1. RAG 到底在解决什么问题聊到检索增强生成Retrieval-Augmented GenerationRAG我得先泼一盆冷水它不是什么高深莫测的架构本质就是把“检索”和“生成”这两件事拼在一起让大模型在回答问题之前先去外部知识库里翻一翻资料再把翻到的内容作为参考依据最后生成答案。为什么要这么折腾因为纯靠模型“背”答案有两个绕不过去的坎知识有时间边界模型训练时学的知识是固定的训练完之后它就不会再自动更新了。你问它最近发生的事情它要么编要么说不知道。幻觉问题模型不知道答案的时候为了不冷场它会一本正经地胡说八道。尤其是垂直领域、小众问题这种情况特别常见。RAG 的思路很简单把知识存储从模型参数里搬出来放到外部数据库里。模型每次回答问题都先去库里检索最相关的内容然后基于这些内容生成答案。这样知识可以随时更新回答也有据可查幻觉问题能缓解一大截。不过理想很丰满现实很骨感。RAG 项目真正跑起来之后你会发现检索质量、文档解析、分块策略、向量化效果每一个环节都可能变成性能瓶颈。这篇文章想分享的就是 RAG 入门阶段最核心的部分核心原理 文档加载全流程。我会把每一步的“为什么这么干”讲清楚也会把我踩过的坑直接列出来。2. 先搞懂 RAG 的完整链路2.1 从“开卷考试”理解 RAG 的流程你可以把纯大模型问答想象成“闭卷考试”——模型脑子里有什么就只能答什么。而 RAG 相当于给了模型一份“参考资料”让它开卷答题。整个流程可以拆成五个环节文档加载Load把各种格式的资料读进来变成纯文本。这是容易被低估的一步——原始文档质量差后面全白搭。文档切分Split把长文本切成小块。切得太粗检索不精准切得太细语义被割裂。这是非常考验经验的一步。向量化Embedding把文本块变成向量。语义相近的文本在向量空间里的距离也相近。存储与索引Store把向量存进向量数据库并建立索引。这一层决定检索速度。检索与生成Retrieve Generate用户提问时把问题转成向量去库里找最相似的文本块然后连同问题一起交给模型生成答案。这五步环环相扣哪一环出了问题最终答案质量都会受影响。而且我可以负责任地说实际项目里检索环节的问题往往占大头生成模型反而是背锅的。2.2 为什么检索结果直接影响答案质量很多人以为 RAG 项目效果不好是模型能力不行。其实大多数时候问题出在检索端该召回的内容没召回来或者召回来的内容根本不相关。你可以这样理解——模型再聪明你给它的参考资料就是错的它也只能在错误的基础上组织语言。检索质量的主要影响因素有三个文档切分粒度如果一块文本包含多个主题这块文本和某个具体问题的相关性就会被“稀释”导致检索得分不高。向量质量弱向量模型对语义理解不够深近义词、同义表达可能被判为不相关。检索策略只做向量检索往往抓不到精确关键词匹配只做关键词检索又理解不了语义。实际项目中通常需要混合检索。所以 RAG 入门的关键不是急着跑通 demo而是把文档加载 → 切分 → 向量化 → 检索的每一个环节都吃透。下面重点拆解“文档加载”部分——这是整个链路的地基。3. 文档加载最不起眼却最致命的一步3.1 文档加载的本质与挑战文档加载就是把 PDF、Word、HTML、Markdown、纯文本等不同格式的文件解析成模型能够理解的纯文本内容。听起来简单等你真拿一份带复杂排版、表格、图片、扫描页的 PDF 去解析就知道了这事儿的坑多到让人想摔键盘。文档加载阶段最常见的问题有问题类型具体表现常规解决方案PDF 扫描件无文字层复制不了文字解析出来全是乱码或空内容先 OCR 识别再解析表格结构错乱表格行列错位数据对不上优先用保留布局的解析工具页眉页脚混入正文检索时频繁命中无关的页眉页脚清洗阶段做规则过滤多栏排版颠倒双栏 PDF 读取顺序错乱使用支持版面分析的解析库加密文档工具直接报错或跳过先解密再加载3.2 文本读取与格式解析的常用方案在 LangChain 生态里文档加载器Document Loader帮你屏蔽了大部分格式差异统一输出为 Document 对象包含page_content和metadata两个核心字段。我的常见做法是第一能转 Markdown 的先转 Markdown。Markdown 保留了标题层级、列表、表格、代码块这些结构信息对后续切分非常有价值。比如 PDF 可以先用文档转换工具转成 Markdown再交给 LangChain 读取。这一步能显著减少版式信息丢失特别是表格和多栏排版的问题。第二结构化文档用对应加载器。Word 文档、HTML 页面、JSON、CSV 等格式LangChain 都有对应的加载器不需要自己手写解析逻辑。第三扫描版 PDF 必须先过 OCR。这是很多人容易忽略的。扫描件根本没有文字层你直接加载只能得到一堆空白或者乱码。要么先用 OCR 工具转成带文字的 PDF要么选用内置 OCR 能力的加载器。3.3 实战用 LangChain 加载多种格式文档下面这段代码展示了我最常用的一套加载组合覆盖 Markdown、PDF、Word、HTML 四种常见格式from langchain_community.document_loaders import DirectoryLoader from langchain_community.document_loaders import TextLoader from langchain_community.document_loaders import PyPDFLoader from langchain_community.document_loaders import Docx2txtLoader from langchain_community.document_loaders import UnstructuredHTMLLoader # 方式一按目录批量加载指定文件后缀和对应加载器 loaders { .md: TextLoader, .txt: TextLoader, .pdf: PyPDFLoader, .docx: Docx2txtLoader, .html: UnstructuredHTMLLoader, } # 实际项目中我倾向逐个类型加载便于单独处理异常 def load_documents(file_path: str): if file_path.endswith(.pdf): loader PyPDFLoader(file_path) elif file_path.endswith(.docx): loader Docx2txtLoader(file_path) elif file_path.endswith(.html): loader UnstructuredHTMLLoader(file_path) else: loader TextLoader(file_path, encodingutf-8) return loader.load()这里有个细节值得注意TextLoader的默认编码是 UTF-8但某些老旧的 TXT 文件可能是 GBK 或 GB18030 编码读取时会直接抛异常。所以我通常会在代码里加一个编码 fallback 逻辑rstrip()掉文本前后的空白字符然后过滤掉太短的段落减少无效内容的干扰。这类小细节往往决定了项目的稳定性。提示DirectoryLoader虽然方便但默认用多线程加载某些格式尤其是加密 PDF会在线程池里直接吞掉异常导致你排查问题时无从下手。建议入门阶段一个一个格式加载把每个文件的成功/失败状态打印出来心里有数。3.4 实战用 Markdown 头部元数据辅助打标除了内容文档的元数据metadata也很关键。它相当于给文本块贴的标签后续可以用来做过滤、去重或溯源。LangChain 的MarkdownHeaderTextSplitter就是专门干这个的——它能把 Markdown 的标题层级信息提取为 metadata 字段比如把一级标题存为H1二级标题存为H2然后再切分正文。from langchain_text_splitters import MarkdownHeaderTextSplitter markdown_document # 产品手册 ## 安装说明 第一步先安装依赖包... ## 配置说明 修改配置文件中的连接串... ## 常见问题 Q1: 连接失败怎么办 splitter MarkdownHeaderTextSplitter( headers_to_split_on[(#, H1), (##, H2)], ) docs splitter.split_text(markdown_document) for doc in docs: print(doc.page_content[:50], doc.metadata)这样切出来的文本块metadata 里自带{H1: 产品手册, H2: 安装说明}后续检索时你可以按标题过滤、按篇章去重、按来源溯源非常灵活。这个思路很多项目都在用强烈推荐。4. 切分策略不是简单按字数硬切4.1 为什么切分粒度如此重要文档加载完之后下一步就是切分。切分这个动作看起来简单实际上直接决定检索效果的“颗粒度”。想象一下你有一本 300 页的产品手册如果不切分整本书作为一块丢进向量库检索时你会发现任何问题跟这本书的相关度都差不多完全没法精准定位到具体章节。反过来如果你把每个句子都切成一块语义碎片化严重检索出来的内容缺少上下文模型也无法组织出完整答案。切分的核心目标是让每个文本块在语义上尽量“自洽完整”。也就是说一个文本块要能独立表达一个主题或一个要点当它被检索出来作为参考资料时模型不需要额外脑补太多背景。4.2 字符数切分与语义切分的取舍最常见的切分方式是“按固定字符数量切再加重叠”。LangChain 里的RecursiveCharacterTextSplitter就是这么做的——它尝试按一组分隔符从大到小段落符、换行符、句号、逗号、空格依次切分优先在语义边界处断开实在不行才硬切。from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n\n, \n, 。, , , , ], ) chunks text_splitter.split_text(long_text)这里的两个参数是经验值但值得解释一下chunk_size 800按中文字符算800 字大致是一篇短文或一个知识点的体量。太大检索定位不精确太小语义不完整。我实测下来中文知识库场景 5001000 字是相对稳妥的范围具体取决于你的文档密度。chunk_overlap 150重叠的作用是让相邻文本块之间保留一定的上下文衔接。比如第一块末尾讲到“该方法”第二块开头如果完全没有前文信息模型可能不知道“该方法”指什么。重叠部分把上一块的结尾“带到”下一块开头上下文连贯性会好很多。注意overlap 不是万能的。如果文档句式非常碎片化overlap 补再多也救不回语义割裂。更根本的解法是“按语义切分”——用semantic chunking先把文本按语义边界聚簇再切分。但语义切分计算开销大入门阶段先用字符切分 合理参数完全够用。5. 向量化与存储选型要点和避坑经验5.1 向量化模型选择的实用建议向量化Embedding这一步是把文本块变成数字向量的过程。这一步的关键是选对 Embedding 模型。我筛选模型的几个标准中文语义理解能力通用领域的 Embedding 模型不一定擅长中文尤其是专业文档里的术语。建议在你自己领域的小样本上做个简单评测准备 100 组问题-文档对看命中率。向量维度维度越高向量越“精细”但存储和计算开销也更大。常用模型从 384 维到 1536 维不等没有绝对的好坏只有适不适合。输入长度上限Embedding 模型通常有 token 上限比如 512 token 或 8192 token。文本块别超过上限否则会被截断。5.2 向量数据库的对比与选型思路向量数据库负责存储向量并提供相似度检索。入门阶段不用纠结太多常见的几个我都试过数据库部署方式适合场景备注Chroma本地嵌入式入门、原型验证简单易用无需单独部署FAISS本地库单机中等规模检索性能好需自行管理生命周期Milvus客户端-服务端生产级大规模检索支持过滤、混合检索部署略重Elasticsearch服务端已有 ES 体系的团队关键词和向量都能做扩展方便pgvector嵌入式/服务端已用 PostgreSQL 的团队复用现有数据库减少组件我个人的建议是入门先用 Chroma 或者 FAISS 跑通链路等确定项目会长期迭代、数据量上来了再迁移到生产级向量库。5.3 一个完整的“加载 → 切分 → 入库”流程示例把所有环节串起来给你一个可以直接抄作业的完整流程from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader TextLoader(knowledge_base.txt, encodingutf-8) documents loader.load() # 2. 切分文本 splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, ) chunks splitter.split_documents(documents) # 3. 初始化 Embedding 模型 embeddings HuggingFaceEmbeddings( model_nameyour-embedding-model-name, ) # 4. 构建向量库并持久化 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) # 5. 检索测试 query 某个具体问题 results vectorstore.similarity_search(query, k5) for i, doc in enumerate(results): print(fTop {i1}: {doc.page_content[:100]})这里有一个非常容易被忽视的点similarity_search返回的是“向量空间距离最近”的文本块而不是“语义上真的相关”的文本块。两者不一定完全一致。尤其当你的 Embedding 模型能力较弱时向量相关性和语义相关性的 gap 会特别明显。所以检索之后强烈建议再加一个rerank重排环节——用更重的模型对初筛结果重新排序把最相关的挤到前面。这是生产级 RAG 的标配入门阶段可以先不加入但心里要有这根弦。6. 检索优化的几个高阶方向6.1 混合检索与重排纯向量检索的短板前面提过抓不住精确关键词匹配。解决思路是混合检索——同时跑向量检索和关键词检索比如 BM25然后把两路结果合并排序。这个方案的实现方式有很多LangChain 里有现成的EnsembleRetriever可以做加权融合。重排Rerank则是在初筛结果的基础上用一个更精细的模型比如 Cross-Encoder对“问题-文档对”重新打分把真正相关的文本块排在前面。重排带来的效果提升通常非常直观尤其当你的知识库有大量相似文本时重排之后回答质量会上一个台阶。6.2 元数据过滤与引用溯源向量检索支持按 metadata 过滤这是一个非常实用但入门者容易忽略的功能。举例你的知识库里有 2023 年和 2024 年的两份政策文档用户问“2024 年政策有哪些变化”你可以先在 metadata 上过滤year 2024再在过滤结果里做向量检索精度会高很多。另外保留每个文本块的来源路径比如文件路径、页码、章节标题非常有必要。用户看到答案时能点开原文核对这个能力在企业内部应用中是刚需也是让用户建立信任的关键。6.3 多轮对话与查询改写RAG 在对话场景下还有一个经典问题用户说“它的安装步骤是什么”这里的“它”指代上一轮讨论的某个软件。如果直接把这一句话拿去做检索效果必然差。所以生产级 RAG 通常会做查询改写——先用大模型把用户的指代问题补全成完整问句再用补全后的问句去检索。这个环节不起眼但实际体验提升非常大。7. 常见问题与排查技巧实录下面这几条是我实际项目里反复踩过的坑列成速查表你遇到类似问题时可以直接对照排查。问题现象可能的根因排查方向检索结果总是缺失关键信息文档切分太粗关键内容被稀释调小 chunk_size或改用语义切分回答内容张冠李戴检索出来的文本块本身不相关检查 Embedding 模型是否合适尝试换模型或加 rerankPDF 加载后乱码扫描件未 OCR或编码识别错误先 OCR再加载确认加载器编码参数相似文档太多排序分不清向量检索区分度不足引入重排模型或加关键词过滤首次构建向量库极慢文档数量大 模型推理耗时长分批入库用批量 API或换更强的机器检索结果与问题完全不相关Embedding 向量空间映射不合理评测多个 Embedding 模型选特定领域表现最优的排查技巧我习惯先做单点验证只保留一个文档用几个典型问题测检索看能不能召回到正确内容。这能快速把问题定位到“加载/切分”还是“向量化/检索”环节。如果内容没进库后面全白搭。8. 一点实在的体会做 RAG 项目至今我的最大感受是这个方向看起来简单调起来无穷无尽。很多人以为 RAG 就是把文档丢进去、向量化、检索、生成四步走完就完事了。但实际上文档质量、切分参数、Embedding 模型、检索策略、重排策略每一项都有大量可优化的空间每一项都可能成为效果的瓶颈而每一项的调试经验都需要真金白银的尝试才能沉淀下来。如果你是刚开始接触 RAG我建议不要急着上各种花哨框架先老老实实把“加载 → 切分 → 向量化 → 入库 → 检索”这条链路亲手跑通再用 2030 个领域内的高频问题去反复检验检索质量。等你能清楚地说出“为什么这个问题命中不了”“为什么那个问题召回了错误片段”你对 RAG 的理解就已经超过大多数停留在 demo 阶段的人了。先说这些后面有机会再聊聊检索优化的更深层玩法。 
长河君 · 2026/10/22 18:33:40 · 阅读 1.2k RAG入门核心原理与文档加载全流程实战解析
1. RAG 到底在解决什么问题聊到检索增强生成Retrieval-Augmented GenerationRAG我得先泼一盆冷水它不是什么高深莫测的架构本质就是把“检索”和“生成”这两件事拼在一起让大模型在回答问题之前先去外部知识库里翻一翻资料再把翻到的内容作为参考依据最后生成答案。为什么要这么折腾因为纯靠模型“背”答案有两个绕不过去的坎知识有时间边界模型训练时学的知识是固定的训练完之后它就不会再自动更新了。你问它最近发生的事情它要么编要么说不知道。幻觉问题模型不知道答案的时候为了不冷场它会一本正经地胡说八道。尤其是垂直领域、小众问题这种情况特别常见。RAG 的思路很简单把知识存储从模型参数里搬出来放到外部数据库里。模型每次回答问题都先去库里检索最相关的内容然后基于这些内容生成答案。这样知识可以随时更新回答也有据可查幻觉问题能缓解一大截。不过理想很丰满现实很骨感。RAG 项目真正跑起来之后你会发现检索质量、文档解析、分块策略、向量化效果每一个环节都可能变成性能瓶颈。这篇文章想分享的就是 RAG 入门阶段最核心的部分核心原理 文档加载全流程。我会把每一步的“为什么这么干”讲清楚也会把我踩过的坑直接列出来。2. 先搞懂 RAG 的完整链路2.1 从“开卷考试”理解 RAG 的流程你可以把纯大模型问答想象成“闭卷考试”——模型脑子里有什么就只能答什么。而 RAG 相当于给了模型一份“参考资料”让它开卷答题。整个流程可以拆成五个环节文档加载Load把各种格式的资料读进来变成纯文本。这是容易被低估的一步——原始文档质量差后面全白搭。文档切分Split把长文本切成小块。切得太粗检索不精准切得太细语义被割裂。这是非常考验经验的一步。向量化Embedding把文本块变成向量。语义相近的文本在向量空间里的距离也相近。存储与索引Store把向量存进向量数据库并建立索引。这一层决定检索速度。检索与生成Retrieve Generate用户提问时把问题转成向量去库里找最相似的文本块然后连同问题一起交给模型生成答案。这五步环环相扣哪一环出了问题最终答案质量都会受影响。而且我可以负责任地说实际项目里检索环节的问题往往占大头生成模型反而是背锅的。2.2 为什么检索结果直接影响答案质量很多人以为 RAG 项目效果不好是模型能力不行。其实大多数时候问题出在检索端该召回的内容没召回来或者召回来的内容根本不相关。你可以这样理解——模型再聪明你给它的参考资料就是错的它也只能在错误的基础上组织语言。检索质量的主要影响因素有三个文档切分粒度如果一块文本包含多个主题这块文本和某个具体问题的相关性就会被“稀释”导致检索得分不高。向量质量弱向量模型对语义理解不够深近义词、同义表达可能被判为不相关。检索策略只做向量检索往往抓不到精确关键词匹配只做关键词检索又理解不了语义。实际项目中通常需要混合检索。所以 RAG 入门的关键不是急着跑通 demo而是把文档加载 → 切分 → 向量化 → 检索的每一个环节都吃透。下面重点拆解“文档加载”部分——这是整个链路的地基。3. 文档加载最不起眼却最致命的一步3.1 文档加载的本质与挑战文档加载就是把 PDF、Word、HTML、Markdown、纯文本等不同格式的文件解析成模型能够理解的纯文本内容。听起来简单等你真拿一份带复杂排版、表格、图片、扫描页的 PDF 去解析就知道了这事儿的坑多到让人想摔键盘。文档加载阶段最常见的问题有问题类型具体表现常规解决方案PDF 扫描件无文字层复制不了文字解析出来全是乱码或空内容先 OCR 识别再解析表格结构错乱表格行列错位数据对不上优先用保留布局的解析工具页眉页脚混入正文检索时频繁命中无关的页眉页脚清洗阶段做规则过滤多栏排版颠倒双栏 PDF 读取顺序错乱使用支持版面分析的解析库加密文档工具直接报错或跳过先解密再加载3.2 文本读取与格式解析的常用方案在 LangChain 生态里文档加载器Document Loader帮你屏蔽了大部分格式差异统一输出为 Document 对象包含page_content和metadata两个核心字段。我的常见做法是第一能转 Markdown 的先转 Markdown。Markdown 保留了标题层级、列表、表格、代码块这些结构信息对后续切分非常有价值。比如 PDF 可以先用文档转换工具转成 Markdown再交给 LangChain 读取。这一步能显著减少版式信息丢失特别是表格和多栏排版的问题。第二结构化文档用对应加载器。Word 文档、HTML 页面、JSON、CSV 等格式LangChain 都有对应的加载器不需要自己手写解析逻辑。第三扫描版 PDF 必须先过 OCR。这是很多人容易忽略的。扫描件根本没有文字层你直接加载只能得到一堆空白或者乱码。要么先用 OCR 工具转成带文字的 PDF要么选用内置 OCR 能力的加载器。3.3 实战用 LangChain 加载多种格式文档下面这段代码展示了我最常用的一套加载组合覆盖 Markdown、PDF、Word、HTML 四种常见格式from langchain_community.document_loaders import DirectoryLoader from langchain_community.document_loaders import TextLoader from langchain_community.document_loaders import PyPDFLoader from langchain_community.document_loaders import Docx2txtLoader from langchain_community.document_loaders import UnstructuredHTMLLoader # 方式一按目录批量加载指定文件后缀和对应加载器 loaders { .md: TextLoader, .txt: TextLoader, .pdf: PyPDFLoader, .docx: Docx2txtLoader, .html: UnstructuredHTMLLoader, } # 实际项目中我倾向逐个类型加载便于单独处理异常 def load_documents(file_path: str): if file_path.endswith(.pdf): loader PyPDFLoader(file_path) elif file_path.endswith(.docx): loader Docx2txtLoader(file_path) elif file_path.endswith(.html): loader UnstructuredHTMLLoader(file_path) else: loader TextLoader(file_path, encodingutf-8) return loader.load()这里有个细节值得注意TextLoader的默认编码是 UTF-8但某些老旧的 TXT 文件可能是 GBK 或 GB18030 编码读取时会直接抛异常。所以我通常会在代码里加一个编码 fallback 逻辑rstrip()掉文本前后的空白字符然后过滤掉太短的段落减少无效内容的干扰。这类小细节往往决定了项目的稳定性。提示DirectoryLoader虽然方便但默认用多线程加载某些格式尤其是加密 PDF会在线程池里直接吞掉异常导致你排查问题时无从下手。建议入门阶段一个一个格式加载把每个文件的成功/失败状态打印出来心里有数。3.4 实战用 Markdown 头部元数据辅助打标除了内容文档的元数据metadata也很关键。它相当于给文本块贴的标签后续可以用来做过滤、去重或溯源。LangChain 的MarkdownHeaderTextSplitter就是专门干这个的——它能把 Markdown 的标题层级信息提取为 metadata 字段比如把一级标题存为H1二级标题存为H2然后再切分正文。from langchain_text_splitters import MarkdownHeaderTextSplitter markdown_document # 产品手册 ## 安装说明 第一步先安装依赖包... ## 配置说明 修改配置文件中的连接串... ## 常见问题 Q1: 连接失败怎么办 splitter MarkdownHeaderTextSplitter( headers_to_split_on[(#, H1), (##, H2)], ) docs splitter.split_text(markdown_document) for doc in docs: print(doc.page_content[:50], doc.metadata)这样切出来的文本块metadata 里自带{H1: 产品手册, H2: 安装说明}后续检索时你可以按标题过滤、按篇章去重、按来源溯源非常灵活。这个思路很多项目都在用强烈推荐。4. 切分策略不是简单按字数硬切4.1 为什么切分粒度如此重要文档加载完之后下一步就是切分。切分这个动作看起来简单实际上直接决定检索效果的“颗粒度”。想象一下你有一本 300 页的产品手册如果不切分整本书作为一块丢进向量库检索时你会发现任何问题跟这本书的相关度都差不多完全没法精准定位到具体章节。反过来如果你把每个句子都切成一块语义碎片化严重检索出来的内容缺少上下文模型也无法组织出完整答案。切分的核心目标是让每个文本块在语义上尽量“自洽完整”。也就是说一个文本块要能独立表达一个主题或一个要点当它被检索出来作为参考资料时模型不需要额外脑补太多背景。4.2 字符数切分与语义切分的取舍最常见的切分方式是“按固定字符数量切再加重叠”。LangChain 里的RecursiveCharacterTextSplitter就是这么做的——它尝试按一组分隔符从大到小段落符、换行符、句号、逗号、空格依次切分优先在语义边界处断开实在不行才硬切。from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n\n, \n, 。, , , , ], ) chunks text_splitter.split_text(long_text)这里的两个参数是经验值但值得解释一下chunk_size 800按中文字符算800 字大致是一篇短文或一个知识点的体量。太大检索定位不精确太小语义不完整。我实测下来中文知识库场景 5001000 字是相对稳妥的范围具体取决于你的文档密度。chunk_overlap 150重叠的作用是让相邻文本块之间保留一定的上下文衔接。比如第一块末尾讲到“该方法”第二块开头如果完全没有前文信息模型可能不知道“该方法”指什么。重叠部分把上一块的结尾“带到”下一块开头上下文连贯性会好很多。注意overlap 不是万能的。如果文档句式非常碎片化overlap 补再多也救不回语义割裂。更根本的解法是“按语义切分”——用semantic chunking先把文本按语义边界聚簇再切分。但语义切分计算开销大入门阶段先用字符切分 合理参数完全够用。5. 向量化与存储选型要点和避坑经验5.1 向量化模型选择的实用建议向量化Embedding这一步是把文本块变成数字向量的过程。这一步的关键是选对 Embedding 模型。我筛选模型的几个标准中文语义理解能力通用领域的 Embedding 模型不一定擅长中文尤其是专业文档里的术语。建议在你自己领域的小样本上做个简单评测准备 100 组问题-文档对看命中率。向量维度维度越高向量越“精细”但存储和计算开销也更大。常用模型从 384 维到 1536 维不等没有绝对的好坏只有适不适合。输入长度上限Embedding 模型通常有 token 上限比如 512 token 或 8192 token。文本块别超过上限否则会被截断。5.2 向量数据库的对比与选型思路向量数据库负责存储向量并提供相似度检索。入门阶段不用纠结太多常见的几个我都试过数据库部署方式适合场景备注Chroma本地嵌入式入门、原型验证简单易用无需单独部署FAISS本地库单机中等规模检索性能好需自行管理生命周期Milvus客户端-服务端生产级大规模检索支持过滤、混合检索部署略重Elasticsearch服务端已有 ES 体系的团队关键词和向量都能做扩展方便pgvector嵌入式/服务端已用 PostgreSQL 的团队复用现有数据库减少组件我个人的建议是入门先用 Chroma 或者 FAISS 跑通链路等确定项目会长期迭代、数据量上来了再迁移到生产级向量库。5.3 一个完整的“加载 → 切分 → 入库”流程示例把所有环节串起来给你一个可以直接抄作业的完整流程from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader TextLoader(knowledge_base.txt, encodingutf-8) documents loader.load() # 2. 切分文本 splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, ) chunks splitter.split_documents(documents) # 3. 初始化 Embedding 模型 embeddings HuggingFaceEmbeddings( model_nameyour-embedding-model-name, ) # 4. 构建向量库并持久化 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) # 5. 检索测试 query 某个具体问题 results vectorstore.similarity_search(query, k5) for i, doc in enumerate(results): print(fTop {i1}: {doc.page_content[:100]})这里有一个非常容易被忽视的点similarity_search返回的是“向量空间距离最近”的文本块而不是“语义上真的相关”的文本块。两者不一定完全一致。尤其当你的 Embedding 模型能力较弱时向量相关性和语义相关性的 gap 会特别明显。所以检索之后强烈建议再加一个rerank重排环节——用更重的模型对初筛结果重新排序把最相关的挤到前面。这是生产级 RAG 的标配入门阶段可以先不加入但心里要有这根弦。6. 检索优化的几个高阶方向6.1 混合检索与重排纯向量检索的短板前面提过抓不住精确关键词匹配。解决思路是混合检索——同时跑向量检索和关键词检索比如 BM25然后把两路结果合并排序。这个方案的实现方式有很多LangChain 里有现成的EnsembleRetriever可以做加权融合。重排Rerank则是在初筛结果的基础上用一个更精细的模型比如 Cross-Encoder对“问题-文档对”重新打分把真正相关的文本块排在前面。重排带来的效果提升通常非常直观尤其当你的知识库有大量相似文本时重排之后回答质量会上一个台阶。6.2 元数据过滤与引用溯源向量检索支持按 metadata 过滤这是一个非常实用但入门者容易忽略的功能。举例你的知识库里有 2023 年和 2024 年的两份政策文档用户问“2024 年政策有哪些变化”你可以先在 metadata 上过滤year 2024再在过滤结果里做向量检索精度会高很多。另外保留每个文本块的来源路径比如文件路径、页码、章节标题非常有必要。用户看到答案时能点开原文核对这个能力在企业内部应用中是刚需也是让用户建立信任的关键。6.3 多轮对话与查询改写RAG 在对话场景下还有一个经典问题用户说“它的安装步骤是什么”这里的“它”指代上一轮讨论的某个软件。如果直接把这一句话拿去做检索效果必然差。所以生产级 RAG 通常会做查询改写——先用大模型把用户的指代问题补全成完整问句再用补全后的问句去检索。这个环节不起眼但实际体验提升非常大。7. 常见问题与排查技巧实录下面这几条是我实际项目里反复踩过的坑列成速查表你遇到类似问题时可以直接对照排查。问题现象可能的根因排查方向检索结果总是缺失关键信息文档切分太粗关键内容被稀释调小 chunk_size或改用语义切分回答内容张冠李戴检索出来的文本块本身不相关检查 Embedding 模型是否合适尝试换模型或加 rerankPDF 加载后乱码扫描件未 OCR或编码识别错误先 OCR再加载确认加载器编码参数相似文档太多排序分不清向量检索区分度不足引入重排模型或加关键词过滤首次构建向量库极慢文档数量大 模型推理耗时长分批入库用批量 API或换更强的机器检索结果与问题完全不相关Embedding 向量空间映射不合理评测多个 Embedding 模型选特定领域表现最优的排查技巧我习惯先做单点验证只保留一个文档用几个典型问题测检索看能不能召回到正确内容。这能快速把问题定位到“加载/切分”还是“向量化/检索”环节。如果内容没进库后面全白搭。8. 一点实在的体会做 RAG 项目至今我的最大感受是这个方向看起来简单调起来无穷无尽。很多人以为 RAG 就是把文档丢进去、向量化、检索、生成四步走完就完事了。但实际上文档质量、切分参数、Embedding 模型、检索策略、重排策略每一项都有大量可优化的空间每一项都可能成为效果的瓶颈而每一项的调试经验都需要真金白银的尝试才能沉淀下来。如果你是刚开始接触 RAG我建议不要急着上各种花哨框架先老老实实把“加载 → 切分 → 向量化 → 入库 → 检索”这条链路亲手跑通再用 2030 个领域内的高频问题去反复检验检索质量。等你能清楚地说出“为什么这个问题命中不了”“为什么那个问题召回了错误片段”你对 RAG 的理解就已经超过大多数停留在 demo 阶段的人了。先说这些后面有机会再聊聊检索优化的更深层玩法。