胖头鱼的技术专栏-487 川序最近在忙什么？从找对材料到把话说准（20261111）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

最近在做川序的回答质量分析时，有一类问题让我很在意：资料找到了，也确实送到了模型，回答却还是把意思说错了。

我是做数据库出身的，碰到这种情况，习惯先查数据：从哪里来的，取的是哪一版，当前用户有没有权限，中间有没有少传内容。

川序是一个基于数据库的 AI Agent 管理平台，关系、向量、全文、标签和图关系等融合检索，就是其中的一部分工作。把这些做好，才能让 Agent 找到相关且有权访问的材料，也知道材料来自哪里（这里的“多模融合”说的是这些数据和检索方式，不专指图片、音频等输入）。

但最近的记录里，出现了更让人头疼的情况：故障报告已经写了“后来解决了”，回答还是说“目前正在监控”；本地报告没有拿到根因，到了回答里，却变成了“官方根因字段为空”。

材料找对了，不代表模型就能把它说对。川序近期在回答质量上的一些工作，也就从检查资料有没有找到，继续追到了模型到底怎样使用这些资料。

一、先看模型到底收到了什么

要查清这类问题，得先看到模型实际收到的内容。否则，检索没找到、材料没传完整和模型理解错了，最后都表现为一句“回答不准”，很难知道该改哪里。

川序现在会记录上下文的来源和修订、预算使用情况，以及内容是否完整。其中有一个区别很重要：材料准备好了，和材料已经发给模型了，是两回事。检索结果里能看到某份资料，不能证明它完整地出现在最后的请求中。

在 v5.0.4 的一组故障问答评估中，通过对照最后发出的请求，可以确认完整的本地事实报告已经送到模型。输入内容、材料修订和原始回答都留有记录。这就排除了这组用例中的一个疑点：相关内容没有在发送过程中丢掉。

有了这些记录，就能把原材料、实际输入和回答放在一起，看看究竟从哪一句开始，意思变了。后续该改哪里，也就有了更具体的依据。

不过，这组用例是用明确的事件标识找到材料的， 还不能据此认定所有自然语言提问都能找对资料、传递完整。这里只是把这几个回答的实际输入查清楚了。

二、材料完整仍然会答错

确认材料完整以后，再看回答中的错误，就能发现问题有时只出在几个词上。

这组评估用了两个固定问题，分两轮，共生成了四次回答。第一轮里，模型把已经解决的事件又说成了当前仍在监控，还把可能出现的症状写成了确定的因果关系。

比如，材料里的“可能导致部分请求失败”，删掉“可能”和“部分”，句子依然通顺，意思却已经变了：原本只是可能发生、影响一部分请求，现在成了确定发生，连影响范围也扩大了。

在故障排查里，这种差别可不小。读者可能据此决定是否继续等待恢复，或者沿着一个尚未证实的方向排查。所以我更在意的是这些词有没有用对，而不只是回答读着顺不顺。

第二轮调整了来源摘要和指令，时间和措辞有所改善，但仍然有一句话不对：本地报告没有填上的字段，被说成“根据官方记录，以下字段为空值”。

模型保留了字段名，却把本地报告中的信息说成了官方记录。如果只检查关键词有没有出现，很可能发现不了这种错误。

这四次请求的输入都在约 1900 tokens，也不能简单归因于“上下文太长”。目前这组评估采用的是 AI 评审（尚无独立人工复核，相关报告仍是草稿）。 它帮助我们找到了具体问题，还不足以算出川序的整体错误率，更谈不上证明问题已经解决。

三、空值也有来处

本地报告里的  root_cause，就是一个需要分清来源的字段。它是本地整理报告时定义的，没有取得根因证据，所以留了空值。这说明的是这份报告缺少根因信息。官方接口有没有这个同名字段、取得的官方材料究竟写了什么，还得回到来源去看，不能从本地的空值倒推。

这也提醒我，采集和整理数据时，不能只想着把字段填好。假如只留下一个空值，没有说明是“没有采集到”“材料没有披露”还是“字段不适用”，后面再要求模型分清楚，它也无从知道。

数据从哪里来、适用于什么时候、为什么缺失，和字段的值一样，都需要保留下来。否则，整理后的内容看起来更简洁，回答时却少了判断依据。

类似的误读也可能发生在损失和责任上。没有企业内部损失数据，不能说企业没有损失；建议某个角色评估，也不能写成整改任务已经交给了他。即使回答附着引用，也要看引用的内容是否真的支持这句话，尤其是其中的时间、范围和确定程度。

有时，误导还来自问题本身。比如有人问“为什么这次数据库故障导致业务损失”，问题已经默认了故障类型、因果和损失。如果材料只说明服务异常，回答就得指出哪些前提还没有依据，不能因为问题这样问，就顺着补出一整段原因分析。

四、置信度不能只给一个数

读者面对这样的回答，当然会想知道哪些能信、哪些还要查。给回答附上一个置信度，看起来是个办法，但这个数到底从哪里来？

以川序用到的 RRF 为例，它综合不同检索列表中的名次，帮助决定哪些材料排在前面。 这个排序分数不能直接当成答案正确的概率。即使把分数转换到 0 到 1，含义也没有变。

多路检索都命中，也可能只是同一份材料在不同路径里出现了。找到了好几次，不等于有好几个独立来源互相印证，更不能直接推成答案更可信了多少。

