Chuoer47's Blog

Appearance

InterX - 多粒度问答引擎 ​

上一篇讲完了检索层如何把证据捞回来。但检索只是手段，最终目的是回答用户的问题。这篇来讲 InterX 的核心创新——多粒度集成问答引擎。

说它是核心创新，不是自吹。整个系统最有技术含量的设计决策都在这一层：问题怎么路由、证据怎么分粒度喂给 LLM、三个独立回答怎么融合、幻觉怎么从架构层面压制。

问题路由：不是所有问题都该走 RAG ​

先说一个容易被忽略的问题：用户问"7天无理由退换货的政策是什么"，你让 RAG 去 40 本产品手册里检索，结果只能是"根据手册无法回答"。体验极差。

所以 InterX 在入口处放了一个 LLM 路由器，快速判断问题应该走哪条路：

用户问题
  ├── 有图片 → 跳过路由，直接走 RAG（图片大概率是产品相关）
  ├── LLM 路由 (temperature=0.0, 10s超时)
  │   ├── "manual" → 完整 RAG 流程
  │   └── "general" → 通用客服 LLM 直接回答
  └── 路由失败 → 默认走 RAG（保守策略）

路由策略的设计原则是"松但不随意放行"。如果路由判断失败（超时、解析错误等），默认走 RAG 而不是返回错误。毕竟产品问题走 RAG 大概率能得到有用答案，但通用问题走 RAG 一定会扑空。宁可多走一步检索，也不能让用户看到"无法回答"。

这个路由器用 temperature=0.0 确保判断稳定，10 秒超时防止卡死。实测 24 个用例路由准确率 100%，其中通用客服问题获得了结构严谨的专业回答，产品问题完全不受影响。

多粒度集成回答：核心创新 ​

好，这是整篇文章的重头路。

问题：单次 LLM 调用的困境 ​

传统 RAG 的做法是把检索到的 chunk 拼成一个上下文，调一次 LLM 生成回答。这有个根本矛盾：精确事实和完整上下文需要不同的证据粒度。

用户问"滤网多久清洗一次"，你需要的是一个精确数字（"每两周一次"），塞一大堆背景信息进去反而干扰 LLM 注意力。但用户问"空调制冷差怎么办"，你需要的是完整的排查步骤和操作流程，只给一个碎片根本答不全。

更致命的是，单次生成没有校验机制。LLM 一旦"注意力漂移"就开始编造，在产品安全场景下这不可接受。

方案：三层独立回答 + Ensemble 融合 ​

InterX 的做法是把回答生成拆成三层，每层用不同粒度的证据独立生成，最后融合：

small_chunk 证据 → LLM → small_answer（精确事实，8K 上下文）
mid_chunk 证据  → LLM → mid_answer（操作步骤，12K 上下文）
big_chunk 证据  → LLM → big_answer（背景概述，16K 上下文）
      │                    三者并行执行（ThreadPoolExecutor）
      ▼
ensemble 融合
  · 精确事实取 small，操作步骤取 mid，背景取 big
  · 矛盾时 small > mid > big（特异性优先）
  · 禁止编造三层回答中都不存在的信息

每一层的定位不同：

  • small（220 token chunks, 8K 上下文）：精确事实。型号、参数、安全约束、具体数字。证据粒度最细，LLM 注意力最集中。
  • mid（520 token chunks, 12K 上下文）：操作步骤。多步骤流程、安装指南、故障排查。保留了步骤间的衔接关系。
  • big（900 token chunks, 16K 上下文）：背景概述。完整章节上下文、产品介绍、使用场景。提供全局视野。

三层并行执行，取最慢的那路作为总耗时。实际测试中并行比串行快 3-5 倍。

为什么这能抑制幻觉 ​

三层互相校验的效果是：三个独立调用使用不同证据粒度和 prompt，同时出错且方向一致的概率极低。

假设 LLM 在 small 层编造了"滤网每三天清洗一次"，mid 层和 big 层的证据里大概率没有这个信息。Ensemble 融合时，"禁止编造三层回答中都不存在的信息"这条规则会把这个幻觉过滤掉。

这不是靠 prompt 指令让 LLM "不要编造"（那只是心理安慰），而是从架构层面——多路独立生成 + 规则融合——封堵了幻觉的出口。用工程手段解决 AI 的不确定性问题。

