金融RAG系统结构性困境与FoC架构解析

1. 金融RAG系统的结构性困境与破局思路

在金融、医疗等强监管领域，文档通常具有严格的层级结构和复杂的逻辑嵌套。一份标准的保险条款可能包含数十个章节，每个章节下又有层层嵌套的子条款。这种结构化的知识表达方式，恰恰是传统RAG（检索增强生成）系统最棘手的场景。

我们曾遇到一个典型案例：用户询问"主险和附加险在保障范围上的区别"。传统向量检索系统（即使采用Dense+Sparse混合检索+重排序）的表现令人失望——系统返回的所有结果片段都集中在主险的"保险责任"章节，完全遗漏了位于文档第15页的附加险条款。这不是偶然失误，而是架构层面的根本缺陷。

问题本质分析：向量检索本质上是一种"自底向上"的盲搜过程。它将结构严密的文档拆解为数百个独立片段，在语义空间中进行最近邻搜索。这种处理方式丢失了三个关键信息维度：

1. 文档的全局目录结构
2. 章节间的层级关系
3. 条款间的排除与附加关系

当问题涉及跨章节的逻辑对比时，这种碎片化的检索方式就像让盲人摸象——每个片段都真实，但拼凑不出完整图景。在金融场景下，这种结构性缺陷可能导致严重的业务风险。

2. FoC架构设计：双引擎并发检索

2.1 核心设计理念

条款森林（Forest of Clauses，FoC）架构的核心创新在于将文档结构提升为"一等公民"。其设计哲学是：在具有严格层级的专业文档中，结构本身就是最强烈的检索信号。就像人类阅读合同时会先查看目录定位相关章节，FoC让LLM具备同样的"上帝视角"。

技术实现上采用松耦合的双路并发架构：

• Bottom-up向量检索：处理细粒度实体匹配（如特定术语定义）
• Top-down结构检索：通过LLM理解文档整体结构，定位相关章节

两路检索结果在内存中动态合并，形成既保留语义相关性又具备结构完整性的上下文。

2.2 系统架构详解

离线处理流程（Ingestion Phase）

1. 文档解析：使用自研栈式解析器处理非标Markdown文档
2. 树形构建：生成带层级关系的条款森林（ClauseForest）
3. 片段标注：为每个文本块标记clause_id和clause_path
4. 双路存储：
   • 树形结构存入PostgreSQL（JSONB格式）
   • 文本片段向量化后存入Milvus

关键设计：clause_path采用类似"3.10.22"的编码方式，表示"主险→责任免除→故意犯罪"的完整路径。这为后续的碎片溯源提供了GPS定位功能。

在线检索流程

1. 意图识别：轻量级9B模型前置路由
   • 简单事实查询（fact）→ 纯向量检索
   • 复杂逻辑问题（logic）→ 触发双路检索
2. 并发检索：
   • 向量检索：返回相关片段（含clause_path）
   • FoC检索：LLM返回相关条款ID列表
3. 结果融合：
   • 根据clause_path溯源祖先链
   • 从完整树中提取相关子树
   • 生成保留结构关系的"局部盆景"

3. 关键技术实现与性能优化

3.1 非标文档解析的工程突破

金融文档的标题结构极具领域特色："第一部分"、"第一条"、"（一）"等非标形式层出不穷。通用解析工具（如LlamaParse）对此束手无策。我们实现的栈式解析器具有三大创新：

1. 正则引擎优化：设计领域特定的模式匹配规则
2. 单遍扫描算法：时间复杂度严格O(N)

   python复制# 核心栈处理逻辑
   while current_level <= self.stack[-1].level:
       self.stack.pop()
   

3. 单调ID分配：为后续O(logN)级别的节点查找奠定基础

实测中，50页保险条款的解析仅需毫秒级时间，比通用方案快2个数量级。

3.2 确定性输出保障

在结构检索阶段，LLM需要根据文档目录返回相关条款ID列表。高并发场景下，即使35B模型也容易出现JSON输出异常（失败率约15%）。我们通过三重保障解决该问题：

1. Prompt工程：设计极简的Markdown目录模板
2. Guided Decoding：集成vLLM的有限状态机(FSM)约束
3. 输出校验：强制符合预设JSON Schema

最终将结构化输出的成功率提升至100%，满足金融级稳定性要求。

3.3 长上下文性能压榨

6K tokens的条款树干直接喂给LLM会导致首字延迟(TTFT)飙升。我们采用vLLM的Prefix Caching技术实现突破性优化：

技术原理：

• 将Prompt分为固定部分（条款树干）和可变部分（用户问题）
• 固定部分的KV Cache在首次计算后缓存复用
• 后续请求只需计算新增的几十个token

性能对比（Qwen3.5-35B, RTX PRO 6000 96GiB）：

该优化使单卡并发能力从c≤16提升至c≥32，且TTFT稳定在毫秒级，彻底消除了长文本处理的性能瓶颈。

4. 架构对比与选型思考

4.1 与RAPTOR的差异化设计

斯坦福的RAPTOR方案同样采用树形检索思路，但与FoC存在本质区别：

4.2 金融场景的特殊考量

金融RAG系统需要平衡三个核心诉求：

1. 准确性：不能遗漏关键条款
2. 可解释性：每项结论必须可溯源
3. 合规性：禁止擅自生成法律条款

FoC通过物理结构解析和确定性输出，完美契合这三点要求。而基于语义聚类的方案可能在合规性上存在风险。

5. 实施建议与避坑指南

5.1 部署实践要点

1. 冷启动优化：

   • 预先解析高频文档并缓存解析树
   • 对条款树干进行预计算和缓存

2. 资源分配策略：

   • 向量检索和结构检索使用独立资源池
   • 根据业务特点调整双路检索的触发阈值

3. 监控指标：

   • 结构检索命中率
   • 子树平均大小
   • Prefix Cache命中率

5.2 常见问题排查

问题1：LLM路由结果不稳定

• 检查Prompt模板是否清晰标注层级关系
• 验证Guided Decoding的FSM设计是否合理

问题2：高并发时延迟波动大

• 检查vLLM的Cache配置是否正确
• 监控GPU显存带宽利用率

问题3：碎片溯源失败

• 确认clause_path编码规则一致性
• 检查PostgreSQL的JSONB索引状态

6. 领域应用的扩展思考

FoC架构的价值不仅限于保险条款。任何具有严格层级的专业文档都可受益：

• 法律合同：条款引用与责任界定
• 医疗指南：治疗方案的多级决策树
• 金融报告：财务数据的层级关联分析

我们在开源实现中保留了架构的扩展性，开发者可以通过实现新的Parser适配不同领域的文档结构。一个值得探索的方向是将FoC与多智能体系统结合，让不同Agent分别处理不同层级的语义理解。