用确定性计算约束大模型的领域幻觉

AI 产品接上领域资料，也可能一本正经地编造事实。AstralRead 的作者遇到的就是这种问题：用户输入出生日期、时间和地点，模型却会写出不存在的相位、错误的宫位，甚至把两个月前结束的逆行当成当前事件。

作者的解决办法，是让计算引擎负责事实，让模型负责解释，再用代码检查生成结果。这套做法值得程序员借鉴，但需要分清：能验证的是星盘数据与文字是否一致，并不是占星解释本身是否可靠。

能算出来的事实，为什么还要让模型猜

AstralRead 最初的问题不是文风空泛，而是出现了可以直接核对的错误。例如，火星与月亮根本没有四分相，模型却写得十分肯定；金星实际位于第 6 宫，解读里却变成第 7 宫。

作者把这些数据交给 Swiss Ephemeris 计算，包括黄经、星座、宫位、角度，以及每个相位的精确容许度（orb），宫位默认采用 Placidus。行运则逐日计算，起止日期来自星历，而不是模型对 2023 年的记忆。

下面这份事实表，用来限定模型可以解释的内容：

Sun 6°45' Sagittarius, house 5
Mars square Saturn, orb 1.2°, TIGHT
Lilith in Leo, house 12
Transit: Saturn conjunct natal Moon, exact 2026-12-03 (window 11-18 … 12-21)

要看最后一行：精确发生日期与有效窗口已经给定，模型只需解释，不该自行推算时间。

凡是能够确定计算的事实，都应先算好，再交给模型组织语言。

不过，仅靠事实表和提示词仍然不够。作者发现，模型会联想到熟悉的相位组合，把输入中没有的关系顺手补进回答。

生成之后，怎样用代码把错误拦下来

作者增加了一轮输出检查：从解读中提取占星断言，再与计算结果逐条核对。

检查对象包括「某星体位于某星座」「某星体位于第几宫」、相位是否存在及其类型，以及日期是否落在行运窗口内。规则还要容纳领域中的合法分歧，例如天蝎座、水瓶座、双鱼座的传统守护星与现代守护星都被接受。

错误也分情况处理。如果只是装饰性的句子，就删除；如果影响主要解释，就把明确的纠错信息送回模型。例如，指出火星与月亮不存在四分相，并补充月亮最紧密的相位其实是与木星形成三分相，容许度为 0.8°。

这里最有借鉴价值的细节，是作者主要使用正则表达式加一个小型解析器，没有再请另一个 LLM 当裁判。

程序已经掌握结构化真值时，让代码核对通常更容易追踪问题。但原文没有公开解析器、断言覆盖率或漏检数据，因此只能确认实现思路，无法判断它对复杂表达能查得多完整。

解释从哪里来，长回答又该怎么拆

计算只能回答位置与关系，无法决定如何解释。作者为此限定了资料范围：Sergey Vronsky 的 12 卷著作、Howard Sasportas 的 The Twelve Houses、Robert Hand 的 Planets in Transit 等教材。

检索方式也很直接。资料按照实际标题切分，例如「Lilith in Leo」「Mars in the 12th house」，再把对应章节交给模型，减少语义搜索召回相邻主题的情况。

输出还会过两道检查：与来源连续重合约 7 个词就判定不通过，要求重新转述；旧书中的「意志薄弱」「致命」「完全依赖」等宿命式判断，则改写为较温和的心理描述。

完整解读较长，作者又把它拆成人格、爱情、事业、月亮交点、Lilith、Chiron 等部分，每部分配自己的事实块和书籍材料，并行生成。作者称，这改善了模型只顾太阳、月亮，略过其他内容的问题。

速度也有变化：主模型采用开放权重的 Qwen，迁移到快速推理硬件，并配置其他模型组成回退链后，每次解读从 1–2 分钟缩短到约 10–16 秒。但原文没给 Qwen 的具体版本，也没拆分硬件与并行生成各自贡献了多少。

五千页知识库，能证明 AI 搜索有效吗

项目另一部分是约 5,000 页知识库，例如某个星体在特定星座、宫位中的解释。页面同样使用上述书籍和检查规则，结构包含直接回答问题的定义、FAQ 与来源。

每页还有追加 .md 即可访问的 Markdown 版本，站点提供 llms.txt，并通过 IndexNow 推送新页面。

作者从 Bing 的 AI Performance 报告看到，Copilot 在三个月内引用这些页面约一千次，而 Google 仍在缓慢处理收录。这是一个具体的项目观察，说明传统搜索收录之外，还可以查看 AI 引用情况。

但这些措施一起上线，没有对照数据，不能据此认定 .md、llms.txt 或 IndexNow 中的某一项带来了引用。引用次数也不能直接代表访问量、注册量或收入。

我的判断

我最认可的是作者明确划分了责任：计算引擎提供事实，书籍提供解释材料，模型写作，代码核对。相比只在提示词里反复要求「不要编造」，这套设计能把一部分错误变成可定位、可修正的问题。

它也有明显前提。领域需要有可用的计算工具、相对稳定的事实结构，以及能维护的校验规则。开放式建议很难全部转成断言，表达越自由，解析器越容易漏掉隐含错误。多模型回退同样需要验证输出约束是否仍然成立。

限定书目有助于保持解释一致，却不能自动保证解释正确。约 7 个词的重合检查也只能拦截部分直接复制，不能替代版权判断。作者关于覆盖改善、幻觉减少的描述没有对照实验，应当作为工程经验看待。

能拿来做什么

• 开发领域助手时，先列出能够由程序确定的字段，把它们交给计算库或业务代码，再让模型解释结果。
• 在 Node 服务中保留结构化事实，从生成文本中提取关键断言，优先核对日期、数值和实体关系，并记录删除或重试的原因。
• 长报告可以按主题拆分，每段只提供对应事实与材料，同时检查跨段重复和口径冲突。
• 配置模型回退链时，用同一组事实检查规则验证备用模型，避免服务恢复了，内容约束却失效了。