三级幻觉抑制防线 ​

多粒度集成回答只是幻觉抑制的第二级。InterX 实际上有三级防线：

防线层级机制
第一级Prompt 层"Prioritize evidence"、"say so honestly"、禁止暴露内部细节
第二级架构层三层独立回答互相校验 + ensemble 特异性优先
第三级工程层上下文预算控制（small: 8K, mid: 12K, big: 16K），防止注意力稀释

第一级是基本功，告诉 LLM 要以证据为准、不确定就说不知道。第二级是刚才讲的多粒度集成。第三级是工程保障——严格控制每一层的上下文长度，防止 LLM 因为上下文太长而"注意力稀释"，开始在长文本中胡乱抓取信息。

三级防线叠加，幻觉被压缩到极低水平。

上下文预算控制：二分搜索截断 ​

说到上下文预算控制，这里有个工程细节值得展开。

三层回答各自有不同的 token 预算（small 8K, mid 12K, big 16K）。当检索到的证据总长度超出预算时，需要截断。但截断不是简单地"砍掉最后一条"——那样可能把关键证据丢掉。

InterX 用的是二分搜索截断：对最后一条超长证据进行二分搜索，找到一个合适的断点，使得总长度刚好在预算内。同时保证至少保留 1 个 block，不会因为截断把所有证据都删光。

这个设计的妙处在于：它不会粗暴地丢弃证据，而是尽量保留每一条证据的前半部分（通常包含最重要的信息），同时严格遵守预算上限。在实际测试中，英文手册问题的 small 上下文精确地卡在 8,000 字符，正是二分搜索截断的效果。

PIC 占位符协议：图文混排的优雅方案 ​

最后一个细节：图片引用。

LLM 回答中经常需要引用图片（比如"按下图中的按钮"）。但图片不能直接内嵌在 JSON 文本里传给前端——太重了。InterX 设计了一套 <PIC> 占位符协议：

  1. LLM 在回答文本中输出 <PIC> 标记，表示此处需要插入图片
  2. 后端后处理器将 <PIC> 与 images 列表按位置对齐
  3. 前端收到文本（含 <PIC> 占位符）+ 图片 ID 列表
  4. 前端通过 /images/{id} 端点按需加载图片

文本走 JSON（轻量），图片走独立端点（按需）。会话恢复时完整重建 image_ids，历史图片上下文不丢失。

这套协议还处理了 LLM 输出的各种内联标记格式——有时 LLM 会输出 [PIC]、(PIC)、甚至 <img> 标签，后处理器会统一修复为 <PIC> 格式。

真实案例：三层回答长什么样 ​

拿"空调制冷效果差怎么办"这个案例来看三层回答的实际输出：

  • small_answer（272 字符 / 0 图片）：聚焦精确事实——滤网清洁频率、极速制冷模式的具体操作
  • mid_answer（281 字符 / 1 图片）：聚焦操作步骤——4 步改善方法，带图片说明
  • big_answer（119 字符 / 0 图片）：聚焦背景概述——简短的使用环境建议

Ensemble 融合后：281 字符 + 1 张图片。精确事实来自 small，操作步骤来自 mid，背景来自 big。三层信息互补，最终回答既精炼又完整。

再看英文手册案例"How do I use the air fryer for the first time?"：

  • small_answer（544 字符 / 1 图片）：插电、取出锅、不加油等操作细节
  • mid_answer（601 字符 / 2 图片）：完整首次使用步骤流程
  • big_answer（759 字符 / 0 图片）：安全注意事项和背景

Ensemble 融合后：1,233 字符 + 3 张图片。三个粒度的信息被完整融合，图片引用分别对应插电、取出锅、不加油三个操作步骤。

小结 ​

多粒度集成问答引擎的设计哲学是：不指望一次 LLM 调用解决所有问题，而是让三个不同视角的独立回答互相校验，通过规则融合取长补短。 这是从架构层面（而非仅靠 prompt）抑制幻觉的思路。

配合三级幻觉防线、二分搜索截断的上下文预算控制、以及 <PIC> 占位符的图文混排协议，这套问答引擎在实际测试中表现出了很高的可靠性和回答质量。

下一篇我们来看 chat 层——多轮对话管理。当用户连续追问"那个按钮在哪？""按了没反应怎么办？"时，系统怎么保持上下文连贯。