1. 为什么我要自己搭一套私域知识库公司内部文档散落在飞书、Confluence、共享盘和一堆PDF里每次找东西都像考古。新同事问“报销流程是啥”我得翻三个系统才能拼出完整答案。市面上的通用AI助手回答不了内部问题因为它们没见过我们的私有文档。这就是我动手搭RAG私域知识库的直接原因。RAG全称Retrieval-Augmented Generation检索增强生成。说人话就是先从你的文档库里找到相关内容再让大模型基于这些内容生成回答。它解决了大模型“不知道你公司内部事”的核心痛点。适合有大量私有文档需要快速检索的团队也适合想入门RAG的开发者。整套流程拆开就三步切分、向量化、生成。听起来简单但每一步都有坑我踩了差不多两周才跑通。这篇文章我会把完整流程拆开讲包括每个环节的参数选择、代码实现、踩坑记录和优化技巧。你照着做大概率能少走一半弯路。2. 整体架构设计与技术选型思路2.1 为什么选RAG而不是微调一开始我也纠结过到底是微调一个模型还是搭RAG微调的成本太高了——需要标注数据、租GPU、反复训练而且知识更新一次就得重新训。RAG的优势在于知识库和模型解耦文档改了只需要重新向量化那部分模型完全不用动。对于知识频繁更新的场景RAG是更务实的选择。另一个考虑是可解释性。RAG能告诉你答案来自哪份文档的哪个段落微调模型做不到这一点。在内部知识库场景下能溯源比什么都重要。2.2 技术栈选型与理由我最终选的技术栈如下环节选型理由文档解析PyMuPDF python-docx覆盖PDF和Word速度快文本切分LangChain RecursiveCharacterTextSplitter递归切分保留语义边界向量化BGE-M3中文效果好支持多语言向量存储ChromaDB轻量本地部署零依赖生成模型Qwen2.5-7B-Instruct中文能力强可本地部署编排框架LangChain生态成熟社区资料多选BGE-M3而不是OpenAI的embedding主要原因是中文语义理解。我实测过同样的中文文档BGE-M3的检索命中率比text-embedding-ada-002高出不少。而且本地部署没有API调用成本数据也不出内网。ChromaDB选它是因为够简单。Milvus功能更强但部署复杂FAISS更轻但没有持久化和管理界面。ChromaDB刚好卡在中间适合中小规模知识库。注意如果你文档量超过百万级建议直接上Milvus或QdrantChromaDB在数据量大了之后检索性能会明显下降。2.3 数据流全景整个系统的数据流是这样的原始文档经过解析变成纯文本然后切分成小块每块通过embedding模型转成向量存进数据库。用户提问时问题也转成向量在数据库里找最相似的N个块把这些块拼成上下文喂给大模型大模型生成最终答案。这个流程里最容易被低估的是切分环节。切分策略直接决定了检索质量的上限切得不好后面向量化和生成再优化也救不回来。3. 文档切分最容易被低估的关键环节3.1 切分策略的核心逻辑切分的目标是让每个块既有完整的语义又不会太长导致检索精度下降。切太大一个块里混了好几个主题检索时噪音大切太小语义不完整模型拿到碎片拼不出答案。我试过三种切分方式。按固定字符数切简单但经常把一句话拦腰截断。按段落切语义完整但块大小不均匀有的段落特别长。最后用的是递归切分优先按段落切段落太长再按句子切句子还长才按字符切。这样最大程度保留了语义边界。3.2 参数选择与计算过程LangChain的RecursiveCharacterTextSplitter有几个关键参数chunk_size每个块的最大字符数chunk_overlap相邻块之间的重叠字符数separators切分符优先级列表chunk_size我最终定的是500。这个数字怎么来的我拿一批典型文档做了测试256太小很多完整段落被切碎1024太大检索时经常召回不相关的块。500左右在中文场景下大约对应200-300个token刚好能容纳一个完整的知识点。chunk_overlap设成50也就是10%的重叠。为什么要重叠因为切分点可能正好落在一个关键句中间重叠能保证这个句子至少在一个块里是完整的。10%是我实测下来比较平衡的值再大浪费存储再小起不到保护作用。separators的设置很关键我用的顺序是separators [\n\n, \n, 。, , , , ., , ]先按双换行段落切再按单换行再按中文句号、感叹号、问号、分号最后才按字符切。这个顺序保证了语义优先级。3.3 代码实现与实操细节from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , ., , ], length_functionlen, is_separator_regexFalse ) chunks splitter.split_text(raw_text)这段代码看起来简单但有几个细节要注意。length_function默认是len按字符数算。如果你用的是token计算需要传入对应的tokenizer。is_separator_regex设成False表示separators里的字符串按字面量匹配不是正则。实操心得切分完之后一定要抽样检查。我当时的做法是随机抽20个块打印出来看发现有几个块开头是半句话说明切分点没落在语义边界上。后来调整了separators的顺序把中文标点提前问题就解决了。3.4 特殊文档的处理技巧PDF解析出来的文本经常有换行混乱的问题。比如一句话中间被硬换行截断导致切分时误判为段落边界。我的处理方式是在切分前先做一次文本清洗把单个换行替换成空格保留双换行作为段落标记。表格类文档更麻烦。PyMuPDF解析表格会变成一堆散乱的文字语义完全丢失。对于表格多的文档我建议单独处理——要么用专门的表格解析工具转成Markdown表格要么在切分时把整个表格作为一个块不拆分。还有一种情况是代码文档。代码里的换行和缩进都有意义不能按普通文本切。我用的策略是给代码块加上特殊标记切分时识别标记把整个代码块作为一个不可分割的单元。4. 向量化把文本变成可检索的数学表示4.1 Embedding模型的工作原理向量化的本质是把一段文本映射到一个高维空间中的点。语义相近的文本在这个空间里的距离就近。比如“如何报销”和“报销流程是什么”虽然字面不同但向量距离很近。BGE-M3输出的是1024维向量。为什么是1024维这是模型训练时确定的维度越高表达能力越强但存储和计算成本也越高。1024维在效果和成本之间是个比较平衡的选择。4.2 模型部署与推理优化BGE-M3我是在本地用FlagEmbedding库加载的from FlagEmbedding import BGEM3FlagModel model BGEM3FlagModel(BAAI/bge-m3, use_fp16True) embeddings model.encode( texts, batch_size32, max_length512, normalize_embeddingsTrue )[dense_vecs]use_fp16True开启半精度推理显存占用减半速度提升明显精度损失可以忽略。batch_size设32是因为我的显卡显存有限你可以根据实际情况调整。normalize_embeddingsTrue做归一化这样后续用余弦相似度检索时只需要算点积速度快。注意max_length一定要设。BGE-M3默认支持8192长度但大部分文档块只有几百字符设成512足够还能防止异常长文本拖慢推理。4.3 批量处理的工程细节实际文档量大的时候不能一次性把所有文本加载到内存。我的做法是分批处理每批1000个块处理完一批存一批。同时加一个进度条方便监控。from tqdm import tqdm batch_size 1000 all_embeddings [] for i in tqdm(range(0, len(chunks), batch_size)): batch chunks[i:ibatch_size] batch_embeddings model.encode(batch, batch_size32)[dense_vecs] all_embeddings.extend(batch_embeddings)这里有个坑如果中途程序崩溃之前算的全丢了。我的解决方案是每批处理完就存到磁盘下次启动时检查已处理的批次跳过已完成的部分。这个断点续传机制在调试阶段特别有用。4.4 向量存储与索引构建ChromaDB的写入很简单import chromadb client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection( nameknowledge_base, metadata{hnsw:space: cosine} ) collection.add( embeddingsall_embeddings, documentschunks, ids[fchunk_{i} for i in range(len(chunks))] )metadata里指定cosine距离因为我们的向量已经归一化了cosine和点积等价但显式指定更清晰。ids必须唯一我用chunk_加序号的方式。实操心得ChromaDB默认用HNSW索引建索引是增量式的。如果你一次性写入大量数据建议分批写入每批之间稍微等一下让索引有时间构建。我试过一次性写10万条检索时发现部分数据还没进索引等了几分钟才正常。5. 检索与生成让大模型说出靠谱的答案5.1 检索策略的优化最基础的检索是拿问题向量去数据库里找最相似的Top-K个块。K设多少我试过3、5、10。3太少有时候关键信息在第四个块里10太多噪音大模型容易被干扰。最终定的是5配合后面的重排序。但单纯向量检索有个问题它擅长语义匹配不擅长精确匹配。比如你搜“2024年Q3营收”向量检索可能返回一堆讲营收的段落但不一定是Q3的。我的解决方案是混合检索——向量检索和关键词检索各取Top-10然后合并去重。# 向量检索 vector_results collection.query( query_embeddings[query_embedding], n_results10 ) # 关键词检索用ChromaDB的where_document keyword_results collection.query( query_embeddings[query_embedding], n_results10, where_document{$contains: Q3} )5.2 重排序的引入混合检索之后候选块可能有15-20个。直接全喂给大模型太浪费上下文窗口而且噪音多。我加了一个重排序环节用BGE-Reranker对候选块按与问题的相关性重新打分取Top-5。from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-v2-m3, use_fp16True) pairs [[query, chunk] for chunk in candidate_chunks] scores reranker.compute_score(pairs, normalizeTrue) # 按分数排序取Top-5 sorted_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:5] final_chunks [candidate_chunks[i] for i in sorted_indices]重排序大概会增加200-300毫秒的延迟但检索质量提升非常明显。我实测下来加了重排序之后答案准确率从70%左右提升到了85%以上。5.3 Prompt设计与生成控制Prompt的设计直接决定生成质量。我的模板是这样的prompt_template 基于以下参考资料回答问题。如果参考资料中没有相关信息请直接说根据现有资料无法回答不要编造。 参考资料 {context} 问题{question} 回答关键点是那句“不要编造”。大模型有很强的补全倾向如果不明确禁止它会自己编答案。加上这句话之后幻觉率明显下降。生成参数方面temperature设0.1让输出尽量确定。max_tokens设1024够用且不会太长。top_p设0.9保留一定的多样性但不会太发散。5.4 完整检索生成流程def rag_query(question): # 1. 问题向量化 q_embedding model.encode([question])[dense_vecs][0] # 2. 混合检索 candidates hybrid_search(q_embedding, question, top_k20) # 3. 重排序 final_chunks rerank(question, candidates, top_k5) # 4. 拼接上下文 context \n\n---\n\n.join(final_chunks) # 5. 生成 prompt prompt_template.format(contextcontext, questionquestion) answer llm.generate(prompt) return answer这个流程跑下来单次查询延迟大概在1-2秒取决于文档量和硬件。对于内部知识库场景这个速度完全可以接受。6. 常见问题与排查技巧实录6.1 检索命中率低的排查思路检索命中率低是最常见的问题。排查顺序应该是先看切分是否合理再看embedding模型是否适合你的语言最后看检索策略。我遇到过一次典型情况用户搜“年假怎么请”检索出来的都是“请假制度”相关但没提到年假的段落。后来发现是切分时把“年假”和“请假流程”切到了不同的块里。调整chunk_size从300到500之后这个问题就解决了。还有一个隐蔽的坑是文档编码问题。有些PDF解析出来是乱码向量化之后全是噪音。排查方法是随机抽几个块打印出来看如果发现乱码就要换解析工具或者做编码转换。6.2 生成答案不准确的典型原因生成不准确通常有三个原因检索没找到正确内容、找到了但被噪音干扰、模型没理解上下文。第一个原因用上面的方法排查。第二个原因可以通过减少Top-K和加重排序来缓解。第三个原因比较少见但如果你的文档里有大量专业术语可能需要换一个领域知识更强的模型。我遇到过一个特殊情况文档里有一句话“本流程不适用于实习生”但模型生成时忽略了“不”字给出了错误答案。这种否定语义的丢失是LLM的常见问题。我的应对方式是在Prompt里强调“注意否定词和条件限定”。6.3 性能瓶颈与优化方向性能瓶颈通常出现在三个地方embedding推理、向量检索、LLM生成。Embedding推理慢的话可以开FP16、减小batch_size、或者换更小的模型。向量检索慢的话检查索引是否构建完成数据量大的话考虑换Milvus。LLM生成慢的话可以量化模型、减少max_tokens、或者换更小的模型。我实测下来7B模型在消费级显卡上生成速度大概是20-30 token/秒对于知识库问答场景够用了。6.4 常见问题速查表问题现象可能原因排查方法解决方案检索结果不相关切分不合理抽样检查块内容调整chunk_size和separators答案编造Prompt未限制检查Prompt模板加“不要编造”指令检索速度慢索引未完成查看ChromaDB日志等待索引构建或分批写入中文效果差模型不适合对比不同模型换BGE-M3或中文优化模型显存不足batch太大监控显存占用减小batch_size或开FP16答案不完整Top-K太小增大K值测试配合重排序取Top-5重复内容多overlap太大检查chunk_overlap降到10%以下特殊字符乱码编码问题打印原始文本统一转UTF-8避坑技巧每次调整参数后建一个包含20-30个典型问题的测试集跑一遍看命中率和准确率。不要凭感觉调参数据说话。7. 一些实操后的个人体会这套系统我跑了三个月最大的体会是RAG的效果上限取决于文档质量不是模型。垃圾文档进去垃圾答案出来。所以前期花时间清洗文档、设计切分策略比后期调模型参数重要得多。另一个体会是不要追求一步到位。我一开始想搞混合检索加重排序加多路召回结果调试复杂度爆炸。后来退回到最简单的向量检索跑通了再逐步加功能反而更快。最后分享一个小技巧在向量化之前给每个块加上来源元数据文件名、页码、章节检索时一起返回。这样生成答案时可以标注来源用户能直接跳转到原文。这个功能对内部知识库来说特别实用信任感直接拉满。