不给AI幻觉留余地：纯代码审核的网站客服机器人

加拿大航空曾试图让法庭相信，其网站客服机器人说的话不代表公司立场。法庭驳回这一抗辩，裁定企业必须为其网站上的一切内容负责，包括AI机器人的回答。这个判例给所有部署网站客服机器人的企业划下了一条红线：机器人说错话，后果由企业承担。

对于小型企业，这个风险尤为致命。一个编造出来的营业时间或捏造的价格，造成的损失可能远超机器人节省的人力成本。一位开发者为此构建了一个演示项目Front Desk，核心思路是：让语言模型只负责起草回答，最终呈现给顾客的内容由确定性代码审核决定。

四步流程：把模型关进代码的笼子里

检索：无匹配就不让模型参与

Front Desk的演示场景是一家虚构的"Juniper Street Bakery"烘焙店。整个"网站"只有13条简短条目，涵盖营业时间、价格、蛋糕、过敏原、配送和支付信息。机器人只掌握这些内容，对其他知识一无所知。

用户提问后，第一步由代码从这13条中匹配最多三条相关条目。如果没有任何条目匹配，模型根本不会被调用，顾客直接收到电话联系方式。这一步从源头上杜绝了模型在知识空白区自由发挥的可能。

起草：模型只做填空题

语言模型基于匹配到的条目生成JSON格式的回答，包含三个字段：回答文本、引用的条目ID、以及答案所依据的原文句子。模型被限定为"只读"选定的条目，温度设为零，尽可能减少随机性。

温度（Temperature） 是大语言模型的一个采样参数，通常取值在 0 到 1（或 0 到 2）之间，用于控制输出的随机性。温度越低，模型越倾向于选择概率最高的下一个词，输出越确定、越保守；温度越高，低概率词被选中的机会增大，输出更发散、更有创意，但也更容易出现不一致甚至幻觉。当温度设为零时，模型在每一步都确定性地选择概率最高的词元，相同输入几乎总能得到相同输出，这被称为贪心解码。在需要事实准确、格式稳定的场景（如客服起草、结构化抽取、代码生成）中，通常会把温度调低甚至设为零，以换取可复现性和可靠性；而在创意写作、头脑风暴等任务中则相反。需要说明的是，温度为零并不能消除幻觉，它只是减少随机波动，让模型在已有知识误导下稳定地给出同样错误的答案，因此仍需外部校验机制兜底。

三重校验：句子、数字、词表

这是整个系统最关键的环节。模型起草的回答要经过三道独立检查：

• 句子校验：引用的句子必须逐字出现在对应条目中。
• 数字校验：回答中的每个数字都必须能在引用条目中找到对应。"4 pm"等同"16:00"，但"$4"不等于"$4.50"。
• 词汇校验：所有承载语义的词语必须出现在模型获取的材料中。

任何一项检查失败，草稿即被丢弃。第一步失败时，顾客看到的是条目原文或联系方式；后续句子失败时，该句被直接截断。

在自然语言处理中，分词（Tokenization） 指把一段文本切分成更小的单元（词元），既可以是词，也可以是子词或字符，是词表校验等文本比对操作的基础。英语中以空格分词较为简单，但涉及缩写、连字符、标点时仍需谨慎；而在中文、日文等语言中，词语之间没有空格，必须依赖分词算法（如基于词典、统计或神经网络的分词器）才能得到有意义的词语边界。分词策略直接决定了词汇校验的粒度：切得过粗会漏掉伪造内容，切得过细又会把无实义的碎片误判为语义词，导致误报。此外，同义词、词形变化（如复数、时态）和跨语言混写也会影响匹配。正因如此，文中提到的词汇校验在非英语场景下需要专门设计分词与词形归一化方案，否则可能出现中文回答里每个字都在原文、但整句含义已被曲解的情况。

降级：宁可不说，不可说错

校验失败后的降级策略体现了这个系统的设计哲学。机器人不会试图"修复"回答，而是回退到展示原始条目文字。这种保守策略意味着机器人有时会显得"笨"，但它从不说没有依据的话。