还是拿故障回答来说：事件已经解决，有公告支持；详细根因还没拿到；本企业有没有损失，缺少内部数据；接下来查什么，则可能只是建议。如果笼统地给它一个百分比，比如“置信度 85%”（这里的 85% 只是举例，不是这次评估测出来的数），读者反而不知道该相信哪一部分。

所以我更倾向于先把每一项说明白：什么有材料支持，什么还不知道，什么是推测，推测又依据什么。这样读者才知道后面还需要补哪些信息。换成“高、中、低”也一样，标签得有依据，不能让模型凭感觉换个说法。

如果以后确实需要用概率表达，就得准备独立的同类问题集，检查那些自称有八成把握的判断，实际有多少答对。 模型说自己有把握，也需要验证，不能直接当作结论。

五、让事实少经过一次自由改写

要让回答分清这些情况，光提醒模型“谨慎一点”还不够。我更想尝试的是，把已经能够核对的状态、日期和审批结果保留下来，减少模型重新组织这些事实的机会。

比如，按相应来源和时间直接展示事件的最终状态，同时注明当前材料没有详细根因。模型再围绕这些信息整理线索、解释影响、提出排查建议。这样做是否有效还要验证，但至少要让读者看得出来，哪些是材料中的事实，哪些是模型的分析和建议。

实现时，我不希望另外再维护一份“事实”，让它和原有数据各自更新。川序已经有实体和来源修订记录，也有从候选到审核、发布的流程，应该继续使用这些已有信息。否则，原数据改了，展示给读者的事实卡没改，反而又多出一处不一致。

这类展示比较适合状态和日期，复杂根因仍然得靠证据，几条规则算不出来。涉及根因、损失、责任，或者某项行动是否已经批准、分派时，可以考虑在回答交付前多核对一次：材料真的支持这样说吗？如果不支持，就降低措辞的确定程度、指出缺少什么，必要时先不给出这一项结论。

这些做法还停留在研究建议阶段，也没有列为下一版本的功能承诺。接下来要验证的，是怎样在现有引用和审核机制上，把回答中的具体表述检查得更细。

六、模型能力需要单独比较

除了怎样组织材料，模型本身能不能处理好这些细节，也得比较（这组问答使用的是本地模型）。目前还没有把同一批输入交给更强模型做充分对照。因此，看到错误就决定换模型，依据还不够。

一个模型擅长写代码，不代表它写中文摘要时，也能稳定分清是谁说的、有没有否定、是可能还是确定。判断原因之前，还得查清实际加载的权重和部署配置，不能只看服务名称里的参数标识，就把问题归到参数规模、模型架构、量化或者生成速度上。

比较时可以分开做：固定同一个模型和同一批材料，只调整材料的组织方式，看原来的错误还在不在；再固定输入内容，换一个更强的对照模型，看哪些地方改善了，哪些仍然没做好。

这样才能判断，哪些问题值得先改输入，哪些需要考虑模型升级或任务分工。两边都有成本，我更希望先看清楚错误出在哪里，再决定把精力投到哪里。

有些常用办法也不能省掉这一步。降低温度，可以减少部分随机变化，却不能保证纠正稳定的误读；要求输出 JSON，能约束格式，不能保证里面的内容正确。让模型自查可以辅助，但它也可能把同一个错误再犯一遍。 换成更强模型做复核，也仍然要对照来源，不能直接把它的回答当成标准答案。

至于是否要做专门训练，我觉得还可以往后放一放。先把问题和对照方法确定下来，再看现有办法解决不了的部分还有多少。

七、接下来怎样验证

做这些比较，还需要一组能判断对错的问题。后续如果继续推进，可以先整理二三十个，把事实明确、信息缺失、时间变化、来源冲突，以及建议有没有被批准等情况都放进去。这只是小规模探索的起点，还不足以估计罕见错误，更不能据此承诺产品的服务水平。

我会更关注同一种错误是不是反复出现，以及调整以后是不是真的少了。每次只改一个因素，做少量必要重复，失败的回答也保留下来，不能只挑最好的一次。哪些由 AI 评审、哪些经过人工复核，也要分别记录，方便以后回头查。

不过，评价时不能只盯着它有没有说错，否则很容易把模型调成遇事都说“不确定”。事件已经解决，而且有明确依据，就应该告诉读者；详细根因还没有拿到，只需要说明根因未知，不该连已经知道的状态也一起含糊掉。

有依据的部分要答清楚，没有依据的部分要说明缺什么。所以，后续既要检查模型有没有把未知写成已知，也要看材料已经充分时，它是不是还在不必要地拒答。

总结

最近这部分工作，比较实在的进展是：可以拿着原材料、实际请求和原始回答，去查某个结论究竟在哪里出了问题。时间说错了，还是把本地报告当成了官方记录，已经能在这组用例里具体指出来。但这些问题怎么稳定地减少，还需要继续做对照。

做这件事也让我更清楚，数据库里的来源、版本、状态，到了生成回答时仍然有用。 材料管得再清楚，也还要检查模型有没有按材料的原意来回答。这两部分工作得接起来，不能在资料送到模型时就结束。

目前提出的做法还需要验证，现有记录也不足以保证整体回答质量。我更希望川序接下来能具体说明：改了什么，哪类错误少了，哪些还在。这样才知道下一步该继续做什么。

川序(Chuanxu) db4agent.cn：基于数据库的 AI Agent 管理平台。

老规矩，知道写了些啥。