Rag问题总结

知识库构建（90％取决于文档结构处理和格式预处理是否合规且高质量）

目前rag存在的问题：命中率低，文档结构复杂，存在语义鸿沟。我们需要多种解决方案，比如混合搜索、查询改写等，最终通过LLM生成答案。

一、文档类型

1．支持的常见知识库文件格式

文件格式	推荐程度	描述
.md / .txt	强推荐	纯文本，语义清晰、结构明显，便于切块。
.docx	推荐	标题/段落格式可保留，适合提取。
.pdf	谨慎处理	存在图片、分页符、表格嵌套，易格式错乱。
.html	推荐	DOM层次结构天然丰富，适合章节提取。
.xls(x)	仅在特定场景	表格内容需结构化处理，非自然语言。
.ppt(x)	不推荐	多为短语、图像，不具上下文连贯性。
图片类（.jpg/.png）	仅 OCR 场景使用	需要 OCR 识别，准确率依赖算法。

2．文档结构处理

标题分级清晰：按H1-H2-H3 层级组织，利于LLM理解上下文。

段落独立：每段为完整语义单位，便于分块与向量化。

图文表分离：图／表单独处理，避免噪声干扰。

冗余清理：去除页眉页脚／版权声明等低价值信息。

引用显式化：附件／跳转等用锚点或改写补全上下文。

3．图片处理

OCR图→提取文字合并入相邻段落，生成向量。

图像语义理解→利用多模态模型理解图片内容。

结构／表格图→提取结构，转JSON 表格或结构摘要。

无意义图（如Logo）→过滤不入库。

4．图文整合入库流程

图片提取→保存图片并记录位置／ID。

类型识别→OCR图／表格图／结构图／展示图。

语义整合→文字与图内容合并为逻辑块，保留图片URL和位置信息。

向量生成→每块生成语义向量，含 metadata。

入库支持查询→可按文档ID、图片类型、页码等条件回查。

入库块内容丰富：提取关键字，提取摘要，增加上下文摘要，将当前块置于全文背景之下，提供更丰富的背景信息和支持细节。通过丰富块信息，最终帮助大模型理解知识库内容

通过整合这些元素–关键字、摘要及上下文描述–使得大模型能够更高效地解析和利用知识库中的内容，进而提高整体理解和响应质量。

二、如何有效 Chunking

1．确定最佳切块粒度

说明类文档：按自然段切块，控制在300-512 token，保证上下文流畅；

规范类文档（如标准／合同）：按条编号（如1.1节）切块，保持逻辑链不被打断；

表格内容：整个表格作为一个chunk，含表头与行，通过对齐特征识别，确保结构不被破坏代码／配置：以函数或配置段为单位切块，避免断裂逻辑块；

FAQ 问答：每组问答独立成块，保留问题背景，便于上下文理解与回答。

2．滑动窗口 overlap

为确保块间语义连贯，应设置合理的重叠（Overlap）区域，使关键转折句或上下文承接内容在多个块中重复出现。根据chunk 大小，推荐设置64-200 token 的Overlap，用于防止句子截断、语义跳断，帮助大模型更好理解上下文，从而提升召回质量与回答准确率。Overlap 是语义缓冲带，不是简单句子复制，而是精准延续语义流。

3．最佳实践总结：

结构感知切块策略，针对不同内容类型（如自然段、规范条款、表格、代码）进行 结构边界切分，而非简单按 token 截断。

推荐Chunk Size为300-512 tokens，设置50-150tokens的Overlap保持语义连续。

对每个切块附加结构元数据（如标题、段落ID、条款号），同时将图文整合为统一的“语义块”进入向量库，以提升多模态查询表现。

4．切分方法介绍

4.1 Q&A分块