测试数据揭示的问题

开发者编写了24个已知答案的测试问题，其中6个涉及网站从未提及的内容（披萨、会员卡、圣诞营业时间）。

第一轮测试正确率17/24。主要失分原因并非幻觉，而是模型把"我们没有这项服务"错误地标记为"无法回答"。调整为更精确的规则后，第二轮提升至21/24。

但第二轮暴露了一个真实的漏洞。当被问及"你们有会员卡吗？"时，模型回答"不，我们没有会员卡"——网站对此只字未提。由于这句话没有数字，数字校验放行了。这正是词汇校验的由来："loyalty"不在模型获取的任何材料中，因此该句被判定为无依据。

加入校验规则后，开发者新增7个未调优的问题，31题在线运行正确28题。其中一个失败源于开发者自身的bug：模型输出"$8.00"而网站写的是"$8"，数字校验将其判为不匹配。修复后，同样的草稿通过29/31。

剩余两个失败案例值得关注，因为校验机制无法捕捉：

• "圣诞节营业吗？"机器人给出了常规营业时间。每个词都在网站上，但不是用户要的答案。
• "肉桂卷是纯素的吗？"机器人正确回答了"不"，但引用的依据指向糕点价格条目而非纯素条目。

这类错误的核心问题是：一个每个词都有出处但方向完全错误的回答，能顺利通过所有自动检查。开发者由此得出结论：这类机器人上线前需要用企业真实客户问题构建测试集，而不仅仅依赖好的提示词。

小企业真的有聊天机器人吗？

开发者从OpenStreetMap抓取了奥斯汀1020家商业网站（咖啡馆、餐厅、牙医、诊所、沙龙、烘焙店），剔除了共用域名的连锁品牌，对每个首页发起一次请求。592个成功加载，其中27个有任何聊天组件，15个是Wix内置的店主聊天功能。唯一能识别为AI助手的，全部来自连锁品牌网站。

聊天机器人市场看似拥挤，但本地咖啡馆绝大多数根本没有助手。这个发现指向一个现实：最需要这类工具的小商户，恰恰是渗透率最低的群体。

OpenStreetMap（OSM） 是一个由全球志愿者共同编辑的开源地图数据库，遵循开放数据许可，允许任何人自由获取、使用和再分发其地理数据。它通过 Overpass API 等接口支持按区域和类别批量查询兴趣点（POI），例如某城市内所有标注为咖啡馆、餐厅或牙医的商户及其网站字段。相比商业地图数据，OSM 的覆盖度和字段完整性因地区而异，商户的官网链接可能缺失、过时或指向第三方平台，因此基于它做的抽样调研会存在一定偏差，不能完全等同于官方工商名录。不过，对于开发者个人进行低成本、可复现的行业摸底，OSM 是少数无需申请商业授权即可大规模拉取结构化商户数据的来源之一，文中对奥斯汀上千家商业网站的抓取正是借助这一途径完成的。

无模型模式：连AI都不需要

基于这一观察，开发者提供了第二种运行模式。整个组件只需一个script标签。不配置模型端点时，它运行在"引用模式"下：找到匹配条目后逐字展示，或提供电话联系方式。它无法编造任何内容，每次提问零成本。

在31个测试问题上，引用模式29次展示正确条目或拒绝回答。但开发者提醒，这些问题在调优搜索词时已被使用过，新网站上表现可能下降。配置模型端点后，组件会执行起草和校验流程，校验失败时自动回退到引用模式。

值得思考的设计取舍

这个项目的价值不在于技术复杂度，而在于它对AI落地边界的清醒认知。当模型能力不足以可靠地处理某个场景时，用确定性代码兜底比优化提示词更务实。

几个值得进一步探讨的方向：校验层能否处理多条目组合回答？词汇校验在非英语场景下的分词策略如何设计？测试集的构建成本对小商户是否可接受？开发者本人在文末抛出了一个问题："你们还会检查哪些我没有检查的东西？"