他花3个月治大模型幻觉，发现提示工程是条死路

2023年，SingularityNET团队在Minecraft里放了个叫AIRIS的认知代理。不是玩方块——是它学东西的方式：每一步操作都看得见、追得回。一个开发者读完论文，脑子里蹦出个问题：文字世界能不能复制这套？让AI跟用户一来一往地学，每句话都有据可查？

他试了。失败了。好几次。

第一次尝试堪称洁癖晚期。零外部库、零隐式行为、零随机性，所有组件必须完全确定、完全透明。听起来很原则，实际是条死胡同。任何内部不透明的库都不能用，意味着基础设施得从零手搓。项目变得又慢又脆，维护成本爆炸。概念 purity 正在杀死产品本身。

他退了一步，换了个问法：问题不是外部代码，而是什么样的外部代码。

依赖重新放开，但只准用确定性的、无隐式智能的、行为可预测的。这是第一个真正的转折点。

但项目仍在错误的方向膨胀。组件太多、职责不清、代码碎片化，每次提交都让系统更难理解。某天他猛然意识到：自己在造错的东西。Kremis（他给系统起的名）不该负责生成答案——LLM 已经够擅长这个了。真正的问题是验证。

架构就此翻转。Kremis 变成 sidecar（边车架构）：不生产响应，只验证响应。它坐在 LLM 旁边，检查模型说的话是否锚定在真实数据里。两边严格分离——一边是概率推理，一边是确定性逻辑。

从"造答案"到"验答案"：一个产品经理的顿悟

这个重构让一切豁然开朗。

Kremis 是用 Rust 写的图存储。喂给它结构化数据——实体、属性、值的三元组——它构建确定性图。查询时返回图里有的东西，不发明、不推断。

核心引擎没有随机数、没有浮点运算、没有预加载知识。相同输入，相同输出，每次如此。这个约束让后续一切变得可信。

假设 Kremis 在本地运行。你灌入一些事实：

curl -X POST http://localhost:8080/signals \ -H "Content-Type: application/json" \ -d '{ "signals": [ {"entity_id": 1, "attribute": "name", "value": "Alice"}, {"entity_id": 1, "attribute": "role", "value": "engineer"}, {"entity_id": 1, "attribute": "works_on", "value": "Kremis"} ] }'

图里现在有三条边。你问"Alice 做什么的？"，Kremis 返回"engineer"。不问"Alice 喜欢什么？"——图里没这条边，它不会编。

这听起来像数据库？差远了。传统数据库查的是存储，Kremis 做的是验证：LLM 生成一句话，Kremis 检查这句话能否从图里推导出来。能，放行；不能，打回。

为什么确定性比"更聪明的模型"更重要

开发者圈子里有个幻觉：下一代模型会更强，幻觉会自己消失。这位作者不买账。他的理由很产品经理：用户要的不是"通常对"，是"这次对"。

概率系统的本质是赌。GPT-4 在简单事实问答上的准确率约 70-90%，听起来不错？错了。10-30% 的错误率放在生产环境是灾难。医疗、法律、金融场景里，一次胡说八道就够赔光信任。

Kremis 的解法是把知识层从概率层剥离。LLM 负责语言流畅、意图理解、对话管理——这些它确实擅长。但任何声称的事实，必须过 Kremis 的图验证。验证通过，才呈现给用户；不通过，要么拒绝回答，要么明确标注"这部分我不确定"。

这种架构有个副作用：可审计。每次回答都能追溯到图里的具体边。用户问"为什么你说 Alice 是工程师？"，系统可以展示：entity_id 1 → attribute "role" → value "engineer"，来源是某次 POST 请求。不是黑箱解释，是白箱举证。

作者打了个比方：LLM 像创意总监，点子多、口才好，但偶尔瞎编；Kremis 像法务，每个声明都要过审，没证据的不让往外说。两人搭档，比让创意总监同时干法务靠谱得多。

Rust 不是炫技，是工程约束的必然选择

用 Rust 写图引擎，在 Python 主导的 AI 圈显得格格不入。作者解释过选型逻辑：确定性需要严格的内存安全和无副作用保证，Rust 的所有权模型正好对上。垃圾回收语言有不可预测的停顿，C/C++ 的内存问题会引入难以复现的 bug——这些在验证层都是不可接受的。

更实际的是性能。图查询需要遍历大量边，Rust 的零成本抽象让核心引擎保持紧凑。作者提到早期原型用 Python，验证延迟在百毫秒级；Rust 版本降到个位数毫秒，足够塞进实时对话流。

但技术选型只是表象。深层问题是：当 AI 从 demo 走向产品，什么品质最值得投资？作者的答案是可预测性。用户能接受"我不知道"，不能接受"我瞎编的但说得很有把握"。Kremis 的确定性架构，本质是把"我不知道"的权利还给系统。

这和他早期的洁癖尝试不同。那次是排斥一切外部依赖，这次是精心选择依赖——只选那些行为可证明、版本可锁定的。比如用 serde 做序列化，用 tokio 做异步运行时，都是社区成熟、接口稳定的库。随机性被驱逐到系统边缘，核心保持铁律。

项目开源后，有个反馈让作者意外。有用户把 Kremis 接进客服系统，发现最值钱的不是"拦截幻觉"，是"暴露知识缺口"。图查询返回空，说明组织内部某块知识没数字化——这比 LLM 胡说八道更早暴露问题。

另一个场景是合规。金融客户需要证明"这个投资建议基于哪些数据"，传统 LLM 的注意力权重无法解释，Kremis 的图遍历可以出具审计日志。监管问话时，这是生与死的区别。

作者没宣称解决幻觉。他的原话更克制：Kremis 把幻觉从"系统 bug"变成"可检测事件"。LLM 仍然可能生成图里没有的信息，但系统现在有能力识别、标记、拦截。这是防御性架构，不是根治方案。

至于根治方案是否存在，他持怀疑态度。概率推理和符号验证的杂交，可能是未来几年的主流路线。纯符号 AI 已死，纯概率 AI 不可信，中间地带正在长出新产品形态。

Kremis 的 GitHub 仓库现在有 1.2k star，不算爆款，但评论区活跃着一群奇怪的人：做医疗 AI 的、搞法律科技的、区块链预言机项目的。他们共享同一个痛点——需要 LLM 的灵活性，又承受不起它的任性。

作者最近一条更新是：正在把图查询语言从自定义 DSL 换成 SPARQL 子集，方便对接现有知识图谱。没有宏大叙事，只有具体迭代。