1.1 什么是知识库问答质量检查提示词
我先把话说直白一点：知识库问答质量检查提示词，就是一段交给大模型执行的“质检工作说明书”。它不负责直接回答用户问题，它负责判断另一个问答结果靠不靠谱。我会把待检查的问题、知识库检索片段、模型答案、引用信息一起放进提示词里，让模型按我设定的维度逐项检查，最后给出评分、结论和理由。这个角色很像质检员，不像答题员。
我见过不少团队把“质检”理解成人工抽看几条答案。人工抽检有价值，成本也高，覆盖范围有限。知识库问答质量检查提示词把质检标准写成可执行的文本规则，让模型批量跑起来。它关注的是答案和知识库是否一致、引用能不能追溯、回答是否完整、有没有安全风险。我的经验是，提示词写得越像一份清晰的验收单，后面拿到的结果越稳定。
还有一点容易混淆：质量检查提示词不是让模型“再答一遍”。它要输出的是判定结果，不是新的答案。我会在提示词里明确“你是检查者，不是回答者”，要求模型先找证据，再下结论。这个边界划清楚，质检结果才不容易跑偏。
1.2 与普通问答提示词、评测脚本的区别
普通问答提示词的目标是“生成好答案”。我给它一个问题，它组织语言回答。知识库问答质量检查提示词的目标是“判断答案好不好”。它拿到的是问题、答案、知识库证据，输出的是评分和理由。两者面对的对象不一样，写作重点也不一样。普通提示词关心语气、结构、信息组织，质量检查提示词关心判定标准、证据引用、边界案例。
评测脚本更像工程侧的自动化检查。脚本擅长跑规则，比如答案是否包含关键词、引用链接是否为空、响应时间是否达标。质量检查提示词擅长处理语义判断，比如答案和知识库片段是否矛盾、拒答是否合理、表述有没有过度承诺。我会把两者配合使用：脚本做硬规则过滤，提示词做语义质检。只靠脚本，很多“看起来对但事实错”的问题抓不出来。只靠提示词，成本高，速度也受限。
我常跟团队说，别把质量检查提示词写成万能裁判。它适合做语义层的第一道筛子，不适合替代全部人工复核。高风险场景里，提示词给出可疑标记，人工再看关键样本。这个分工比较务实。
1.3 质量检查提示词的核心价值与适用场景
知识库问答质量检查提示词的价值，我体会最深的是“把质检标准从个人经验变成可复用资产”。以前不同人看同一条答案，结论可能不一样。把检查维度、评分档位、扣分理由写进提示词，团队就有了共同语言。新人也能按同一套标准上手，复盘时能对着理由讨论，不用只凭感觉说“这条不太好”。
它还能把质检往前推。产品上线前，我用它批量跑测试集，找出知识库覆盖不足、引用错配、拒答过度这些问题。上线后，我把它接到抽样评测流程里，监控答案质量波动。客服、售前、内部知识助手这些场景都适用。只要答案需要依据知识库、需要可追溯、需要控制风险，知识库问答质量检查提示词就有用武之地。
我比较看重的场景是批量评测和回归验证。知识库更新频繁，模型换版本，提示词调整，都会影响答案质量。每次全量人工看不太现实。知识库问答质量检查提示词能快速给出结构化结果，帮助我定位问题集中在哪些维度。它不保证百分之百准确，它能帮我用较低成本发现大部分明显问题。
1.4 设计质量检查提示词的基本流程
我的做法是先定检查目标，不急着写提示词。我要先问清楚：这次质检最怕漏掉什么？是事实错误，还是引用缺失，还是安全合规风险？目标不同，检查维度和评分规则差别很大。目标定下来，我再收集一批真实问答样本，包括好答案、坏答案、边界答案。样本里要有反例，提示词才知道什么情况该扣分。
定完目标，我会设计输入输出格式。输入侧固定问题、答案、知识库片段、引用信息这几个字段。输出侧要求模型给出总分、各维度评分、判定理由、可疑点。格式固定下来，后面做批量统计和错误分析会轻松很多。评分档位我会尽量少，三档或四档就够用，档位太多模型容易摇摆。
写完第一版，我会拿小样本试跑，对照人工标注看偏差。偏差大的地方，我回去改判定规则，补边界案例，调整理由输出要求。知识库问答质量检查提示词不是一次写完就结束，它需要跟着错误分析迭代。我的习惯是给每次修改留版本记录，写清楚改了什么、为什么改。这样团队协作时不会乱。
我把质量评估指标看成知识库问答质量检查提示词的骨架。提示词写得再花，指标不清楚，模型也只能凭感觉打分。我在团队里做过几轮校准，发现大家嘴上说“答案质量”，心里想的并不是同一件事。业务同事先看答案能不能解决用户问题，法务同事先看引用和合规，标注同学先看评分档位好不好判断。我把这些视角揉进同一套检查维度里，提示词才有稳定的判定依据。
2.1 答案正确性与事实一致性
答案正确性是我最先抓的指标。它看的是答案里的关键事实与知识库证据是否一致，主体、时间、数字、条件、关系这些信息不能错位。知识库说“退款申请提交后三个工作日到账”，答案写成“当天到账”，这就是硬错误。我会要求检查提示词把答案拆成可核对的事实点，再逐条对照知识库片段，判定“支持”“部分支持”“不支持”或“证据不足”。
事实一致性不等于关键词重合。我见过答案把知识库里的原词都带上了，语义却拧着来。知识库写“该活动仅限新用户”，答案写“新老用户都能参加，新用户优先”，关键词都在，事实已经变了。知识库问答质量检查提示词要能抓这种语义矛盾，我会在提示词里放反例，要求模型说明哪一句和哪条证据冲突，不能只给一个“错误”标签。
我会把正确性错误分硬错误和软偏差。硬错误是事实相反、数字错误、主体错配，这类直接判不合格。软偏差是表述不严谨、条件漏写、范围说得过大，这类按档位扣分。每条判定都要求附证据片段和理由，方便人工复核。这个做法让同一批答案在不同人手里更容易得出接近的结论。
2.2 知识库覆盖度与引用可追溯性
知识库覆盖度看的是回答问题所需的信息在知识库里有没依据。用户问“企业版能不能开票”，知识库只有个人版开票说明，答案却给了企业版结论，这就是覆盖不足。我会把覆盖度分成完全覆盖、部分覆盖、未覆盖三档。部分覆盖时，答案只能回答有依据的部分，缺依据的部分要明确说不知道，不能拿相近内容顶上。
引用可追溯性是我和业务同事争论最多的地方。业务同事要能点开引用核对原文，标注同学要能定位答案里的哪句话对应哪条片段，我看的是引用片段是否真的支撑结论。同一批问答里，有的答案引用格式很漂亮，点进去发现片段讲的是另一个产品。引用存在不等于可追溯，知识库问答质量检查提示词要检查引用编号、片段内容和答案句子之间的对应关系。
我会在检查维度里单列“引用支撑度”。完全支撑是片段直接包含答案关键事实，部分支撑是只覆盖一部分，不支撑是引用与结论无关。覆盖度和引用支撑度要分开评，不能互相抵消。一条答案覆盖度很高，引用却乱挂，照样要扣分。这样评出来的结果，业务方看得懂，工程侧也能拿去做知识库补录。
2.3 相关性、完整性与简洁性
相关性看答案有没有正面回应用户问题。用户问“怎么修改绑定手机号”，答案大谈账户安全体系，信息再多也不相关。我会让检查提示词先提取用户问题的核心意图，再看答案是否落在意图范围内。相关性差的知识库问答质量检查结果，我会单独标出来，这类问题常常出在检索片段跑偏或者提示词把回答带偏。
完整性看关键要点有没漏。客服场景里，退款流程要讲清申请入口、审核时长、到账时间，漏掉到账时间，用户还会追问。内部知识助手场景里，完整性要求可以松一点，用户更想快速拿到结论。我会按场景调整完整性权重，检查提示词里写清“本场景必须覆盖的要点类型”，不让模型凭常识补。
简洁性看答案有没堆砌和重复。我见过模型把知识库三段话全贴出来，正确信息都在，用户读起来费劲。简洁性不是越短越好，关键限制条件不能为了短而删。我会把相关性、完整性、简洁性放在同一组检查，要求模型分别打分。三个分数分开看，团队才知道问题出在答偏、答漏还是答啰嗦。
2.4 安全合规、拒答与不确定性表达
安全合规是质量检查里的底线维度。敏感个人信息、越权承诺、医疗金融等高风险建议，都要在提示词里列成明确检查项。客服主管关心的是答案会不会乱承诺赔偿，合规同事关心的是有没泄露隐私，我关心的是模型能不能识别风险表述并给出扣分理由。安全合规不合格的答案，我不建议用总分平均掉，要单独标记。
拒答质量要分两头看。该拒答时拒答，是能力；不该拒答时乱拒，是伤害。知识库没有依据、问题超出服务范围、涉及敏感操作，这些情况要拒答或者转人工。知识库有明确答案，模型还来一句“我无法回答”，用户体验会很差。我会在检查提示词里写清拒答触发条件和拒答话术要求，让模型判断拒答是否合理。
不确定性表达是容易被忽略的检查点。知识库证据不足时，答案要说明“当前知识库没有明确说明”，不能编一个看似合理的结论。我会要求模型检查答案里有没“可能”“建议咨询人工”这类不确定性表达，也要检查这些表达是否被滥用。该确定的地方含糊，该谨慎的地方拍胸脯，这两种情况都要扣分。
2.5 结构化评分规则与判定标准设计
评分规则要能让模型执行，也要能让人复核。我通常把评分拆成维度分、档位判定、理由字段三块。维度分覆盖正确性、覆盖度、引用支撑度、相关性、完整性、简洁性、安全合规、拒答质量。档位我控制在三档或四档，档位太多，模型容易在相邻档之间摇摆。每个档位写清判定条件，比如“完全支持”要求证据片段直接包含关键事实，“部分支持”要求证据覆盖部分事实但缺少限制条件。
判定标准要写正例、反例和边界例。只写“答案要正确”没有用，模型不知道什么叫正确。我会在提示词里放一条好答案、一条事实错误答案、一条引用错配答案，让模型对照判定。评分规则里还要写扣分上限和是否一票否决。安全合规、硬事实错误适合单独标记，不与普通维度分混在一起。这样跑批量评测时，问题定位会清楚很多。
我设计结构化评分规则时，会拉上标注同学试跑。工程同事看字段是否好解析，标注同学看档位是否好判断，我看同一答案多次检查的稳定性。知识库问答质量检查提示词不是评分表越细越好，字段太多，模型输出会变长，判定一致性也会下降。我的经验是先把关键维度跑稳，再按错误分析补细分项。评分规则跟着业务场景迭代，提示词才不容易僵化。
我写质量检查提示词有个习惯，先把一句话写在文档最顶上：让模型看完一条问答后，像质检员一样填一张结构化的检查单。这句话看着简单，真动手写的时候，大部分时间都花在磨那张“检查单”上。指标维度上一章已经铺好了，这一章讲的是怎么把这些维度翻译成模型能执行、人能复核的提示词。
我经历过最典型的一次翻车，是提示词里写了“请检查答案是否正确”，跑完批量评测发现模型给所有答案打了“正确”。问题不在模型，在我没把“正确”拆成可操作的步骤。后来我把提示词改成了“先提取答案中的关键事实点，再逐条对照知识库片段，标注每条事实的支持状态”，同一批数据的结果就稳定多了。从那次之后，我写质量检查提示词都会问自己一句：一个刚入职的标注同学拿着这段提示词，能不能做出和我一样的判断。
3.1 明确任务目标与输入输出格式
我写提示词第一段永远留给任务目标。这一段不写背景不写感谢，直接说清楚三件事：这条提示词要检查什么、检查结果用来做什么、模型需要按什么顺序干活。比如“你是一名知识库问答质检员。你的任务是判断给定答案是否完全基于知识库片段作答，并输出每个检查维度的判定结果和理由。这些结果将用于人工复核和数据采样。”任务目标写清楚了，模型后面跑偏的概率会低很多。
输入格式我习惯用带标签的块状结构，不用长段落。知识库片段、用户问题、待检查答案各占一块，每块前面加个明确标签。我踩过的坑是把知识库片段和用户问题混在一段里，模型偶尔会把用户问题里的描述当成证据。后来我固定写成“【知识库片段】——”“【用户问题】——”“【待检查答案】——”，每块之间空一行，模型引用证据时指代清楚多了。
输出格式我一般不直接写JSON，先用表格描述字段，再补一句“请按表格字段以JSON格式输出”。字段包括：各维度判定档位、判定理由、关键证据片段、是否需要人工复核。每个字段我会加一句取值说明，比如“判定理由需引用答案中的具体句子，不能只写‘表述不当’”。输出格式里我会明确禁止模型输出与表格无关的寒暄和总结。字数限制也写清楚，理由字段控制在两到三句话，太长了批量跑起来解析成本高。
有一点我特别在意：输入输出格式要和下游系统对齐。工程同事要解析哪个字段、字段值是枚举还是自由文本、枚举值大小写敏不敏感，这些在写提示词之前就要确认。我吃过一次亏，提示词里写“输出高、中、低三档”，代码里按“high/medium/low”匹配，批量结果全被判成无效。格式对齐这件事，先和后端确认再动笔，比写完再改省事。
3.2 设计角色、检查范围与判定规则
角色设定我不写空泛的“你是专家”，写得越具体越好。我会写“你是一名在客服知识库运营团队工作三年的质检员，熟悉退款、账户、发票类问题的标准表述，能区分事实错误和表述偏差”。角色里带上业务领域和判断经验，模型在边界案例上会更谨慎。角色设定还要写清“你不负责什么”，比如“你只检查答案与知识库片段的一致性，不评价知识库本身是否正确”。这样能防止模型跳出去评知识库质量问题。
检查范围我会在提示词里列成清单，写明哪些维度必须检查、哪些维度本次不检查。比如某次评测只关注正确性和引用支撑度，我会写“本次检查不涉及安全合规维度，遇到敏感内容只需标记疑似”，不让模型在无关维度上消耗判定注意力。检查范围里还会写清“证据不足时怎么办”，我的规则是证据不足按“无法判定”处理，不强行推断。模型遇到证据不足时容易硬猜，提示词里提前堵住这个口子。
判定规则我坚持写成“条件—档位”对照表，不写成模糊描述。比如引用支撑度我会写：“片段直接包含答案全部关键事实，判完全支撑；片段覆盖部分关键事实但缺少限制条件，判部分支撑；片段与答案关键事实无关或矛盾，判不支撑。”每条规则后面跟一个简短示例。我还会在判定规则里加一条元规则：“如果两个档位都说得通，选更保守的那个，并在理由里说明分歧点。”这条规则帮我在多模型对比时减少摇摆。
检查范围里我会专门写一节“不检查项”。模型被要求做质量检查时，常常顺手把答案的格式、语气、标点也挑一遍。这些不属于本次检查范围。我会写“不要因为答案语气不够热情扣分，不要因为答案没有使用敬语扣分”。不检查项写出来之后，模型给出的理由更聚焦在实质问题上。这个做法我是从标注规范里借来的，写提示词和写标注手册，底层逻辑是一回事。
3.3 编写评分量表与理由输出要求
评分量表我控制在三到四档，档位太多模型在相邻档之间反复横跳。每档我会用一句判定条件加一条示例来定义。比如正确性我用“完全正确、存在软偏差、存在硬错误、无法判定”四档。软偏差和硬错误的区别我在提示词里写死：事实相反、数字错误、主体错配是硬错误；条件漏写、范围表述过大是软偏差。写死之后，模型不会把“到账时间写错了”降级成软偏差。
理由输出要求我写得最细。我会明确要求每条判定理由包含三部分：答案中的问题句、知识库中的对应证据句、判定依据。缺任何一部分，理由不合格。我还会要求模型在理由里说明“为什么不是相邻档位”，比如判了部分支撑，要解释为什么不是完全支撑。这个要求会让模型多花一点推理成本，但复核时能直接看到判定边界。有次跑完评测，标注同学反馈说加了这一句之后，他们纠正模型判定的速度明显变快了。
量表里我会单独设一个“整体结论”字段，但不让模型用平均分自动算。整体结论的规则写清楚：存在硬错误或安全合规问题，整体判不合格；无硬错误但有两个以上维度扣分，整体判需复核；所有维度达标，整体判合格。平均分在质量检查里容易掩盖一票否决项，我宁可让规则复杂一点，也不让一条有硬错误的答案因为其他维度得分高而被平均掉。
我还会在理由输出里加一个“证据定位”字段。知识库片段比较长的时候，模型经常只写“依据知识库片段”，没有定位到具体句子。我会要求模型把支撑判定的事实句原文摘出来，摘不出来就说明证据不足。这个字段加上之后，人工抽检的核对时间缩短了不少。工程同事做错误聚类时，也能直接用证据句做文本匹配，不用再人工翻原文。
3.4 加入边界案例、反例与判定约束
光写规则不写例子，模型的理解会飘。我在提示词里固定放三类例子：正例、反例、边界例。正例用一条好答案，展示各维度满分长什么样。反例用一条事实错误答案，展示硬错误怎么判、理由怎么写。边界例用一条“部分信息有依据、部分信息没依据”的答案，展示部分支撑的判定逻辑。三个例子加起来占提示词篇幅不小，我觉得值。没有例子的提示词，每次跑出来的判定尺度都在变。
反例我会选那种“看起来对、细看有问题”的答案。比如知识库说“会员积分有效期为12个月”，答案写“会员积分长期有效”。关键词对上了，语义已经变了。反例后面我会跟一句“此答案判硬错误，理由是答案将有限期表述替换为无限期，与证据句构成直接矛盾”。模型看到这种对照，对语义矛盾的敏感度会高一些。边界例我选的是“知识库覆盖了申请条件但没写审核时长”这种半覆盖情况，让模型学会区分“答漏”和“答错”。
判定约束我通常写三条。第一条：不能自行补充知识库片段之外的信息作为判定依据。模型有时会调用自己训练数据里的常识来“纠正”知识库，这在知识库问答质检里是越界行为。第二条：无法判定时必须标注“证据不足”，不允许强行给档位。第三条：涉及敏感内容的答案，即使知识库片段支持，也要单独标记“需合规复核”，不直接判合格。这三条约束放到提示词末尾，模型执行时会更守边界。
我还会在提示词里加一个“自检步骤”。要求模型在输出最终结果之前，先检查自己有没有漏掉必检维度、理由里有没有引用具体句子、档位选择有没有和规则对照表一致。这个自检步骤写在输出格式之后，模型执行时会多走一遍。我拿同一批数据对比过，加了自检步骤之后，格式错误率明显下降，尤其是指定JSON字段漏字段的问题少了很多。
3.5 提示词的可复用结构与版本管理
我写质量检查提示词不会每次从头写。我有一套固定骨架：任务目标、角色设定、输入格式、检查维度清单、判定规则与量表、示例区、输出格式、自检与约束。固定骨架负责稳定，每次要改的是检查维度清单、示例和量表档位定义。这样改起来有位置感，新同事接手也能快速找到该改哪一段。我见过有人把提示词写成一大段自然语言，改一版结果就漂一版，没法做版本对比。
可复用结构里我会把“业务专属内容”抽成变量。比如知识库片段示例、答案示例、敏感内容清单，这些在不同业务线不一样，写成变量之后，主体提示词不用动。我会在文档里用“{{知识库片段示例}}”“{{敏感内容清单}}”这种占位符标注。工程同事做提示词管理系统时，直接按占位符做参数注入。这个做法还有一个好处：业务方要换成自己领域的例子，不需要改主体逻辑，换个变量包就行。
版本管理我做得比较土但有效。每版提示词文件头部写四行：版本号、修改日期、改了什么、为什么改。提示词内容本身不做行内注释，避免模型把注释当指令执行。每次改版我会先跑一个固定的小样本集，记录各维度判定分布，和上一版做对比。分布变化大的维度，我会回去看是提示词措辞问题还是样本本身就有争议。
我还会给提示词配一份“变更记录表”，每次改版写清楚触发修改的具体badcase。比如“v1.3：增加引用错配反例，原因是v1.2在引用编号正确但片段内容无关的案例上全部误判”。这份表在团队交接时特别有用，新人能看到每个约束条目的是什么，不会上来就把看似多余的规则删掉。提示词版本和评测集版本我会绑在一起记，避免换了评测集之后结果没法比。
可复用结构最后一块是“场景适配层”。同一个质检骨架，客服场景和内部知识助手场景的判定权重不一样。我会在骨架末尾加一段“场景参数”，写明本场景完整性权重高于简洁性，或者本场景安全合规采用一票否决。场景参数和主体逻辑分开写，调参时不容易误伤通用规则。这套结构跑顺了之后，新业务线接入基本就是换示例、调权重、跑小样本校准三步。 你是一名知识库问答质检员，负责对给定问答对进行质量检查。你的检查结果将用于人工复核、错误聚类和模型迭代。
【角色与边界】 你在客服知识库运营团队工作三年，熟悉退款、账户、发票类问题的标准表述。 你只检查答案与知识库片段的一致性，不评价知识库片段本身是否正确，不检查答案的格式、语气和标点。
【输入】 【知识库片段】 {{知识库片段}}
【用户问题】 {{用户问题}}
【待检查答案】 {{待检查答案}}
【检查维度与判定档位】 1. 正确性：完全正确 / 软偏差 / 硬错误 / 无法判定 事实相反、数字错误、主体错配判硬错误；条件漏写、范围表述过大判软偏差。 2. 引用支撑度：完全支撑 / 部分支撑 / 不支撑 / 无法判定 片段直接包含全部关键事实判完全支撑；覆盖部分关键事实但缺少限制条件判部分支撑； 片段与关键事实无关或矛盾判不支撑。 3. 完整性：完整 / 部分缺失 / 严重缺失 / 无法判定 4. 相关性：相关 / 部分相关 / 不相关 5. 简洁性：简洁 / 略显冗余 / 严重冗余 6. 安全合规：通过 / 疑似违规 / 违规
【判定约束】 - 不能自行补充知识库片段之外的信息作为判定依据。 - 证据不足时必须标注“无法判定”，不允许强行给档位。 - 涉及敏感内容的答案，即使片段支持，也标记“需合规复核”。 - 两个档位都说得通时，选更保守的档位，并在理由里说明分歧点。
【输出格式】 按以下字段以 JSON 格式输出，不要输出 JSON 之外的任何内容： { "正确性": {"档位": "", "理由": "", "证据句": ""}, "引用支撑度": {"档位": "", "理由": "", "证据句": ""}, "完整性": {"档位": "", "理由": ""}, "相关性": {"档位": "", "理由": ""}, "简洁性": {"档位": "", "理由": ""}, "安全合规": {"档位": "", "理由": ""}, "整体结论": "合格 / 需复核 / 不合格", "是否需人工复核": true }
【整体结论规则】 - 存在硬错误或安全合规违规，整体判不合格。 - 无硬错误但有两个以上维度扣分，整体判需复核。 - 所有维度达标，整体判合格。
【自检】 输出前检查：必检维度是否都填了、理由是否引用了具体句子、档位是否与对照表一致。
模板写完只是半成品。上一章那些模板在我电脑里躺了半个月，真正跑起来才发现问题一箩筐：数据集偏简单，模型分数虚高；提示词改一版，某个维度好了，另一个维度又塌了；换个模型，同一套提示词判出来的档位分布完全不一样。这一章聊的就是把质检提示词从文档变成生产线的过程，脏活累活居多，经验也都是踩坑踩出来的。
5.1 评测数据集与抽样策略
我最早做评测数据集，直接让工程同事从线上日志随机抽了五百条。跑完一看，正确性合格率 92%，高兴了没两天。人工复核一百条，发现随机抽样里七成问题是“退款多久到账”“发票怎么开”这种标准问题，答案早就被知识库打磨得很稳。难例、长尾、边界案例少得可怜，模型在这种数据集上分数当然好看。这套数据集拿去做版本对比，提示词改好改坏根本看不出来。
后来我改成按维度分层抽样。业务线一层，问题类型一层，知识库片段长度一层，答案质量档位再一层。难例比例我一般控制在两到三成，来源包括客服工单里用户反复追问的问题、知识库刚更新还没沉淀标准答案的问题、以及人工标注时争议大的样本。历史难例我会保留一部分在回归集里，每次改提示词都跑一遍，防止老毛病复发。抽样时间上，近三个月的数据占七成，更早的样本只留典型难例。数据脱敏在抽样阶段就做掉，手机号、订单号、身份证号统一替换，别等标注完再回头清洗。
样本量这块，小样本评测我跑五十到一百条，看字段缺失率和档位分布。全量评测按置信区间算，一般每个业务线不少于三百条。标注环节我坚持双人标注加仲裁，标注规范跟提示词里的档位定义用同一份文档。有次标注同学按自己的理解把“部分支撑”判成“完全支撑”，回头查发现提示词里“部分支撑”的定义写得太绕，模型和人都理解偏了。数据集和提示词是一体两面，这话我 now 信了。
5.2 提示词效果验证与指标校准
提示词效果验证，我只看三样东西：跟人工金标的一致性、各维度档位分布、以及错误样本长什么样。一致性用 Cohen's Kappa 算，正确性和引用支撑度这两个维度我要求 Kappa 不低于 0.65，低于这个值提示词就得回炉。档位分布看的是判定偏松还是偏紧。有次“完整性”维度“完整”占比 85%，人工金标只有 62%，回去查提示词，发现完整性检查步骤里没写“以用户问题必要信息点为标准”，模型把知识库片段里所有内容都当成必答项，答案少写一句就判缺失，判定整体偏严，分布却偏松，原因是模型把“部分缺失”也归到“完整”里了，档位定义有歧义。
指标校准我习惯做混淆矩阵。正确性维度把“硬错误”和“软偏差”分开看，硬错误的召回率优先保，宁可把一些软偏差判成硬错误，也不能漏掉事实性错误。客服场景一条硬错误可能带来投诉，复核成本比误判成本高。拒答质量维度看“应答未拒”和“过度拒答”两个方向的错误率，这两个错误对用户体验的伤害不一样，阈值分开设。模型输出有随机性，温度我统一设 0，同一批样本跑三次，取档位一致率低于 90% 的样本进人工复核池。有次改提示词，正确性 Kappa 从 0.68 提到 0.74，完整性 Kappa 从 0.71 掉到 0.63。只看一个指标会以为改成功了，全维度看才发现模型变保守了，该答全的地方开始漏信息。提示词迭代最怕这种跷跷板，验证时必须所有维度一起看。
5.3 基于错误分析的提示词迭代优化
错误分析我一般分两步走。先做错误聚类，把模型判错的样本按错误类型归堆：事实点漏提、证据句摘错、档位边界模糊、拒答误判、格式解析失败。再抽样看判定理由，定位到提示词的具体步骤。有段时间数字类事实点漏提率特别高，回去看模板，“关键事实点”的定义写的是“可被证实或证伪的陈述”，太抽象。我补了五个例子，数字、时间、条件、资格、操作步骤各一个，漏提率降了一半。还有一次拒答质量误判集中，模型把“答案不完整”当成“拒答不清晰”，我在模板里加了一句“实际是否拒答必须是明确拒绝表述，没有‘无法回答’‘不能提供’这类表述的一律算作答”，误判少了很多。
迭代节奏我控制得很小，一次只改一个变量。改完先跑五十条小样本，看字段缺失率和档位分布有没有异常。小样本过了再跑全量回归集，跟上一版做对比。提示词版本号我写在模板头部，每次改动记一条变更日志：改了哪段、为什么改、预期影响哪个维度、回归结果怎么样。有次同时改了三处措辞，正确性上去了，简洁性崩了，回头根本说不清是哪处改动导致的。从那以后我给自己定规矩，一次只动一个地方，改完必须跑回归。回归集里我专门放了一批“老难例”，这些样本是过去半年人工复核争议最大的，每次迭代都跑，防止改新问题把老问题带回来。
错误分析的价值不只是改提示词。有些错误聚类出来发现是知识库片段本身写得模糊，模型判“无法判定”是合理的，这种样本要回流到知识库运营侧。还有些错误是标注规范不一致导致的，得回去改标注手册。质检提示词跑顺之后，它其实变成了一面镜子，照出知识库、标注、模型三方的短板。
5.4 多模型、多场景下的适配与对比
同一套提示词换模型，结果经常差出一截。有的模型指令遵循好，JSON 输出稳定，档位判定偏保守；有的模型爱发挥，理由写得漂亮，档位给得大方，正确性维度“完全正确”占比能高出十个百分点。我做过一次三模型对比，同一批五百条样本，A 模型硬错误召回 0.81，B 模型 0.72，C 模型 0.76。B 模型不是能力差，是它对“矛盾”的理解偏窄，答案把“1 到 3 个工作日”改成“3 到 5 个工作日”，它判“部分支持”，没判“矛盾”。后来我在模板里把“数字、方向、主体、范围冲突”写进矛盾判定标准，B 模型的召回上来了。
多场景适配，我的做法是通用模板加场景补充规则。客服场景强调拒答质量和安全合规，内部知识助手场景强调完整性和引用可追溯，工单辅助场景强调简洁性和结构化输出。场景补充规则单独放一个文件，不混进通用模板里，方便按业务线组合。模型特定约束也单独维护，比如某个模型对长上下文里的证据句定位弱，我就在模板里要求“先摘录证据句原文再判定”，用步骤约束补模型短板。温度参数、最大输出长度、JSON 模式这些配置项，跟提示词版本一起记录在评测配置表里，做模型对比时保证除了模型名其他条件一致。
多模型对比的统计口径要统一。我一般按维度统计档位分布、跟人工金标的一致率、以及平均输出 token 数。token 数这个指标容易被忽略，有的模型理由写得长，单条成本高出一截，批量跑两千条差距就明显了。对比结果我习惯画一张表，行是模型，列是各维度 Kappa 和硬错误召回，一眼能看出哪个模型适合哪个场景。没有哪个模型在所有维度上都最好，选型得看业务最在意哪个维度。
5.5 常见误判、评分偏差与规避策略
质检提示词跑久了，能总结出几类高频误判。长度偏差最常见，答案写得长，模型容易判“完整”和“相关”，哪怕后半段跑题。位置偏差也有，证据句藏在知识库片段中间或者末尾，模型摘不出来就判“不支撑”。引用编号偏差更隐蔽，答案写了“依据片段 2”，片段 2 确实存在，内容却跟答案没关系，模型看到编号就放行。礼貌偏差集中在简洁性维度，客服答案带“感谢您的耐心等待”“如有疑问请随时联系”，模型判“略显冗余”，人工复核觉得是场景习惯。乐观偏差是模型倾向于给“合格”，尤其在其他维度都还不错的时候，硬错误容易被放过。
规避策略我总结了几条。档位定义必须配反例，光写“硬错误指事实相反”不够，得写“答案说积分长期有效，知识库说有效期 12 个月，判硬错误”。证据句摘录要求写进模板，摘不出原文就标“无法判定”，这个约束比任何措辞都管用。简洁性维度列不检查项，礼貌用语、语气、段落划分都不扣分。整体结论不让模型算平均分，硬错误和安全违规一票否决，其他维度扣分累计到阈值才判“需复核”。校准集定期跑，人工复核的争议样本回流到校准集里，每季度更新一次。
评分偏差没法完全消灭，只能压到可接受范围。我的经验是，单模型单提示词的判定一致性做到 Kappa 0.7 左右就到瓶颈了，再往上提得靠规则兜底和人工复核。规则兜底包括数字比对、引用片段内容匹配、敏感词扫描，这些确定性检查放在模型判定之后跑，冲突时以规则为准。人工复核比例我控制在 15% 到 20%，重点复核“需复核”档和模型理由写得含糊的样本。这套流程跑顺之后，质检提示词才算真正变成生产线上的工装，不再是一份躺在文档里的提示词。
