库里没有能支撑的段落时，模型应当拒绝

不知道却回答的模型不是功能。那是语气好听的责任。在我运行的系统里，问题可以空手回来。有用的行为是：段落在库里就给引用，不在就拒绝。

先检索，后措辞

这个模式故意无聊。拿起问题。找出可能装着答案的段落。给它们打分。如果没有一段真正支撑一个说法，就停。如果有一段支撑，就把那段放在用了它的句子旁边。句子不是来源。段落才是来源。打不开那段的读者不能信任句子，也不该被要求去信任。

我运行的训练系统就是这样建的：材料进去，计划对准一个日期，答案对照来源打分，复习在材料被忘掉之前到来。对文档的提问也该这样。有依据，或者沉默。猜测在演示里显得有用，而客户照着做的第一周就会很贵。

云端模型会看到数据。在那之前，数据流要写下来：哪个服务、谁的密钥、每月上限是多少。同意是明确的。凡是碰到客户、价格或订单的，都等一个人。调用会记入日志，因为「助手这么说的」不是审计痕迹。

我不保证这会把网站放进别人的回答框里。排名是另一台机器，激励不由我控制。我能控制的，是我自己的系统会不会编造。

说得顺不值钱。产品是你能打开的那段原文。

得有人定下「接近」变成「不够好」的那一点。我不把这件事交给模型的心情。一段要么越过我能说明的杠，要么答案被扣下。我宁可向用户解释一次拒绝，也不解释他照着做了的步骤里有一步是编的。杠可以在您见过真实问题之后再调。它不该从零开始，演示喜欢住在零那里，因为演示是按它开口的次数打分的。

当一次处理是另一种不确定，是低置信度的抽取而不是空库时，我把它暂停给一个人，而不是再付钱做一次听起来更顺的尝试。更顺不等于更真。日志留下第一次尝试，让人看见取回了什么、丢掉了什么。

模型被训练成要帮忙，也就是它们宁可把段落写完。应用必须比模型不客气。一个阈值、一处缺失的引用、一次空的检索：每一条都是不返回答案、并记下原因的分支。如果没有这条分支，系统最终会回答库里支撑不了的问题，而且听起来很有把握。

您第一次看到它拒绝时，会觉得这是个故障。其实相反。真正的故障，是那段自信、却无处可点的文字。