03 - RAG 与 RAGFlow 集成技术深挖篇

核心定位：深度剖析以 RAGFlow 为底座的业务封装、文档深度解析、混合检索（BM25+向量）、重排、Query 改写、引用溯源与高可用降级。

Q1: 为什么选型 RAGFlow 作为知识库和 RAG 底座？相比于从零自研或 LangChain/LlamaIndex、Dify，RAGFlow 的核心优势是什么？

回答（求职者口吻）：
选型 RAGFlow 是基于我们对政务严肃业务场景深思熟虑后的架构决策：

1. 解决“垃圾进垃圾出”（Garbage In, Garbage Out）的文档解析痛点：
   - 传统基于 LangChain/LlamaIndex 搭建的 RAG 系统，最脆弱的环节在于 PDF/Word 复杂排版解析。政务公文大量包含“红头公文头、多级编号标题、跨页表格、双栏排版、公章与附录”。普通的纯文本切片或简单正则切分会导致表格断裂、标题与正文脱节。RAGFlow 核心优势在于其基于深度学习版面分析（DeepDoc / Vision-based Layout Analysis）的深度文档解析能力，能够精准识别表格结构、段落层级和文档元数据，从源头保证了高质量分块。
2. 开箱即用的工业级混合检索与重排管道：
   - RAGFlow 原生集成了“稠密向量（Dense Vector）+ 稀疏关键词（BM25/Elasticsearch）+ Reranker（交叉编码重排）”的完整 Pipeline，并支持多模态与 OCR，避免了我们在底层去重复拼装 Elasticsearch、Milvus/Infinity 与重排模型的巨大工作量。
3. 清晰的架构边界：
   - 与 Dify 偏向轻量化可视化应用编排不同，RAGFlow 更加专注于“高质量知识库与检索底座”。我们团队选择“复用 RAGFlow 的知识库解析与混合检索能力，自研上层业务编排、多租户权限隔离、流式会话控制与政务 Task Agent”，这是技术投入产出比最高的方案。

Q2: 既然 RAGFlow 已经提供了底座能力，你们业务后端（Go/Python）到底在 RAGFlow 之上封装了哪些核心能力？未重复造轮子的边界在哪里？

回答（求职者口吻）：
我们严格恪守“下层复用底座能力，上层聚焦业务价值”的边界原则：

• 底座负责（不重复造轮子）：
• 文档的 OCR、版面分析与结构化提取；
• 文本的分块（Chunking）、Embedding 向量化生成；
• 底层向量索引（Infinity/Milvus）与全文检索索引的构建与混合检索计算。
• 业务后端（Go/Python）核心自研封装能力：
  1. 多租户与组织权限注入（Permission Injection）：RAGFlow 本身缺乏与政务复杂组织架构（科室、密级、租户）深度绑定的鉴权。我们在业务层拦截检索请求，将当前登录用户的组织权限动态转化为过滤表达式（Filter DSL），在向 RAG 底座发起检索时精准限制可见知识域。
  2. 多轮对话上下文治理与 Query 改写：维护会话窗口滑动、滑动窗口内的摘要提炼、针对代词指代消解与政务专业实体扩充后的 Query Rewriting。
  3. 细粒度引用溯源与元数据重构：将 RAGFlow 返回的原始分块数据，与业务数据库中的政策印发日期、发文字号、有效性状态进行二次组装，生成带格式的引用卡片。
  4. 高可用降级与超时熔断：封装统一的 RAGFlow Client，实现连接池管理、指数退避重试、检索相关性阈值拦截与大模型不可用时的兜底流式降级。
  5. 业务 Task Agent 状态机：在 RAG 检索能力之上编排复杂多步任务（政策对比、案例对标）。

Q3: 政策公文和政务材料通常有复杂红头、多级条款和表格，你们在分块（Chunking）大小和策略上做了哪些针对性调优？

