给客服助手补上一段退款规则

你让一个客服助手回答“订单超过七天还能退款吗”，它很快给出了肯定的答复，还补充了申请步骤。文字很顺，但公司的实际规则可能完全不同。问题不一定是模型没听懂，而是它没有拿到这家公司的退款政策，却仍然生成了一个看起来合理的答案。

减少这类幻觉，一个实用的起点是：先给模型相关资料，再让它根据资料回答。这就是用有依据的上下文约束回答。它不能保证每句话都正确，但能让回答有可查的来源，也让错误更容易被发现。

§ 上下文是这次回答能参考的材料

这里的上下文，可以是一段退款规则、一页产品说明，也可以是从订单系统查询到的结果。它不是一句“请准确回答”，而是完成任务需要的具体事实。

例如，与其只问“超过七天还能退款吗”，不如同时提供：“退款规则，更新于六月一日：未使用的商品可在签收后七天内申请退款；质量问题需转人工处理。”再补上用户的问题和必要的订单信息。

这样，模型就不必凭常见的电商经验补全规则。不过，资料没有说明的情况，仍然不能被当成已经允许或禁止。

对初学者来说，不必一开始就搭建复杂系统。可以先手动挑选一小段可靠资料，与问题一起发送，并加入几条明确要求：

最后一条很重要。网页、附件或用户上传的文件里，可能出现“忽略此前要求”这样的文字。它们属于待处理的内容，不应该获得修改助手行为规则的权限。

假设用户只说“买了十天”，资料却以签收时间作为退款期限的起点。此时，合适的回答不是直接拒绝退款，而是说明：“现有规则按签收时间计算，需要先确认签收日期。”如果用户提到质量问题，则应指出资料要求转人工处理，而不是自行承诺退款。

好的保留意见会指出缺失的信息，并给出下一步。它既不假装确定，也不把所有问题都推回给用户。这样的回答往往比一个流畅但没有依据的结论更有帮助。

当知识库只有几页时，人工选择资料通常已经够用。文档变多后，可以先搜索与问题相关的片段，再把片段交给模型。这种做法通常称为检索增强生成。

检索并不等于验证。系统可能找到旧版本、相似产品的说明，或缺少例外条款的段落。每个片段最好保留文档名称、更新时间和适用范围，必要时带上相邻段落。重点不是塞入更多文字，而是给出足够且相关的依据。

模型标注了来源，不代表来源真的支持结论。可以检查：引用是否确实存在，原文是否支持回答，是否遗漏了限制条件。对于退款资格、金额或账户状态，尽量由业务系统计算或查询，模型主要负责解释结果。

上线前，准备几道小测试：资料里有明确答案的问题、资料没有答案的问题，以及资料相互冲突的问题。观察助手能否分别回答、承认不足和提示冲突，比只看一次演示是否顺畅更有价值。

在 Vana API 中，你可以通过兼容 OpenAI 的接口发送问题和参考材料，沿用现有 SDK，先测试这套流程。切换模型不会自动补齐缺失的公司政策；应先检查资料是否正确、相关、完整，再判断是否需要调整模型。

如果想亲自试一次，可以创建 Vana API 账户，选一段真实但不含敏感信息的业务说明，分别测试有资料和无资料时的回答。记录哪些结论能追溯到原文，哪些地方仍需追问。减少幻觉，往往就从这样一段可核对的上下文开始。