面向HR政策问答的RAG流水线表格查询精度优化咨询

背景 #

正在构建面向HR政策问答场景的文档加载RAG流水线，支持加载多份PDF/DOC文件，核心流程为：

1. PDF/DOC文档加载
2. 文本分块
3. 嵌入向量生成
4. 向量检索
5. 基于LLM的答案生成

当前问题 #

表格类查询存在以下痛点：

• 信息明确存在于文档表格中，但LLM有时返回不完整列表
• 遗漏跨分块的表格行
• 生成无依据的幻觉条目
• 检索不完善时输出部分答案

当前Prompt #

table_prompt_template = """  
You are an HR assistant.  

Rules:  
- If the question asks for a list (members, names, etc.), extract ALL entries from the context  
- Combine information across chunks if needed  
- Do NOT return partial lists  
- Do NOT assume beyond context  

Context:  
{context}  

Question:  
{question}  

Answer:  
"""

约束条件 #

• 低延迟要求高
• 除非必要，避免复杂多代理流程或高成本重排序流水线
• 表格/列表类查询的准确性优先于对话质量

具体疑问 #

1. 是否应将表格与普通文本分块分开提取存储？
2. 表格采用结构化存储（JSON/行式分块）是否优于语义分块？
3. 混合检索（BM25+向量检索）能否提升列表查询的完整性？
4. 生产级RAG系统通常如何可靠处理表格数据？

1. 是否应将表格与普通文本分块分开提取存储？ #

必须分开。表格是结构化数据，和无结构的普通文本语义特征差异极大，混在一起分块会破坏表格的行/列关联关系，导致检索时无法精准定位完整表格片段。分开存储后，可针对表格数据单独设计检索逻辑，同时避免普通文本的噪声干扰表格查询的召回率，完全符合低延迟要求——仅需在文档加载阶段增加一个表格识别分支，无需额外复杂流程。

2. 表格采用结构化存储（JSON/行式分块）是否优于语义分块？ #

是的，结构化存储更适配表格类查询：

• 行式分块（每行作为独立chunk）或整表转JSON存储，能完整保留表格的结构化关联，比如“岗位级别”与“对应薪资”的绑定关系不会被语义分块拆分。
• 语义分块容易将同一表格的不同行拆分到不同chunk，导致检索时仅召回部分行，LLM无法拼接出完整列表。
• 结构化存储能让LLM更清晰地识别表格结构，大幅减少幻觉——比如JSON格式的表格，LLM可直接解析所有条目，不会遗漏或凭空生成内容。
• 从延迟角度看，行式分块的嵌入生成和检索成本与普通文本chunk相当，不会增加额外负担。

3. 混合检索（BM25+向量检索）能否提升列表查询的完整性？ #

能，这是低成本高收益的优化手段：

• 向量检索擅长语义匹配，但对于需要精准召回所有相关列表条目的场景（比如“所有带薪年假天数对应的员工级别”），BM25的关键词匹配能更精准定位表格中包含目标关键词的所有行，避免向量检索因语义偏差遗漏部分条目。
• 混合检索可采用简单的“并行召回+合并去重”策略：同时用BM25和向量检索召回top N chunk，合并后去重再喂给LLM，无需复杂重排序，延迟增加极小，完全符合约束条件。
• 针对表格的行式chunk，BM25能精准匹配每行的关键词，确保所有相关行都被召回，解决跨分块遗漏的问题。

4. 生产级RAG系统通常如何可靠处理表格数据？ #

生产级系统处理表格一般遵循轻量高效的流程，兼顾准确性与低延迟：

• 文档加载阶段：用专门的表格提取工具（如PyMuPDF、Docx2txt的表格识别模块）将表格从文档中单独提取，避免与普通文本混合。
• 结构化转换：将提取的表格转换为JSON格式（整表或行式），保留表头与行的关联关系；若表格过大，按逻辑主题分块（比如同一类别的多行作为一个chunk，而非随机拆分），确保chunk内的表格行是完整的逻辑组。
• 存储优化：表格的结构化数据单独存储在向量库的独立集合（或用标签标记），方便检索时快速过滤。
• 检索策略：采用BM25+向量检索的混合方式，针对表格查询优先召回标记为表格的chunk；对于列表类查询，强制召回所有匹配的表格行chunk，避免部分召回。
• Prompt优化：在现有prompt基础上，明确告知LLM当前context包含结构化表格数据，要求严格按表格条目输出，不得添加未提及内容，示例如下：

  table_prompt_template = """  
  You are an HR assistant.  
  
  Rules:  
  - The context may contain structured table data in JSON format. Extract ALL entries from the table that match the question.  
  - Combine information across all provided table chunks if needed  
  - Do NOT return partial lists  
  - Do NOT add any entries that are not explicitly present in the context  
  - If no matching entries are found, state "未找到相关信息"  
  
  Context:  
  {context}  
  
  Question:  
  {question}  
  
  Answer:  
  """
  

• 轻量验证层：增加简单的后处理验证步骤——用规则检查LLM输出的列表长度是否与context中表格的条目数量匹配（若查询全部条目），或检查输出的每个条目是否能在context中找到对应关键词，避免幻觉。该步骤仅为简单字符串匹配，延迟极低，不会增加太多成本。

内容的提问来源于stack exchange，提问作者S41