Chuoer47's Blog

Appearance

InterX - 项目概述与架构 ​

什么是 InterX ​

InterX 是一个端到端的产品手册智能客服系统。简单来说，它做的事情是：用户用自然语言提问（支持中英文），系统从 40 份产品手册中检索相关证据，由 LLM 生成带图片引用的回答，并且支持多轮对话。

听起来好像没什么特别的？市面上 RAG 方案一抓一大把。但真正做过的人都知道，从"能跑"到"好用"之间隔着无数坑。InterX 要解决的，正是这些坑。

核心痛点：为什么不能直接用通用 RAG ​

在动手之前，我们梳理了产品手册问答场景下的 7 个核心痛点。这些不是理论推演，而是实际踩过的坑：

1. 数据质量差。 赛题给的原始数据没有结构化文件，图文不匹配、OCR 残留伪影、页眉错位……直接喂给 RAG 的话，垃圾进垃圾出，检索和回答质量根本没法保障。

2. 检索精度不足。 用户问"化油器怎么调"，手册里写的是"化油器调节螺钉位于……"，关键词对不上。纯 BM25 靠字面匹配，Dense 向量又把精确术语给平滑掉了。

3. 幻觉风险高。 LLM 编造操作步骤在通用场景下可能只是闹笑话，但在产品安全相关场景下后果很严重。单次生成没有校验机制，等于裸奔。

4. 跨章节推理困难。 "制冷差"的原因在故障排查章节，解决方案在维护保养章节。首跳检索只命中单一章节，答案不完整。

5. 通用问题混入。 用户问退货政策、物流问题，RAG 返回"手册中未找到"——体验极差。所有问题都走 RAG 没有路由分流是不行的。

6. 多轮上下文丢失。 "那个按钮在哪？""按了没反应怎么办？"——简单拼接历史，LLM 根本不知道"那个"指的是什么。

7. 系统延迟高。 多层 LLM 调用（检索 + 回答 + 改写）叠加起来，端到端延迟几十秒，用户早就走了。

这 7 个痛点基本覆盖了从数据到检索到生成到交互的全链路。InterX 的每一层设计都是在回应这些痛点。

系统架构概览 ​

InterX 采用分层架构，从底到顶依次是：

用户 --> web (Streamlit UI)
           |
           v
        chat (多轮对话编排)
           |--> 查询改写（历史感知）
           v
        answer (多粒度集成问答)
           |--> retrieval (Dense + BM25 + Rerank)
           |--> kg (知识图谱扩展，可选)
           |--> LLM 三层并行生成 + ensemble 融合
           v
        gateway (LiteLLM 统一 LLM 网关)
           |--> 多上游路由（MiMo / DashScope / GPT-5.5）
           |--> 语义缓存（精确匹配 + LLM 等价判断）
           v
        上游 LLM API

核心思路是 分层解耦 + 并行加速 + 全链路容错。每一层独立可替换，任何一层出问题都不会拖垮整个系统。

模块一览 ​

模块职责对应痛点
process数据预处理：Markdown 解析、三级 chunk、向量嵌入、Milvus 入库数据质量差
retrieval多通道检索：Dense + BM25 融合 + Rerank 重排，三级层次聚合检索精度不足
kg知识图谱：Kuzu 图数据库，LLM 语义关系提取，多跳图遍历扩展跨章节推理困难
answer问答引擎：路由判断 + 查询改写 + 三层并行 LLM 回答 + ensemble 融合幻觉风险、通用问题混入
chat对话层：会话管理、记忆策略（滑动窗口/摘要）、查询改写多轮上下文丢失
gatewayLLM 网关：LiteLLM 代理、多上游路由、语义缓存、Prometheus 监控系统延迟高
web前端 UI：Streamlit 聊天界面，支持图片上传和会话管理用户交互

每个模块都有自己的 .env 配置和独立的 Python 虚拟环境，可以单独开发和测试。模块间通过 HTTP API 通信，不共享内存状态。

数据流：从问题到回答 ​

以一个真实场景来走一遍完整链路。用户问："空调制冷效果差怎么办？"

Step 1 - 路由判断。 问题到达 answer 模块后，先由 LLM 路由器判断是产品手册问题还是通用客服问题。这里判断为 manual，进入 RAG 流程。如果是"7天无理由退换货政策"这类通用问题，会直接走通用 LLM 回答，不浪费检索资源。

Step 2 - 查询改写。 LLM 生成 3 个查询变体：

  • 同义改写："空调制冷效果不好该如何处理？"
  • 跨语言翻译："What should I do if my air conditioner isn't cooling?"
  • 具体分解："空调制冷效果差是否因为滤网堵塞或制冷剂不足？"

多变体检索显著提高了召回率。

Step 3 - 层级检索。 retrieval 模块同时执行 Dense 向量检索（Milvus 1024 维）和 BM25 检索（五重分词），通过 RRF 融合后送入 Rerank 重排。最终得到 small_hits 28 个、mid_hits 5 个、big_hits 3 个。

Step 4 - 知识图谱扩展。 kg 模块对首跳命中的 chunk 做 BFS 图遍历，通过 CO_EVIDENCE 共现边和 SEMANTIC 语义边扩展出 8 个跨章节关联 chunk。这些 chunk 补充了首跳检索遗漏的证据。

Step 5 - 三层并行回答。 三个独立的 LLM 调用同时执行：

  • small（精确事实，8K 上下文）：272 字符 / 0 图片
  • mid（操作步骤，12K 上下文）：281 字符 / 1 图片
  • big（背景概述，16K 上下文）：119 字符 / 0 图片

Step 6 - Ensemble 融合。 精确事实取 small，操作步骤取 mid，背景取 big。矛盾时 small > mid > big（特异性优先）。最终输出 281 字符 + 1 张图片的回答。

整个流程走完大约 64.6 秒，其中路由 7.4s、检索 13.7s、三层并行回答（并行执行，取最慢的那路）。后续文章会详细拆解每一层的实现细节。

小结 ​

InterX 的核心设计理念是：不指望一个银弹解决所有问题，而是每一层针对性地解决一个痛点，通过分层架构把它们串联起来。 数据层解决质量问题，检索层解决精度问题，图谱层解决跨章节问题，问答层解决幻觉问题，对话层解决上下文问题，网关层解决延迟问题。

下一篇我们从最底层开始——数据预处理。看看 InterX 是如何把一堆脏乱差的原始 Markdown 变成高质量的向量知识库的。