这是《生成式人工智能实战》系列的第四篇。前三篇我们先后解决了环境搭建、提示词工程、以及一个端到端的生成小应用算是把“生成式AI长什么样”这件事跑通了。今天这次实战我不想再停留在demo层面而是选了一个真正能在业务里落地的场景给大模型做一个“私有知识库外挂”让它能基于你自己的文档回答问题。一句话概括这次做的事把一堆内部资料切成小段向量化之后存进本地向量库用户提问时系统先把跟问题最相关的片段捞出来再把这些片段作为上下文交给生成模型由模型组织出一份有依据的答案。这就是当前企业知识问答里最常见、也最实用的RAG检索增强生成落地方式。这篇内容适合三类人正在公司内部做知识库问答工具的开发者想用大模型处理私有资料、但又不愿意重新训练模型的团队以及想彻底弄明白“检索到底怎么和生成配合起来”的进阶学习者。看完之后你会得到一个可以直接复现的完整链路以及我在调参过程中踩过的那些坑。1. 为什么第四期选了RAG这个方向1.1 通用模型记不住你的私有资料这是个真实缺口用过通用大模型的人应该都有同感让它聊天、写文案、翻译效果都在线可一旦问到内部文档里才有的信息它就开始“一本正经地胡说”。原因不复杂训练语料里根本没有你公司的产品手册、内部流程、项目总结这类私有内容。模型只能靠相关性硬猜猜出来的结果当然不可靠。有人会问那重新训练一个模型不就行了理论上可以实操上代价太大。从头预训练需要几千张卡连续跑几个月数据清洗、对齐调优都是重工程一般团队根本扛不住。退一步说就算用微调把某一批知识塞进去隔两个星期文档更新了又得重新来一轮知识越鲜活这条路越走不通。所以在“知识”这件事上更聪明的做法是把知识放在外部而不是塞进模型的参数里。模型负责的是“理解你的问题、根据资料组织回答”资料本身由你随时更新。这正好是RAG的定位一种给模型外挂知识库的机制需要哪段知识就现场查哪段。1.2 RAG对比微调赢在成本和可维护性我从实际维护的角度做过一个对比两者的差别非常明显。微调的优势是能让模型学习某种表达风格、调整角色定位这是RAG不好替代的。但如果目标是“让我自己的文档可以被回答”RAG的性价比要高很多。知识更新时RAG只需要重新解析并写入新文档几分钟内就能生效而微调需要准备训练集、跑训练、验证效果整个周期按天甚至按周算。再从可信度看RAG有一个天然优势答案能溯源。因为模型是依据检索到的具体片段来回答的你完全可以在答案后面附上“这段信息来自哪份文件的哪个位置”。这一点在企业场景里非常关键。用户看到答案出处信任度会高很多出问题时也方便人工复核。微调后的模型只是一个“黑盒”全靠猜它学到了什么。1.3 这个链路要解决的四个核心问题把RAG拆开看整个系统要解决的问题归纳下来就是四条第一把非结构化的原始文档PDF、Word、TXT清洗成可处理的文本第二把长文本切成语义相对完整的片段既不能太长也不能太碎第三把每段文本转化成向量存进支持相似度检索的向量库第四在提问时完成“检索最相关片段 拼装上下文 调用模型生成答案”这一套动作。四个问题分别对应着数据层、切分层、语义层、生成层。任何一个环节偷懒最后答案质量都会打折扣。这次实战我会按这个顺序一层一层带大家搭起来每一层都讲清楚“为什么这么做”再给可以直接用的代码。2. 整体设计与工具选型能离线跑通、能换件、不复杂2.1 设计原则数据不出内网模块随时可换我动手之前先定了三条设计原则后面所有选型都围绕它们展开。第一条数据必须留在本地。企业内部文档往往涉及流程细节、项目数据按隐私惯例不该传到外部服务。所以这套系统的向量化、存储、检索、生成都要跑在本地环境里。第二条模块要解耦。嵌入模型、向量库、底座生成模型这三块尽量互相独立不能绑死。今天用这个嵌入模型效果不好明天能换成另一个而不是推倒重来。第三条单机可跑、资源可控。不做一上来就上分布式那套先让一台普通开发机能跑通后续再考虑扩容。基于这三条技术栈变得很明朗。2.2 工具与依赖清单我用的是Python 3.10配合下面这些库全部是开源组件单机环境就能装完pip install transformers torch chromadb pypdf python-docx numpy逐个说下角色。transformers和torch负责加载开源嵌入模型、把文本转成向量chromadb是本地向量库负责存储向量、做相似度检索pypdf和python-docx分别用来读PDF和Word文档numpy做一些向量运算。有人会问为什么不直接用更重型的向量库因为它是单机场景。我这边文档规模在几万片以内语义检索延迟完全能接受没必要为了一个demo维护一套分布式存储。轻量库的优势在于持久化就是一个目录备份拷贝都很简单换机器直接搬走非常省心。2.3 嵌入模型和底座模型都要适配中文这次处理的是中文文档所以嵌入模型必须选在中文语料上训练过的版本。这一点我最初吃过亏用英文为主的通用嵌入模型来向量化中文文本结果检索质量很差同一个问题搜出来的片段经常和问题搭不上边。中文的语义结构、词语边界和英文差异很大嵌入模型必须对中文有足够的语料覆盖才能理解“报销”和“发票”、“付款”这些词之间的关系。底座生成模型我建议选支持中文的版本7B70亿参数这个级别在普通开发机上基本能跑起来。如果你手头有现成的大模型API服务也可以把生成部分封装成一次HTTP调用这完全不影响RAG链路。3. 从零搭建文档处理链路3.1 文档加载PDF、Word、TXT统一收进来第一步是把混合格式的文档都读成纯文本。我封装了一个load_documents函数先检查文件后缀再分派给不同的解析器读取。需要注意的一件事PDF有两种一种天生带文本层可以直接复制文字另一种是扫描件本质上是图片直接解析会得到一堆空白。from pathlib import Path from pypdf import PdfReader from docx import Document SUFFIX_TEXT {.txt, .md} SUFFIX_PDF {.pdf} SUFFIX_DOCX {.docx} def load_documents(file_paths): docs [] for fp in file_paths: fp Path(fp) if fp.suffix in SUFFIX_TEXT: docs.append({source: str(fp), text: fp.read_text(encodingutf-8)}) elif fp.suffix in SUFFIX_PDF: reader PdfReader(str(fp)) text \n.join(page.extract_text() or for page in reader.pages) docs.append({source: str(fp), text: text}) elif fp.suffix in SUFFIX_DOCX: doc Document(str(fp)) text \n.join(p.text for p in doc.paragraphs) docs.append({source: str(fp), text: text}) return docs这里有一个我在真实项目里踩过的大坑表格类文档。PDF解析器经常把表格的行列顺序打乱读出来的文字就像被切碎的纸片前一句和后一句完全不连贯。遇到这种文档我的建议是先人工检查一遍解析结果必要的话先把表格导出成CSV或者转成带排版的Markdown再进入RAG链路。图里的文字、横版的PPT导出PDF也都不能直接依赖pypdf需要先做OCR这是后话。3.2 文本切分chunk_size和overlap到底怎么定原始文本一页接一页整篇灌给模型肯定不行上下文窗口装不下而且一段1000字的杂糅文本会让模型抓不住重点。所以要把文档切成适合检索的片段也就是chunk这个阶段几乎是整个RAG系统效果好坏的分水岭。我采用的策略是按段落优先切段落太长就按固定长度兜底同时保留overlap重叠区域。下面是一个可以直接用的切分函数def split_text_with_overlap(text, chunk_size400, overlap80): # 先按换行拆出段落避免把标题和正文强行合并 paragraphs [p.strip() for p in text.split(\n) if p.strip()] chunks [] buffer for para in paragraphs: if len(buffer) len(para) 1 chunk_size: buffer (\n para) if buffer else para else: if buffer: chunks.append(buffer) # 长段落内部按窗口滑动切分保持overlap start 0 while start len(para): chunk para[start:start chunk_size] chunks.append(chunk) start chunk_size - overlap buffer if buffer: chunks.append(buffer) return chunks参数上我的经验值chunk_size设400到500个中文字符overlap设80到100个字符。为什么不能太小chunk太短语义不完整检索出来经常是一堆残缺句子模型拼不出有效答案。为什么不能太大chunk太长里面可能塞了五六个无关要点检索噪声会增加而且会白白占掉模型的上下文空间。overlap的意义很多人忽略但实际上非常关键。它让相邻窗口之间有重叠区域这样即使一个完整的语义句恰好落在两个chunk的边界上也至少在一个窗口里是完整的。我实测过把overlap从0调到80之后一些跨段提问的命中率有明显提升。3.3 清洗与元数据别让脏数据拖垮整个链路文档解析出来之后不能直接拿去切分。页眉页脚、重复的目录信息、无意义的空行和特殊字符都会干扰后续检索。我用正则做了三件事去掉连续的空白字符、去掉页码和页眉特征行、把全角空格统一转半角。然后给每个chunk打上source来源路径和一个自增的chunk_id作为后续引用溯源的基础。注意清洗要克制。不要用太激进的规则去删内容比如不要把所有括号内的文字都删掉那很可能是产品参数。我见过有人为了“清洗”把表格里的数据全删了结果库里面全是空壳文本。4. 向量化入库与检索实现4.1 用开源中文嵌入模型做向量化清洗切分之后的关键步骤是把每一段文字变成一组数字也就是向量。向量的意义在于把“语义相近的文本”映射到空间里距离相近的位置这样检索时不再靠猜关键词而是靠算距离。我封装了一个加载函数加载社区里常见的中文文本嵌入模型。你只需要把EMBEDDING_MODEL换成你选定的模型标识即可from transformers import AutoTokenizer, AutoModel import torch import numpy as np EMBEDDING_MODEL your-embedding-model-name device cuda if torch.cuda.is_available() else cpu tokenizer AutoTokenizer.from_pretrained(EMBEDDING_MODEL) model AutoModel.from_pretrained(EMBEDDING_MODEL).to(device).eval() def embed_texts(texts, batch_size32): all_vecs [] for i in range(0, len(texts), batch_size): batch texts[i:i batch_size] inputs tokenizer(batch, paddingTrue, truncationTrue, max_length512, return_tensorspt).to(device) with torch.no_grad(): outputs model(**inputs) # 取CLS位置向量作为整句表征这是常见做法 vecs outputs.last_hidden_state[:, 0, :].cpu().numpy() all_vecs.append(vecs) return np.vstack(all_vecs)为什么取CLS位置的向量而不是把所有token取平均这是因为预训练任务里CLS向量常用来表示整句语义很多中文嵌入模型也都按这个约定训练。实际取哪种向量最稳妥的办法是看模型说明我之前用过一个模型官方明确建议用平均池化取CLS效果就差一截。4.2 写入Chroma并持久化向量库的选择我直接用了一个本地文件型数据库它支持集合管理、余弦距离、持久化而且API干净。下面是入库代码import chromadb from chromadb.config import Settings client chromadb.PersistentClient(path./chroma_store) collection client.get_or_create_collection( nameprivate_kb, metadata{hnsw:space: cosine} ) def add_documents(chunks, sources, ids): vecs embed_texts(chunks).tolist() collection.add( embeddingsvecs, documentschunks, metadatas[{source: s} for s in sources], idsids )PersistentClient指定了一个本地路径chroma_store写入是持久化的下次启动只要用同一个路径之前建好的索引和文档都还在。注意集合的相似度空间我显式指定了cosine也就是余弦相似度。这是文本语义检索最常用的度量和嵌入模型的训练目标也一致。容易踩坑的是运维时如果改了PersistentClient的路径新环境找不到旧库会白白重新入库一遍。建议把路径写进配置文件别写死在代码里。4.3 检索从“查关键词”到“查语义”入库完成后进入检索环节。相对于传统的关键词匹配向量检索的优势在于能理解“同义表达”。比如用户问“发票丢了怎么办”文档里可能写的是“报销凭证遗失处理流程”两者字面上没有任何重合但语义很接近向量检索可以把这种关系找出来。def search(query, top_k5): query_vec embed_texts([query])[0].tolist() results collection.query( query_embeddings[query_vec], n_resultstop_k, include[documents, metadatas, distances] ) return resultsn_results控制召回数量。我一开始习惯设成3结果发现很多情况下答案被截断了因为相关片段可能分散在多个段落里。后来改成召回5个再做精筛效果好很多。关于这个筛选下一节会细说。5. 把检索结果交给大模型生成答案5.1 上下文模板设计约束越明确幻觉越少检索到候选片段之后接下来是组装prompt。很多RAG项目死在最后一步问题是检索结果明明不错模型却不按资料回答而是自顾自发挥。根因在于prompt模板太弱没有给模型划清边界。我用的模板经过多次调整核心逻辑是让模型当一个“资料解读员”而不是一个“自由发挥的专家”。模板结构如下SYSTEM_PROMPT 你是一个企业内部知识库助手。 请严格根据下面给出的资料片段回答用户的问题。 要求 1. 只能使用资料中出现的信息 2. 如果资料不足以回答问题请直接说明“资料中没有找到相关信息”不要编造 3. 回答要简洁用条目列出要点 4. 在答案末尾标注每个要点的资料来源文件名。 def build_prompt(question, chunks_with_source): context \n\n.join( f[片段{i 1}]来源{src}\n{chunk} for i, (chunk, src) in enumerate(chunks_with_source) ) return f{SYSTEM_PROMPT}\n\n【资料】\n{context}\n\n【问题】\n{question}\n\n【回答】关键点是“资料不足就明说”这一条。它看起来简单但作用非常大。模型在被告知可以“不知道”之后反而更倾向于从资料里找信息而不是编一个答案出来。这套模板在内部文档问答里帮我省下了大量人工复核时间。5.2 接入底座模型并输出答案生成模型可以走两条路一条是在本地加载开源底座模型靠GPU推理另一条是调用现成的大模型API。RAG链路本身和底座模型无关我封装成一个统一的问答函数内部无论是模型推理还是HTTP调用对外暴露的都是generate(prompt)。def ask(question, top_k5, score_threshold0.35): results search(question, top_ktop_k) docs results[documents][0] metas results[metadatas][0] dists results[distances][0] # 过滤掉相似度太低的片段避免拿不相关内容凑数 valid [] for doc, meta, dist in zip(docs, metas, dists): if 1 - dist score_threshold: valid.append((doc, meta[source])) if not valid: return 资料库中没有找到足够相关的信息请换一种问法或补充文档。 prompt build_prompt(question, valid) answer generate(prompt) return answer这里dist是余弦距离我用1 - dist转成相似度并设了一个0.35的阈值。低于这个阈值意味着检索到的片段和问题相关度太低直接丢弃宁可回答“查不到”也不要硬给模型塞不相关内容。这个阈值不是固定的我后面会专门讲怎么按数据调。5.3 引用溯源让答案有据可查我在prompt模板里加了“标注资料来源文件名”的要求这样生成的答案末尾会自动带出依据。比如根据资料报销流程如下提交费用明细表。来源项目部费用管理制度.docx部门负责人审批后交财务。来源项目部费用管理制度.docx财务在三个工作日内完成打款。来源项目部费用管理制度.docx这个设计实施起来几乎零成本但对落地价值极大。用户看到答案后能自己核对原文管理员也能快速发现“哪份资料有信息缺失”。在我实际交付过的内部工具里有没有溯源直接影响使用方的验收态度强烈建议保留。6. 调优实测哪一步对效果影响最大6.1 第一批实测结果默认参数给了我当头一棒我第一次跑通整套链路时全是默认参数chunk_size500、overlap0、top_k3、无过滤阈值。测试文档是十几页的项目管理制度问了一个“项目延期后怎么申请变更”的问题。结果非常尴尬答案确实引用了资料但只覆盖了变更申请的流程前三步后面的审批节点和备案要求完全没提到。原因也很明显这七八个步骤分散在文档不同段落里以500字的chunk切分它们被分到了不同片段中而我只召回3个片段其中两个还包含了大段无关的背景说明真正有价值的步骤片段被挤出了候选列表。这个经历让我意识到RAG调优不是玄学而是每个参数都对应着具体的检索质量瓶颈。6.2 三轮调优参数怎么改、依据是什么第一轮我改的是切分和召回数量。把overlap调到80同时保证包含章节标题的段落不跟正文拆散这样长文档里的“小标题 对应内容”更容易落进同一个chunk。再把top_k从3调到5让候选池更大。改完再测变更流程的几个关键步骤都能被检索到了但答案里多了两段不相关内容模型把背景介绍也当成依据写进了回答。第二轮我加了相似度阈值过滤实测设为0.35。低于这个阈值的候选直接丢弃。这样把最明显的“语义不相关”片段挡在了prompt外面回答里基本不再出现跑题的句子。不过又暴露了新问题有些相关片段因为切得太碎相似度只有0.3出头被阈值一并挡掉了导致部分细节丢失。第三轮我围绕“切碎”动刀。检查后发现长段落被机械切成多个窗口时边界处经常出现半句话。我调整了切分逻辑优先保证段落完整只有超过500字的段落才进入窗口滑动并且滑动窗口时尝试在句号、分号处切分而不是硬按长度切。这一步改完之后同一主题的查询基本稳定命中回答也完整了。三轮调参的对照结果如下环节初始状态调优后效果变化文本切分chunk_size500overlap0overlap80段落优先跨段问题命中率明显提升召回数量top_k3top_k5关键步骤不再丢失结果过滤无相似度阈值0.35跑题内容明显减少切分边界硬按长度切尽量在句号处切半句碎片消失6.3 重排机制召回和精排分开做经过三轮调优基础效果已经可用但我还想分享一个提升明显的技巧召回和精排分开。先用向量检索召回20个较宽的候选再用一个更精细的打分规则让这些候选重新排序最后只取前5个进prompt。精排我这条用的是“关键词重合度 片段位置”的综合打分向量相似度作为基础分候选片段里出现与问题相同的高频词就加分出现标题特征的也加分。这个思路在不引入额外模型的前提下让排序质量有了一次肉眼可见的提升。如果你后续有条件还可以接专门的重排模型效果会更稳定但这套轻量方案在单机场景下已经够用。心得RAG系统的效果瓶颈通常不在底模型有多强而在检索质量有多准。检索到的内容不对后面生成能力再强也白搭。所以调优优先级永远是先调切分再调召回最后调过滤和排序。7. 常见问题与排查速查7.1 实操中的典型故障和应对方案我整理了这段时间真实踩过的几类问题按症状分条列出来方便你对照排查症状可能原因处理办法回答问题总是“资料中没找到”相似度阈值设得太高往低调阈值比如从0.5降到0.3检索结果全是无关片段嵌入模型和查询语言不匹配换成中文语料训练过的嵌入模型答案内容残缺只有半截chunk太小或top_k太小增大top_k调大chunk_size答案引用了不存在的细节清洗时误删了关键内容检查清洗正则别过度删除同一批文档重启后库空了向量库路径不一致统一并固定持久化路径首次建库很慢没有开批次向量化设置batch_size批量编码7.2 多轮对话怎么支持如果想让系统支持追问比如用户先问“报销流程是什么”再问“那发票丢了怎么办”第二问如果只看“发票丢了怎么办”检索效果会打折因为模型缺少“报销”这一层背景。我的处理方式很朴素把最近两轮的用户问题和系统回答拼接起来组成一个“带历史的查询”再去做检索。拼接后用当前问题为主、历史为辅实测下来大部分追问场景都能正确理解。7.3 别忘了校验嵌入模型的一致性这是个隐蔽问题。我有一段时间换了嵌入模型但忘了重新入库导致库里存的是旧模型向量查询用的是新模型向量维度都不一样检索直接报错。就算维度恰好相同两个不同模型产生的向量没有可比性。结论就是换嵌入模型必须重建整个向量库这个步骤要写进操作清单。8. 从Demo到能用的最后一步跑通链路之后如果想给团队用我建议再做三件事。第一加一个极简的Web界面我用一个轻量的Web框架半天就搭起来了让非技术人员也能直接提问。第二文档更新要做成定时任务每天重新解析变更文件并增量写入向量库避免知识越用越旧。第三如果涉及多部门文档在metadata里加上可见范围检索阶段就按权限过滤避免越权看到不该看的内容。说回我个人的真实体会。RAG这个方向乍一听很“大模型”其实落地稳定性更多取决于文档工程这些不起眼的细节。同一套模型有人做出来效果惊艳有人做出来答非所问差别往往不在模型选型而在清洗规则、chunk设计、检索过滤这些“笨功夫”。那些看起来琐碎的地方才是真正决定上限的部分。最后分享一个小技巧不要一开始就对着最优参数调先用一套保守参数把链路完全跑通然后再按“检索结果对不对”来逐步修改。我见过太多人在demo阶段就纠结重排模型选型结果连基础检索都没验证过走了不少弯路。这套系统后续还能扩展的方向很多比如引入重排模型、混合关键词检索、支持图片表格理解但前提都是先把当前这个链路的数据质量打磨扎实。动手复现一遍比我在这写一万字都管用。