回答（求职者口吻）：
在分块策略上，我们坚决摒弃了“固定字符长度硬切（如固定 512 字符 + 10% overlap）”的简单做法，而是采用了“基于文档语义结构的针对性分块（Template-Aware Chunking）”：

1. 法规条款型文档（Law & Regulation Chunking）：
   - 依据“章-节-条-款-项”的法定公文层级进行结构化分块。每个 Chunk 的原子单位精确到“第 X 条”。同时，将上一级的“第 X 章 X 规定”作为元数据（Contextual Header）前置注入到每一个 Chunk 开头。这样即使第 3 条只有简短的一句话，向量化后也包含完整的上下文语义，彻底避免“断章取义”。
2. 表格与清单型文档（Table Chunking）：
   - 利用 RAGFlow 的 Table 结构识别能力，将表格的表头与每一行数据渲染为完整的结构化句子或 Markdown 格式（如：“【企业类型】：制造业小型企业，【增值税加计抵减比例】：5%，【施行期限】：2024-12-31”），保证检索单行数据时表头上下文不丢失。
3. 块大小（Chunk Size）与重叠度权衡：
   - 核心条款 Chunk 大小控制在 300 ~ 600 个 Token 之间。太小会导致语义破碎，太大会稀释关键语义并增加 LLM 上下文负担。同时设置 15% 的滑动重叠窗口（Overlap），防止边界处的关键语句被截断。

Q4: 详细讲讲你们的混合检索（Hybrid Search）机制：稠密向量检索与 BM25 关键词检索是如何结合与加权融合的？

回答（求职者口吻）：
在严肃政务场景下，单一的向量检索或 BM25 都存在明显短板：
- 向量检索（Dense Retrieval）：擅长语义相似度、口语化泛化理解，但对特定“发文字号（如国办发〔2024〕12号）”、“精确法条号（如第三十二条第二款）”、“专有名词（如专精特新、留抵退税）”的精确匹配能力较弱，容易产生语义漂移。
- BM25 关键词检索（Sparse Retrieval）：对专有名词、编号命中率极高，但无法理解同义词和口语化表达。

因此我们采用了“双路并行召回 + RRF（Reciprocal Rank Fusion）倒数排名融合”机制：
1. 双路召回：
- 业务后端将经过改写后的 Query 同时送入向量索引引擎（Top-50）和全文检索引擎（Top-50）。
2. 分值归一化与 RRF 融合：
- 由于向量距离（如余弦相似度 0~1）与 BM25 分数（0~正无穷）量纲不一致，直接线性加权容易受极端值干扰。我们采用 RRF 算法计算综合分：
$$RRF_Score(d) = \sum_{m \in {Dense, BM25}} \frac{w_m}{k + rank_m(d)}$$
- 其中常数 $k=60$，$w_{Dense}$ 和 $w_{BM25}$ 在政务场景下分别配置为 0.5 和 0.5（若用户输入中包含明显的文件编号正则，动态调高 BM25 权重至 0.7）。
3. 合并去重：聚合双路结果，去除重复 Chunk，保留 Top-30 进入下一步 Rerank。

Q5: 什么是重排（Rerank）？为什么在向量和 BM25 召回之后，还必须加一层 Cross-Encoder 重排模型？

回答（求职者口吻）：
召回阶段（Embedding / BM25）的核心目标是“保证高召回率（Recall），速度极快但精度相对粗糙”，属于双塔结构（Bi-Encoder），Query 和 Document 是分别独立编码的，缺乏深度的交互计算。

重排模型（Reranker，如 bge-reranker-large）采用交叉编码器结构（Cross-Encoder），将 [CLS] Query [SEP] Document [SEP] 拼接后送入 Transformer 进行全注意力交互，能够精准捕捉词与词之间的精细因果关系与语义依赖：
1. 剔除语义漂移分块：很多时候向量相似度虽然高（比如都讨论“公积金”），但内容讨论的是“公积金提取条件”，而用户问的是“公积金贷款利率”，重排模型能精准识别出这种细微差异并将真正相关的文档排到最前。
2. 压缩输入上下文（降低 Token 消耗并防幻觉）：通过 Rerank，我们将召回的 30 个候选 Chunk 精确压缩至最相关的 Top-3 ~ Top-5（总 Token 量控制在 1500 以内），既避免了过多无关信息导致大模型“大海捞针（Lost in the Middle）”产生幻觉，又显著降低了大模型推理延迟与 Token 成本。