支持Excel（两列：问题列＋答案列）和CSV/TXT(UTF-8编码，TAB分隔问题与答案）每对问答视为独立块，不符合格式的行忽略

先通用切块，再用内置提示词生成Q&A对

支持 DOCX、EXCEL、PPT、IMAGE、PDF、TXT、MD、JSON、EML、HTML等格式

4.2父子分段

子块用于检索，父块作为上下文补充

4.3Manual（手册）分块

仅支持 PDF

按最低级章节标题切片，同一章节内图表不拆分，块较大

4.4Table（表格）分块

支持 XLSX、CSV/TXT(TAB分隔，首行列标题，需语义明确）

每行作为一个独立块

标题中可用斜杠或方括号表示同义词及枚举值

4.5Paper（论文）分块

仅支持 PDF

按论文章节切块（摘要、1.1、1.2等）

4.6Laws（法律）分块

支持 DOCX、PDF、TXT

按“条款（ARTICLE）”粒度切分，包含上层上下文

54.7Presentation（演示文稿）分块

支持 PDF、PPTX

每页作为一个块，存储页面缩略图

所有PPT文件默认自动使用此方法

4.8 One（整体）分块

支持 DOCX、EXCEL、PDF、TXT

整文不拆分，作为单块处理

适合短文档或需要完整上下文的场景

三、嵌入模型

1．模型选型

语言适配能力、语义精度、推理延迟、向量压缩率、迁移适配能力

2．向量语义表达能力

这是embedding 选型最核心的隐变量，其衡量应从以下维度展开：

语义密度；相似概念在向量空间紧密性

实体区分度：能否区分关键实体

上下文保持能力：长句能否完整保留语义

语义稳定性：微小句式变化一致向量

3．主流向量模型优劣对比

模型	优势	局限	推荐场景
BGE-M3（多语言＋ dense+rerank支持）	中文语义强、适配RAG 、支持 rerank／压缩	模型略大，部署需优化	中文语义检索／多语言 RAG
Nomic Embed	多模态支持、开源、适配文本＋图像	英文任务强，中文表现次	多模态推荐系 统
mxbai-large/v2	MTEB 搜索类任务排名领先语义表达强	， 推理慢、资源重	高精度向量匹配需求（如法务／审计）
E5-mistral	英语强、多语言一般，Open Source	中文任务表现 偏弱	英文 RAG ／检索任务
OpenAI text-embedding-3-small/large	延迟低（API ）、多场景泛用	中文适配差，闭源	快速上线／英文检索任务
GTE / MiniLM	轻量，推理快，适配嵌入缓存	语义密度差、上下文保持弱	快速初期原型／高并发搜索

四、向量数据库选型

目前用于 RAG的数据库分为三类：

第一类是传统型数据库。只要增加了向量能力，理论上就可以用于RAG。

第二类是典型的向量数据库。

第三类是具备全文搜索＋向量能力的数据库，比如Elasticsearch。

在企业级场景中，全文搜索是一项必备能力，需要结合向量维度、相似度算法、过滤器支持能力来选择

五、重排模块选型

重排模块目标：

对初始召回的 Top-K 文档 按语义质量、相关性等进行重新排序，提高最终返回内容质量，通常是第二阶段模型。

六、检索 Retrieval 多策略并行设计

使用问题扩展 多轮提问、同义改写，问题关键词提取，原问题直接 作为 baseline 无处理每个通道并行触发两种检索：向量检索（语义召回）全文检索（关键词召回）

技术要点：每个策略形成不同的检索路径，生成独立Top-K 候选集合，通过去重、重排从查询结果中选择匹配用户问题的最佳结果，用户可以选择设置权重或配置重新排序模型。

七、增强

动态上下文调整在处理用户请求时，根据用户的查询动态地从知识库中提取相关信息。这不仅包括直接相关的数据，还应该考虑相关联的背景信息，以便提供更全面的答案。

多源数据融合：整合来自不同来源的数据，如结构化数据库、文档、网页，形成一个更加丰富的上下文环境。

八、生成

调用模型生成内容，需要考虑模型的生成质量是否和问题相关，可以调用评估模型，不相关时考虑重新生成或者用户提供更多信息。