# 【提示词工程系统教程 04】 LLM应用架构：循环式工作流与提示工程落地 【提示词工程系统教程 04】 LLM应用架构循环式工作流与提示工程落地章节导读从模型原理到工程落地上一章我们围绕对话模型的对齐技术展开讲解了基础模型的原生局限、HHH 对齐标准、RLHF 三阶段训练流水线以及 ChatML 对话范式与对齐带来的能力权衡。这些内容聚焦于大模型本身的能力特性与交互规则是提示工程的底层理论基础。而在真实的产品落地与业务场景中大模型仅仅是一个负责文本生成的底层组件完整的 LLM 应用是一套包含「问题转换 - 上下文加工 - 模型生成 - 效果反馈」的完整循环工作流。用户的现实问题不会天然就是合格的提示词模型的原始输出也不能直接等同于业务解决方案中间需要一整套工程化的处理流程。本章将正式从模型原理转向工程应用拆解 LLM 应用的循环式架构讲解将用户问题转化为模型输入的四大核心标准、上下文处理的前馈流水线、复杂应用的四大能力升级方向以及概率系统特有的双阶段质量评估方法帮助我们理解提示工程在真实产品中的落地逻辑。本章学习目标拆解大语言模型应用的循环式架构理解应用如何在用户问题域与模型文本域之间完成双向转换。掌握“小红帽原则”的核心思想能够设计符合训练数据分布的提示结构获得稳定可预测的输出。掌握提示工程的四大核心标准能够从模仿性、相关性、有用性、终止性四个维度设计与优化提示词。能够从媒介、抽象程度、上下文需求、有状态性四个维度评估不同LLM应用的开发复杂度。4.1 循环架构LLM应用的核心运行逻辑4.1.1 应用的本质用户域与模型域的桥梁前面的章节我们讲解了大语言模型的底层原理、对齐技术与对话交互范式而在实际产品中大模型本身只是一个底层能力组件完整的LLM应用是一套完整的循环工作流。这个循环的核心价值是作为用户问题域和模型域之间的桥梁模型的能力边界非常单一它只能完成文档补全、预测下一个词元无法直接处理现实中的复杂问题。应用的核心作用把用户的各类现实问题转化为模型可以处理的文本格式再把模型生成的文本补全结果转化为用户能直接使用的解决方案。完整的循环流程分为四步用户提出现实场景中的问题应用将用户问题转换、加工为符合要求的提示词输入给大模型大模型完成文档补全输出文本结果应用将模型的输出转换为对应的解决方案反馈给用户该应用程序的强大功能在于它能够通过文本补全功能灵活解决各种问题如邮件处理、旅行安排、代码编写等。4.1.2 用户问题域的四个复杂度维度一个LLM应用的开发难度完全取决于用户问题本身的属性。我们可以从四个核心维度评估任意一个LLM应用的复杂度媒介维度问题本身的承载形式。文本是对大模型最友好的媒介语音、图像、结构化数据等都需要额外的转换处理。抽象程度问题的明确度与复杂度。具体、定义清晰的问题难度低高度抽象、开放的问题需要更复杂的推理能力。上下文需求解决问题需要的额外信息量。只需要用户输入本身就能解决的问题难度低需要调用大量外部信息、私有数据的问题复杂度高。有状态性是否需要依赖历史交互信息。单次独立请求的问题难度低需要跨会话、长时间记忆用户偏好与历史的问题复杂度高。4.1.3 三类典型应用的复杂度对比我们通过三个典型任务对应四个维度做拆解可以直观看到不同LLM应用的复杂度差异。任务1文本校对工具问题媒介纯文本和模型的输入格式天然匹配抽象程度非常具体目标明确就是修正拼写、标点、格式与表述错误上下文需求仅需要用户提交的待校对文本本身不需要额外信息有状态性无状态每一次API调用都是独立的问题不需要历史记录这是最简单的一类LLM应用四个维度的复杂度都极低仅需基础的提示词设计就能实现。任务2IT技术支持助手这里的IT支持不是简单的问答聊天机器人而是能像专业IT专员一样解决各类技术问题的完整应用。问题媒介电话语音输入需要先做语音转文字的预处理抽象程度问题空间和解决方案空间都很大但受限于已有的技术文档范围上下文需求需要可检索的技术文档库、历史支持对话记录作为参考有状态性必须跟踪对话历史记录已经尝试过的解决方案避免重复建议这是中等复杂度的LLM应用需要配套检索系统、对话状态管理等额外模块才能实现。任务3旅行规划助手问题媒介包含网站交互、用户文本输入、外部API对接等多种形式抽象程度需要理解用户的主观偏好和客观约束协调多维度的复杂方案上下文需求需要对接日历、航班API、最新的新闻资讯、政府出行建议、百科信息等大量外部数据源有状态性需要记录在几周的时间里所进行的各种规划过程不同的互动方式以及那些未能实现的规划方案这是高复杂度的LLM应用需要完整的外部系统对接、长周期状态管理、多轮推理能力属于智能体级别的应用。实战讨论复杂度排序与延伸问题文本校对工具、智能家居语音助手、法律案件摘要工具三者按复杂度从低到高排序为文本校对工具 法律案件摘要工具 智能家居语音助手。其中法律案件摘要工具的典型特点是对上下文需求量大需要读取完整的案件文书但有状态性低——每一次摘要任务都是独立的不需要记录历史对话只需要处理当前的单份文档。这也是绝大多数文档处理类应用的共同特征高上下文需求、低状态依赖。4.2 向模型域转换提示工程的四大核心标准将用户的现实问题转换为模型可处理的提示词是提示工程的核心环节。这一步的目标是构造出一个提示词让模型生成的补全内容刚好能用来解决用户的问题。一个合格的提示词必须同时满足四大核心标准。4.2.1 标准一模仿性——贴近训练数据分布核心要求提示词的结构、格式、文风要尽可能和模型训练集中的内容相似。模型对熟悉的格式预测更稳定输出质量也更可控如果提示结构和训练数据差异过大模型的输出会变得不可预测。这就是著名的“小红帽原则”不要偏离训练数据这条“小路”。如果模型训练过大量Python代码那提示就应该写成标准的代码注释格式而不是零散的自然语言描述。如果模型熟悉Markdown格式就用#、##等标题层级来结构化你的请求而不是纯段落文本。核心结论熟悉的结构会带来可预测的输出。符合训练数据分布的样本分布内输出稳定、质量可控偏离训练数据的样本分布外输出波动大、容易出错。实战示例想让模型生成一份产品需求文档用Markdown标题分模块编写提示比用纯文字描述需求输出的结构会更清晰、更符合常规文档格式。因为训练集中有大量标准格式的Markdown文档模型对这种结构的续写更稳定。4.2.2 标准二相关性——注入全部相关信息核心挑战模型本身不知道用户的身份、所处的环境、当下的实时新闻和私有数据。应用必须主动把这些信息收集起来注入到提示词中。上下文的需求量级是一个连续谱简单场景比如校对工具只需要用户提供的原始文本就足够。复杂场景比如旅行规划工具需要注入大量外部实时信息。经典实例平壤旅行规划用户请求「帮我规划一趟平壤的旅行」如果不注入额外上下文模型可能会正常推荐景点、行程完全不知道相关的地缘政治风险输出内容会脱离现实。合格的应用会先检索并注入相关信息官方旅行警告「请勿前往存在拘捕风险」实时新闻「朝鲜发射弹道导弹」「当地执行疫情封锁政策」有了这些相关上下文模型才能生成符合现实情况的、对用户负责的回复。4.2.3 标准三有用性——引导模型输出解决方案核心目标不能只描述问题要明确要求模型给出答案。要在提示中形成一股“向解决方案靠拢的引力”防止模型只是重复描述问题或“胡言乱语”而已。核心实现技巧模式建立少样本提示在提示词里建立固定的“问题→答案”节奏模型会顺着这个模式补全内容。典型的模式结构如下问题1 解决方案1问题2 【模型自动补全解决方案2】实战示例旅行规划场景在提示词里先放一个完整示例问题1推荐适合高尔夫爱好者的旅行目的地解决方案1为您推荐以下三个目的地……简洁礼貌的推荐内容问题2帮我规划平壤的旅行解决方案2通过这种模式模型会自动延续“简洁礼貌”的风格直接给出方案2的内容不会跑偏。注意结尾必须加上「解决方案2」这个触发词如果省略模型可能会接着写第三个问题而不是给出答案。4.2.4 标准四终止性——定义明确的结束点核心问题模型的预训练机制是持续预测下一个词元它天生不知道什么时候任务就完成了会一直续写下去。对话模型经过微调会在输出结束后生成|im_end|特殊词元自动停止。纯补全模型没有自动停止的意识必须人为定义停止规则。解决方案定义明确的停止序列Stop Sequence比如换行符、User:前缀、## 下一个问题标记等。一旦模型生成了对应的序列应用就直接截断生成结束输出。常见误区很多人默认模型“做完任务就会自己停”这是错误的认知。尤其是纯补全模型如果不设置停止序列它会一直续写下去甚至生成更多的问题和无关内容。“小红帽”原则核心概念不要偏离路径即训练数据。如果模型是用 Python 代码训练的那么提示语就应该看起来像 Python 代码。如果使用了 Markdown 格式进行训练可以使用标题标签“#”、“##”来组织请求内容。关键要点熟悉的结构能够产生稳定的预测结果。实战示例作业助手应用场景你正在开发一个名为“作业助手”的应用程序。任务设计一个提示结构使得模型只能回答一个问题然后停止响应而不是生成一个新的完整考试场景。2. 第一层首选大模型 API 的stop参数要让模型回答完一道题就停止而不是自己再出更多题可以用固定模板包裹用户输入responseclient.chat.completions.create(modelgpt-4o,messages[{role:system,content:你是作业答疑助手只输出对应问题的答案不要额外内容。},{role:user,content:问题请解释牛顿第一定律/问题\n答案}],stop[/答案]# 在这里设置停止序列)当模型生成到/答案时会自动停止不会输出标签本身也不会继续生成后续内容既保证了格式干净也节省了不必要的词元消耗。上面提到的\n、User:、\n#这类停止序列也都是通过这个参数传入的2. 第二层兜底应用层后处理截断这是工程上的兜底方案作用在模型输出之后、返回给用户之前。设置位置在你的应用业务代码中拿到模型的完整输出文本后做字符串匹配处理查找停止序列如/答案在输出文本中的位置截取停止序列之前的内容丢弃停止序列和它之后的所有内容再返回给用户。作用防止模型偶发不遵守停止规则、生成溢出的情况做最终的格式兜底保证返回给用户的内容一定符合预期格式。补充说明对话模型本身默认有|im_end|作为内置停止序列普通对话场景无需额外设置只有当你需要严格限定输出格式比如只输出答案本体、只输出JSON时才需要自定义停止序列。停止序列不局限于标签格式任意字符串都可以作为停止符比如---、【结束】、END都统一放在stop参数中即可。4.3 前馈通路上下文处理流水线与复杂度升级4.3.1 前馈通路的核心定位很多人会误以为LLM应用就是“把用户的话发给模型再把结果返回给用户”但工程化的LLM应用远不止如此。前馈通路Feedforward Pass是将用户问题转换为模型文本域的标准化流水线它不是简单的消息转发而是包含检索、加工、排序、组装的完整处理流程。即便模型的上下文窗口已经达到十万甚至百万词元盲目塞入大量无关的“垃圾信息”依然会干扰模型的判断。前馈通路的核心价值就是保证只有最高质量的有效信号输入给大模型。整条流水线分为四个核心步骤上下文检索收集所有相关的信息源片段化处理将原始数据加工为适合放入提示的文本片段打分与排序按重要性排序在词元预算内做取舍提示组装将所有片段拼接为格式规范的完整提示4.3.2 步骤一上下文检索上下文按照和用户当前任务的远近关系分为三类直接上下文用户为当前任务明确提供的内容是优先级最高的核心信息。示例用户输入「帮我修复这个函数的bug」并附上的代码片段。间接上下文用户关注点周边的相关信息不是用户主动提供但和任务高度相关。示例IDE里打开的其他标签页、导入的依赖库、最近编辑的文件以及检索到的相关技术文档。模板固定内容用来塑造回复格式与规则的静态内容全程生效。示例系统提示词、格式引导语如## 解决方案。实战案例GitHub Copilot用户正在编辑的当前文件属于直接上下文而编辑器里打开的其他标签页文件就属于间接上下文会被一同纳入提示的参考范围。4.3.3 步骤二片段化Snippetizing片段化是指将大体积的上下文源拆分为可管理的小块并格式化处理后再放入提示词。它有两个核心挑战挑战1内容提取如果一次搜索返回了一份50页的PDF不可能把整份文档全部塞进提示词。必须从中只提取和当前问题最相关的段落。风险塞入过多无关文本会稀释提示的有效信息大幅降低模型输出的质量。挑战2格式转换原始的API返回数据、数据库字段通常是JSON、XML这类结构化格式自然语言模型处理起来容易混乱。需要先转换成通顺的自然语言片段再放入提示。正反示例不好的示例原始API返回{temp: 298.15, loc: NY}好的示例片段化后纽约当前气温为25摄氏度。4.3.4 步骤三打分与优先级排序上下文的总量往往会远超模型的词元预算因此必须做取舍决定哪些内容进入提示哪些内容被裁减掉。行业通用两种排序机制配合使用优先级分层整数层级先划分大的重要性等级按层级从高到低填充词元预算。第1级必选模板固定内容 用户的直接输入第2级当前活动文档 / 近期对话历史第3级相关参考文档 / 更早的历史记录精细打分浮点分数在同一个优先级层级内再用连续分数区分内容的相关度优先放入分数更高的内容。示例两个打开的文件都属于第2级文件A光标5秒前还停留过相关度得分0.95文件B已经一小时没操作过得分0.6。词元不足时优先保留文件A的内容。4.3.5 步骤四提示组装这是流水线的最后一步核心是“算账”把所有筛选后的片段拼成一份连贯、合规的完整提示刚好适配模型的词元上限。两种常用的组装优化策略省略截断法如果一份高相关文档只是略超长度就删掉其中不重要的次要行用省略号代替而不是直接丢弃整个文档。比如长代码只保留核心函数中间次要逻辑做省略。摘要压缩法对于对话历史这类长内容先用大模型提前压缩成一段摘要再放进系统提示里用很小的词元空间保留核心信息。核心原则组装阶段依然要遵循小红帽原则——最终拼好的提示看起来必须和模型训练时见过的文档格式一致。比如生成代码时组装后的提示应当像一份带注释的合法源代码文件而不是乱糟糟的JSON数据堆砌。4.3.6 应用复杂度的四个升级方向前面的单轮请求流水线是最简单的LLM应用形态也是所有复杂应用的基础。随着需求升级应用的复杂度会沿着四个维度逐步提升更多应用状态、更多外部内容、更深的推理、更多外部交互。1. 应用状态持久化大语言模型天生是无状态的如果你不把历史对话重新喂给它它完全不知道之前发生过什么。对话记忆的管理责任完全在应用层。核心挑战上下文窗口有词元上限长时间的对话比如持续数周的旅行规划、连续数天的编码协作早晚会超出窗口限制不能无限追加历史内容。三种主流的状态管理策略数据库查询用户每次发送消息应用都从数据库如Redis、PostgreSQL中取出完整的对话线程重建上下文。截断法采用先进先出规则砍掉最早的对话内容只保留最近的若干轮。风险容易丢失用户最开始设定的核心约束比如用户名、基础规则等。摘要法用大模型把早期的对话轮次压缩成一段精简摘要放在系统提示中。优势保留关键事实的同时释放大量词元空间。2. 检索增强生成RAG这些模型只了解它们在公开训练数据中的内容它不知道企业的私有数据也不知道最新的新闻事件。如果没有外部上下文补充模型遇到未知问题会选择幻觉而不是承认不知道。**检索增强生成Retrieval-Augmented Generation, RAG**就是解决方案在生成回答之前先从外部知识库中检索相关资料注入到提示词中再让模型基于资料作答。这让大模型从“通用知识百科”变成了“你的私有数据处理器”。三类主流检索方案向量数据库检索通过嵌入模型做语义相似度搜索适合模糊的自然语言查询。关键词检索引擎传统的关键词匹配搜索调试更简单对专业术语、商品编号这类精确查询效果更好。自查询检索当用户输入表述混乱时先让大模型生成规范的检索语句再用语句去查询数据。3. 推理深度提升大模型没有内部的静默思考过程它不能“在心里想好答案再开口”而是边生成边思考输出的词元本身就是思考的载体。要解决复杂的逻辑问题必须强制模型“把思考过程写出来”这就是思维链Chain-of-Thought, CoT提示。原理引导模型分步推理生成的“思考词元”会成为后续内容的上下文模型会基于自己的推导过程得出最终结论准确率大幅提升。正反示例不好的提问「这张机票划算吗」好的提问「先计算这条航线的每英里平均价格再和这个季节的历史价格对比最后根据对比结果判断这张机票算不算划算。」4. 工具使用与函数调用大模型原本被困在纯文本的世界里工具调用Function Calling相当于给了模型“双手”让它可以和真实世界交互获取实时信息、执行实际操作。工具调用的完整流程在提示中定义好所有可用的函数与参数规则模型判断需要调用工具时生成一段结构化文本通常为JSON格式表示要调用的函数与参数应用拦截这段输出暂停生成执行真实的代码或API调用拿到返回结果应用把工具返回结果作为新的上下文重新喂回给模型模型基于工具返回的真实数据用自然语言给出最终答案ReAct范式更高级的工具使用模式是ReActReasoning Acting推理行动模型边推理边自主决定是否调用工具比如自己判断什么时候需要查资料、什么时候需要查天气形成“思考→行动→观察→再思考”的循环。相比固定的单轮工具调用ReAct能处理更复杂的开放式问题准确率显著更高。读写工具的安全边界给大模型开放工具权限必须设置严格的安全边界——本质上是让一个概率性引擎去控制确定性的系统风险差异极大只读工具安全不会改变外部状态就算模型参数幻觉了最多就是搜索失败不会造成实际损失。比如查维基百科、查天气、读取日历。写入工具高风险会真实改变外部世界的状态一旦出错代价极高。比如给客户发正式邮件、预订不可退款的机票、合并生产环境代码。核心设计原则写入操作必须引入人在回路Human-in-the-Loop。永远不要让概率模型自动执行高风险操作先给用户展示草稿必须由用户手动点击确认后再执行。反例警示曾有企业的AI代理被过度授权写入权限最终失控删除了公司整个数据库造成了灾难性损失就是没有遵循人在回路原则导致的。4.4 LLM应用的质量评估4.4.1 概率系统的评估困境大语言模型是概率性引擎它没有“绝对真相”的概念只有“出现可能性”的判断。这和传统的确定性软件有本质区别传统软件输入A永远对应输出B行为完全可预测。大模型输入A可能输出B、B’、C等多种结果错误是必然会发生的这是概率系统的墨菲定律。对应的风险也非常现实模型可能自信地输出虚假信息也可能订错目的地的机票。因此LLM应用的质量评估有一套独立的方法论分为上线前的离线评估和上线后的在线评估两个阶段。4.4.2 离线评估上线前的安全验证离线评估发生在产品发布之前目标是在不把坏体验暴露给真实用户的前提下测试新的提示方案、新模型、新功能。它的最大挑战是没有真实用户来评判好坏需要用自动化的代理指标来模拟评估。策略A外科删除测试这是代码、结构化生成类场景的经典方案被GitHub Copilot官方采用。执行流程准备一份能通过全部单元测试的正常工作代码人为删除其中的一段代码让大模型补全被删除的部分运行单元测试验证补全结果是否正确评估指标单元测试通过率优势结果完全客观、可自动化批量执行、没有歧义适合所有可验证的结构化任务。策略B大模型评委对于聊天机器人、创意写作这类开放式任务单元测试无法适用此时可以用能力更强的大模型来担任“评委”。方法给评委模型一套明确的评分清单比如「语气是否礼貌答案是否简洁内容是否准确」让它给应用的输出打分也可以让它对比两个版本的输出选出更优的一个。重要提醒一定要评估完整的应用链路包括上下文检索环节。只模拟上下文的测试虽然简单但会漏掉检索环节的集成错误上线后容易暴雷。4.4.3 在线评估生产环境的真实表现产品正式上线后就进入在线评估阶段目标是监控真实场景下的性能表现与用户满意度。它的最大挑战是普通用户很少主动给出明确的反馈。点赞/踩的陷阱很多产品会用“点赞、点踩”按钮收集反馈但这个指标有严重的天然缺陷参与率极低绝大多数用户会直接忽略反馈按钮不会主动点击。选择偏差通常只有最不满、最愤怒的用户才会去点踩数据分布严重倾斜不能代表整体用户的感受。统计量不足除非产品有极大流量否则靠点赞数得不到统计显著的结论。结论点赞/踩是有用的补充信号但远远不足以支撑完整的质量评估。黄金标准隐式遥测真正可靠的评估方法是去衡量那些能真实体现用户价值、反映生产力提升的用户行为数据也就是隐式遥测Implicit Telemetry。不需要用户主动打分通过用户的真实操作就能判断效果好坏。两个行业经典案例GitHub Copilot代码接受率它不会问用户“你喜欢这段代码吗”而是统计三个核心行为用户有没有按Tab键接受这段代码建议接受之后是不是立刻就删除了接受之后有没有做大幅度的修改接受率越高、删除率和修改率越低说明生成质量越好、对用户的帮助越大。日程安排助手事件稳定性会话时长是模糊指标——会话短可能是效率高也可能是用户被气走了。真正有效的指标是有没有成功创建日历事件助手创建完事件后用户有没有手动修改时间、地点等核心信息用户手动修改越少说明生成的结果越准确应用的实际价值越高。4.4.4 质量优化的完整循环LLM应用的质量提升是一个持续迭代的闭环流程原型验证阶段用离线代理指标单元测试、大模型评委安全地验证方案快速迭代试错。上线部署阶段给应用做好全链路埋点记录每一次交互的完整数据。效果衡量阶段优先依赖隐式行为信号接受率、任务完成率而非显式的投票评分。核心提醒如果在评估中跳过了上下文检索等任何一个环节都会给产品质量埋下隐患上线后容易出现集成类问题。本章完整总结本章系统讲解了LLM应用的循环式架构与工程落地方法核心结论如下LLM应用的本质是用户问题域与模型文本域之间的桥梁整体运行在“问题转提示、补全转方案”的循环之上应用的复杂度可从媒介、抽象程度、上下文需求、有状态性四个维度评估。将用户问题转换为模型提示有四大核心标准模仿性小红帽原则贴合训练数据分布、相关性注入全部相关信息、有用性引导模型输出解决方案、终止性定义明确的停止规则。前馈通路是上下文处理的标准流水线包含上下文检索、片段化处理、打分排序、提示组装四个步骤在有限的词元预算下最大化输入模型的有效信息。复杂LLM应用沿四个维度升级状态持久化管理对话记忆、RAG接入私有与实时数据、思维链提升推理深度、工具调用实现与真实世界的交互其中写入类工具必须引入人在回路控制安全风险。LLM是概率性系统评估分为离线与在线两个阶段离线阶段用外科删除测试、大模型评委做自动化验证在线阶段以隐式行为遥测为核心替代不可靠的显式点赞反馈形成持续优化的质量闭环。课后思考与参考答案思考题1某企业要搭建内部知识库问答机器人需要保证回答都基于内部文档且输出格式稳定。请结合“小红帽原则”说明在提示组装阶段应当遵循哪些设计要点。参考答案基于小红帽原则提示组装需要尽可能贴合模型熟悉的训练数据格式降低分布外的输出波动核心要点有三个格式贴合检索到的内部文档片段不要以原始JSON、数据库字段的形式直接塞入提示要整理成自然的文档段落格式和模型训练时见过的手册、文章格式保持一致。结构统一用固定的Markdown层级划分“参考资料”“用户问题”“回答”三个模块形成稳定的“资料→问题→答案”模式让模型顺着熟悉的结构续写输出更可控。边界清晰用明确的标记包裹参考资料和用户问题避免不同模块的内容混淆保证模型始终基于注入的内部文档作答减少脱离资料的幻觉。思考题2为什么说“只读工具基本安全写入工具必须谨慎”请结合大模型的概率性特性说明原因并给出对应的工程设计原则。参考答案核心原因大模型是概率性系统输出存在天然的不确定性必然会出现幻觉、参数错误、逻辑偏差。对于只读工具查询天气、搜索文档、读取日历就算模型参数出错最多就是查询失败、返回空结果不会改变系统状态没有不可逆的损失风险极低。对于写入工具发邮件、订机票、删数据、合并代码模型的一次错误就会真实改变外部系统的状态造成财产损失、数据丢失等严重后果代价极高。设计原则写入类操作必须遵循“人在回路”原则——模型只生成草稿方案最终执行必须由用户手动确认后触发绝对不能让模型自动执行高风险的写入操作。思考题3某团队上线了一款AI文案写作助手目前只靠页面上的“点赞/踩”按钮评估产品效果。请问这种评估方式有什么缺陷可以补充哪些隐式指标来更准确地衡量产品效果参考答案点赞/踩的核心缺陷参与率低绝大多数用户不会点击反馈有效数据量不足存在选择偏差负面情绪的用户更倾向于点踩数据无法代表真实的整体满意度反馈颗粒度粗只能知道整体好坏无法定位具体的优劣原因。可补充的隐式指标文案采纳率用户有没有直接使用生成的文案还是直接关闭了页面修改率用户采纳后对文案做了多大比例的修改修改越少说明生成质量越高复访使用率用户会不会再次使用工具周使用次数、留存率越高说明价值越被认可任务完成时长用户完成一篇合格文案的总耗时有没有缩短直接体现生产力提升的效果。思考题4通过训练可以让模型不说谎承认他不知道的内容那为什么还会产生幻觉1. 前提不同描述的不是同一种模型“遇到未知问题优先幻觉”描述的是原始基础模型Base LLM的原生特性也是所有大模型的底层本能。基础模型的训练目标只有一个——续写统计上最合理的下一个词元。它的训练数据里绝大多数内容都是“陈述事实/知识”几乎没有“我不知道、这个问题我无法回答”的文本模式。因此当遇到知识范围外的问题时它不会产生“我不会”的意识只会硬着头皮续写一个看起来最像正确答案的内容也就是幻觉。“会对不知道的内容说不知道”描述的是经过RLHF对齐优化后的对话模型这是后天训练出来的行为偏好不是模型的原生本能。我们在第三章讲过RLHF通过人类排序的方式让模型学到“当自身知识置信度低时说‘我不知道’的回复排名会比编造答案更高”。经过反复奖励优化模型会在通用常识领域主动对没把握的问题表达不确定性。2. 对齐的局限RLHF只能“教态度”不能“补知识”RLHF解决的是“诚实意愿”问题不是“知识边界”问题它的作用有明确的天花板对于通用领域、常识性的未知问题比如“1600年的美国总统是谁”对齐后的模型大概率能正确回答“我不知道/该问题不成立”但对于企业私有数据、实时资讯、长尾小众领域的内容哪怕是对齐后的模型依然会倾向于幻觉。原因很简单模型确实从来没见过这些信息它无法精准判断“这是我没见过的知识”还是“这是我需要续写的内容”底层的续写本能依然会让它编造一个看起来合理的答案。这也正是RAG技术存在的核心价值RLHF是让模型“有不说谎的意愿”而RAG是给模型“不说谎的底气”——直接把答案相关的资料注入提示词从根源上减少模型遇到“未知问题”的场景比单纯靠对齐约束要可靠得多。3. 补充对齐也无法100%消除幻觉哪怕是经过完整RLHF的商用对话模型也做不到“所有不知道的内容都一定会承认”。一方面模型没有真正的“自我认知”它不知道自己的知识边界在哪里只能通过输出的置信度做模糊判断另一方面为了提升用户体验模型的对齐策略也会偏向“尽量给出有用的回答”而非“没百分百把握就说不知道”。简单总结基础模型默认遇到未知就幻觉这是原生特性对齐后的对话模型在通用领域学会了优先承认未知但长尾、私有、实时场景下依然大概率幻觉RAG的作用就是用外部知识注入的方式把模型的“未知场景”变成“已知场景”从工程层面进一步压制幻觉。