vue3中的事件修饰符完整指南
2026-10-18 3467998
2026-10-17 0
资料已经入库，问题也足够明确，系统却仍可能找不到依据、答错条件，甚至对同一问题给出不同结论。遇到这种情况，直接更换模型或重建索引通常无法触及根因。要让排查真正有效，需要沿着数据、检索和生成链路逐层核对证据，并用固定样本验证每一次调整。
资料已经上传，提问也不复杂，知识库却找不到答案，或者引用了原文还是说错。这时候最容易做的动作是换模型、加提示词、重建索引——但如果没找到出错的那一层，投入加了，问题原样保留。这篇文章把排查链路完整拆开，并给了一个完整的排查案例。
知识库回答不准，出错点可能在三层中的任何一层，也可能是多层叠加：
排查顺序不能乱：证据没有进入上下文时，先修数据和检索；证据完整而答案仍然错，才检查生成约束和模型。 反过来先换模型，是最常见也最无效的优化动作——换了大模型，该缺的资料还是缺，该丢的字段还是丢。
开始排查前，先准备一个可复现的错误样本。记录这几个字段：
| 字段 | 说明 |
|---|---|
| 用户身份 | 谁问的，什么角色，有哪些权限 |
| 提问时间 | 对应哪个知识版本生效期 |
| 原始表述 | 用户的原话，不要事后美化 |
| 实际回答 | 系统当时的完整输出 |
| 预期依据 | 正确答案应该来自哪份文档 |
| 错误影响 | 这个错误造成了什么后果 |
有了具体样本，每一步排查才有对照物。没有样本的排查就是在雾里开枪。
讲一个实际的排查案例，比抽象讲原则好理解。
一家制造企业的内部知识库，客服团队反馈：问「XX型号设备的保修期是多久」，系统有时答三年、有时答一年，还有时候说查不到。
排查过程如下：
第一步：确认答案客观存在。 翻了产品资料，这个型号确实有保修条款，写在售后政策文档里，三年保修，但有一个例外——特价促销批次是一年。所以「三年」和「一年」其实都可能是对的，取决于产品批次。系统没问清批次就直接答，才会随机给出两个答案之一。
第二步：检查解析质量。 打开售后政策文档的解析结果，发现了一个致命问题——保修条款在一个表格里，表格跨了两页，PDF解析器把表格切成了两段，前半段在「三年」附近断了，后半段的例外条件（促销批次一年）变成了孤立的文本块。向量化之后，这两块文本之间的关联完全丢失。
第三步：检查检索召回。 用「XX型号保修期」做测试检索，召回的前5个片段里，有3个是其他型号的保修信息——因为其他型号的文档里「保修」这个词出现频率更高，向量相似度把不相关的片段顶了上来。真正相关的片段排在第7位，被挤出了上下文窗口。
第四步：检查生成层。 手工把正确片段塞进Prompt测试，发现模型在回答时确实会省略例外条件——给了「三年保修」的答案但不提「促销批次一年」。这是典型的生成层问题：依据在上下文里，但模型没有完整转述。
一个看似简单的「答不准」问题，实际是四个问题叠加：批次条件缺失（数据层）、表格解析断裂（数据层）、召回排序靠后（检索层）、例外条件漏转述（生成层）。如果当时直接换模型，四个问题一个都不会消失。
数据层要回答三个问题：
还有一种隐蔽的数据问题：解析过程丢了信息。常见的丢失点：
| 文档类型 | 常见解析问题 |
|---|---|
| 扫描件PDF | OCR漏识别负号、小数点和特殊符号 |
| 跨页表格 | 表头丢失、单位丢失、行被切断 |
| 带附件的文档 | 附件内容与正文分离，例外条件独立成块 |
| 合同类文档 | 条款编号丢失、适用对象和有效期与条款分离 |
排查技巧：拿一条有明确答案的制度原文，故意把「适用新客户」跟费率表拆开放到不同段落，看系统会不会错误地把费率应用到全部客户。这类针对性测试比泛泛地「感觉不太对」有用得多。
确认答案在索引里之后，再看它有没有被找到。两种失败模式要区分开：
| 失败模式 | 判断方法 | 修法 |
|---|---|---|
| 完全没召回 | 正确片段不在候选集里 | 优化关键词覆盖（型号、术语、同义词）、检查索引是否包含该文档 |
| 召回但排序靠后 | 正确片段在候选集里但排不进Top-K | 优化Reranker、加元数据过滤、去重 |
正确片段根本没进候选集，后面的重排救不了它；候选集里有正确片段但被大量相似材料挤出上下文，才需要优化重排和去重。 两种情况的修法完全不同，混在一起调参就是撞运气。
具体手段：
一个纪律性提醒：不要同时换模型、切分和索引之后只报告最终结果。 三个变量一起动，出了问题你都不知道是哪一步引入的。一次只改一个变量，用同一个测试集复测，这是排查的基本功。
把最终送进模型的上下文和回答逐句核对，看这几类问题：
回答应该区分「依据」「推断」和「待确认事项」，引用要对应到具体结论。只有引用链接而没有内容对应关系，不能算可信证明。
两个方向都要防：既防模型编造（缺乏依据时应该明确说无法确认），也防过度拒答（什么问题都拒绝，就没有业务价值了）。「正确拒答率」和「有依据任务的完成率」要分开评估，混成一个数字没有任何意义。
「准确率90%」这种话在企业场景里没有意义——分母是什么？样本怎么选的？无答案的问题算不算错？
举个计算口径的示例：
这两个比例不是一回事，也都不能说明另外20个问题被正确处理了。 评测表还要单独统计：
| 指标 | 为什么单独统计 |
|---|---|
| 无答案问题的合理拒答率 | 编造一个答案比拒答危害大得多 |
| 权限受限问题的数据泄露 | 这是安全事故，不能用准确率掩盖 |
| 引用可核对性 | 引用与结论是否真的对应 |
| 人工修改工时 | 回答对了但人要改半天，价值也要打折 |
关键风险单独列，不能被平均分掩盖。样本较小时，评测结果只代表这批测试集的表现，不要推广成「所有未来输入的准确率」。
知识库不是一次性工程。长期运行要管三件事：
更新同步。 源系统发布新版本、删除文件、调整部门权限后，索引和缓存要在约定窗口内同步，同步失败要告警。只上传新文件不处理旧版本失效，同一问题会逐渐出现多个答案。 最常见的症状就是本文开头的案例——同一个问题今天答三年、明天答一年。
权限撤除。 权限测试要覆盖完整链路：原文访问、检索、缓存、导出——而不是只在聊天页面隐藏按钮。员工离职后的数据可见性、跨部门查询的隔离、附件下载的授权，都要测。撤权不是把按钮藏起来，而是从数据源头切断访问。
版本回归。 保留未参与调试的测试问题集，覆盖新表述、无答案、冲突资料和权限边界。每次发布前用固定版本复测，发布后抽样核对真实问题。评测记录要包含失败项，不能只留成功问答的截图。
最后说一句实在的：如果基础知识缺失或者业务规则本身没统一，先治理资料，往往比换模型、加参数有效得多。 模型的推理能力再强，也补不齐资料的窟窿。
这篇文章的排查框架参考了 知华科技关于知识库回答质量的完整排查指南，原文对诊断、优化和验收的分层更细，附了常见问题解答。如果你正在建设或优化企业知识库，也可以到 zhuatech.cn 看看他们的企业知识库与RAG服务介绍。
本文案例为脱敏示例，计算口径仅用于说明评测方法，不代表任何具体项目数据。