Q6: 在多轮对话中，用户说“那这个文件的第二条是什么”、“需要哪些材料”，系统是如何进行 Query 改写（Query Rewriting）与指代消解的？

回答（求职者口吻）：
多轮对话中用户的输入往往存在严重的“指代词（这个、该政策、其）”和“上下文省略”。如果直接拿当前句去向量库检索，召回率几乎为零。

我们的解决方案是“基于滑动会话历史的轻量 LLM Query 改写”：
1. 上下文提取：从 Redis 中提取当前会话最近 3 轮的完整问答以及上一轮命中引用的核心元数据（如上一轮讨论的文件名《武汉市支持专精特新企业发展若干措施》）。
2. 结构化 Prompt 改写提示词：
- 构造专门的 Few-Shot 改写 Prompt：“根据历史对话上下文，将用户的最新简略提问改写为一个语义独立、包含完整实体与限定条件的自包含查询语句（Self-Contained Query）；禁止回答问题本身，仅输出改写后的 Query。”
- 示例：
- 上文：“《武汉市专精特新培育办法》什么时候施行？” -> 回复：“2024年1月1日。”
- 当前输入：“第二条是什么？”
- 改写输出：“《武汉市专精特新培育办法》 第二条 具体内容 条款规定”
3. 改写后并行驱动检索：改写后的独立 Query 用于 RAGFlow 检索，而前端界面依然向用户展示其原始口语提问，保证用户交互的自然流畅。

Q7: 引用溯源（Citation / Provenance Grounding）在技术上是如何实现的？如何精准定位到某篇文档的第几页、哪个 Chunk 并高亮原文？

回答（求职者口吻）：
引用溯源是政务严肃问答的生命线。我们的技术实现链路如下：

1. 分块入库时的唯一坐标绑定（Indexing Phase）：
   - 文档在 RAGFlow 解析入库时，每一个 Chunk 会生成全局唯一 chunk_id，并记录其物理位置元数据：doc_id、doc_name、page_num（页码范围）、bbox（PDF 页面中的坐标边界框矩形 $[x0, y0, x1, y1]$）以及 char_offset（字符偏移量）。
2. Prompt 引用注入（Prompt Construction）：
   - 在将 Top-K Chunk 组装入 Prompt 时，为每个 Chunk 标注显式编号：
   【参考片段 1】(Doc: 武汉政策.pdf, Page: 3, ID: c_101): 内容... 【参考片段 2】(Doc: 实施细则.pdf, Page: 7, ID: c_102): 内容...
   - 要求模型在回答时，必须在关键句后标注引用标签，如 根据相关规定[1]，企业可申请...。
3. 后端流式解析与映射（Streaming Processing）：
   - 后端在接收 LLM 的 SSE 流式 token 时，通过正则流式拦截器捕获 [1]、[2] 标签，将其转化为结构化的 Payload 附加在消息元数据中推送给前端。
4. 前端交互与高亮渲染：
   - 微信小程序与 Web 端渲染引用角标卡片。用户点击 [1] 时，右侧/弹窗直接调用 PDF 预览组件，利用记录的 page_num 直接翻到对应页，并根据 bbox 坐标绘制半透明高亮矩形框，真正实现“字字有据，点击即验”。

Q8: 遇到大模型接口超时、RAGFlow 服务抖动或向量库响应过慢时，后端的超时控制、重试与降级策略是怎么设计的？

回答（求职者口吻）：
大模型和 RAG 服务由于涉及密集计算，网络与推理耗时波动较大。我们在 Go 业务层设计了分级超时控制、断路器与自适应降级矩阵：

1. Context 分级超时控制：
   - 为整个请求生命周期设置根 context.WithTimeout（如 30s）；
   - 为 RAGFlow 检索阶段设置子超时（如 3.5s），大模型首 Token 响应超时（TTFT）设置 5s，流式单 Chunk 读取超时设置 2s。任何阶段超时立即中断下游，防止 Goroutine 堆积。
2. 重试机制与退避策略：
   - 对于非幂等请求或纯网络瞬时抖动（如 HTTP 502/504），最多重试 1 次，并采用指数退避加随机抖动（Exponential Backoff with Jitter），避免雪崩击穿底层服务。
3. 分级降级兜底机制（Graceful Degradation）：
   - Level 1（Rerank 异常）：若 Reranker 模型超时，自动跳过重排，直接采用向量与 BM25 的 RRF 排序前 3 个 Chunk 送入大模型。
   - Level 2（RAGFlow 向量库不可用）：自动降级为业务 MySQL/ES 基础全文搜索，提取匹配段落作答。
   - Level 3（LLM API 完全宕机）：业务层直接返回基于规则的政务兜底提示语，并将该问题自动记录至告警日志，同时提示用户人工咨询通道。

Q9: 当检索到的分块之间存在矛盾（例如旧政策与新政策冲突，或不同层级公文表述不一致），系统如何处理和引导大模型作答？

回答（求职者口吻）：
公文冲突在政务实际业务中非常普遍。我们主要通过“入库期打标 + Prompt 冲突仲裁原则 + 结构化多重视角输出”三重机制解决：

1. 上位法优于下位法，新法优于旧法（法律效力原则）：
   - 在元数据中包含 doc_level（国家 > 省 > 市 > 区县）和 effective_date（施行日期）。
2. Prompt 冲突处理指令注入：
   - 在 System Prompt 中预置仲裁规则：“若检索到的参考材料中出现对同一事项的不同规定，请遵循以下原则：① 优先采纳印发日期最新的有效文件；② 上级部门文件与下级部门细则有冲突时，以现行最新上位法为准；③ 若材料中无法确定替代关系，必须在回答中客观呈现两份文件的不同表述，并明确指出文件名称与印发年份，提示用户注意政策差异。”
3. 输出呈现：
   - 大模型会输出结构化对比段落：“关于该项补贴标准，依据 2024 年最新发布的《A文件》标准为 X 万元；而 2021 年《B文件》历史标准为 Y 万元，请以最新文件为准”，既保证了准确性，又避免了盲目采信单一错误来源。

Q10: 你们如何评估和评测 RAG 系统的问答效果？业内常用的 Ragas 评估三要素在你们项目中是如何落地的？

回答（求职者口吻）：
我们建立了一套“自动化基准测试（Offline Benchmark）+ 线上真实反馈闭环（Online Feedback）”的评估体系：

1. 指标体系（基于 Ragas 框架标准）：
   - 检索相关性（Context Relevance）：召回的 Top-K Chunk 中真正包含答案关键信息的比例。
   - 忠实度/防幻觉率（Faithfulness / Groundedness）：模型输出的每一句断言是否能在检索到的 Chunk 中找到支撑证据。
   - 答案相关性（Answer Relevance）：回答是否直击用户提问核心，是否存在答非所问或废话连篇。
2. 政务专属黄金测试集（Golden Dataset）：
   - 联合政务业务骨干构建了包含 500+ 高频典型问题、标准答案及标准参考法规片段的评测集，覆盖单条法规查询、跨文件对比、否定性提问（“XX 是否被允许”）、口语化模糊提问等场景。
3. 自动化回归评测流水线：
   - 每次调整分块策略、更换 Embedding 模型、修改 Rerank 权重或优化 System Prompt 时，自动化脚本运行全量测试集，通过 LLM-as-a-Judge（结合裁判模型评分）输出综合准确率报表，只有综合评分优于 baseline 时才允许灰度发布。