做了快两年大模型应用落地我最大的感触是模型越聪明越要提防它“嘴硬”。去年组里做内部知识问答模型对公开资料回答得漂漂亮亮可一到公司内部流程文档就开始编条款、编号、负责人全是错的同事开玩笑说它学会了“汇报式写作”。后来我们把方案从“裸模型对话”改成“本地知识库检索增强生成”之后幻觉率肉眼可见地降了下来。这篇就把搭建过程完整梳理一遍从为什么会幻觉讲起到选型、部署、切块、入库、检索、排错一步步写清楚给同样想落地本地知识库的程序员一个可以直接参考的路线。我默认读者已经会Python、懂点Linux但就算你是刚转过来做算法工程的小白跟着走也能把一套可用的问答服务跑起来。1. 为什么大模型会“一本正经地胡说八道”1.1 幻觉的根源不是“笨”是“没学过”很多人以为大模型像搜索引擎一样遇到问题就去某个数据库里查答案。这是最大的误解。大模型本质上是一个参数巨大的概率模型它做的事情非常单一根据你给的上下文预测下一个最可能出现的词然后一个词一个词地续写下去。训练阶段它确实“读”过海量文本但那些内容已经被压缩成几万亿个参数里的数值规律而不是一张张可以原样调取的资料卡片。所以你问它一个它没学过的问题时它不会说“这个我不知道”因为它根本没有“知道”和“不知道”的边界。它的概率分布会告诉他既然前面是“根据公司制度”后面最合理的词可能是“第X条规定是……”——哪怕这条规定根本不存在。用一句话总结就是它在用语言惯性补全内容而不是在检索事实。企业内部文档、私有API说明、未公开的产品参数、刚定下来的流程规范这些内容几乎不可能完整出现在模型的训练语料里幻觉就是这么来的。我在项目里遇到过一个很典型的场景同事问“报销超过5000元需要哪两级审批”模型回答得有模有样还编了一个“财务专用章管理员”的岗位。查了文档才发现真实流程只需要直属上级和部门负责人签字压根没有什么“专用章管理员”。这个岗位名称是全靠“合理想象”补出来的这就是幻觉最危险的地方——它编出来的人和事听起来非常合理。1.2 本地知识库加检索增强生成相当于开卷考试解决幻觉的正路不是让模型去猜而是先给你把正确答案找出来再让模型照着答案回答。这就是“检索增强生成”也就是RAG。把公司文档、操作手册、知识库文章提前切块、向量化存到一个检索系统里。用户提问时先到检索系统里把最相关的几个片段捞出来连同问题一起拼成上下文交给大模型模型再根据这段资料生成最终回答。这就像把考试从闭卷改成开卷。模型不需要“提前背下”你的内部资料它只需要具备阅读理解能力从你给它的几段内容里提取答案就行。阅读理解能力是预训练阶段就具备的通用能力远比你让它记住具体事实更可靠。为什么强调“本地”两个原因。第一是隐私合规企业内部资料往往不允许传到外部服务做向量化本地部署能做到数据不出内网。第二是可控性你可以完全掌控切块方式、检索逻辑、提示词模板出了问题能查能调。外部服务虽然方便但黑盒太多调试空间很小。当然本地部署也有代价主要是硬件成本和运维成本这个我后面会详细算账。2. 动手前先想清楚技术选型与规模估算2.1 四个核心组件怎么选一个完整的本地知识库系统靠的不是某个大模型而是四个组件配合底座大模型、嵌入模型、向量数据库、RAG编排层。这四个里任何一个选错最终效果都会打折。先看底座大模型。它的职责是根据检索结果和用户问题生成自然语言回答这个负责“读”和“写”。选型时重点看三个点中文能力、上下文长度、以及模型量化后在你显卡上能不能跑得动。上下文长度尤其容易忽略如果你的文档块切得比较大或者期望在一次问答里塞进很长的背景说明模型上下文窗口不够会把检索到的资料截断结果质量直接崩掉。建议至少选上下文长度在8K以上的模型16K或者32K更从容。然后是嵌入模型。它的职责是把文本转成可以计算相似度的向量这个负责“查”。很多人会把精力都放在底座大模型上但其实检索效果的好坏一半取决于嵌入模型。领域差异很重要通用的中文嵌入模型在常规语义相似度上没问题但如果你要检索的是代码片段、法律条款、医疗病历这类专业文本最好选在对应语料上做过训练的嵌入模型。判断嵌入模型好坏最直接的办法是在你的真实文档上拿几个典型问题测召回率不要信网上贴出来的排行榜。向量数据库负责存向量和做相似度检索。选型要点是中文分词支持度、是否支持元数据过滤、检索性能和部署运维成本。如果你只有几万条文本块随便选一个开源向量数据库都行性能瓶颈完全不在它身上。但如果你有上千万条数据就要关心索引类型、分片策略和并发查询能力。另外很多向量数据库支持混合检索也就是同时用向量相似度和关键词匹配打分这个功能对专业术语、专有名词的检索特别重要因为中文里很多术语是“字面匹配比语义匹配更可靠”的。最后的RAG编排层是把你整个流程串起来的东西文档加载、切分、向量化、检索、拼提示词、调模型、拿结果。你可以用现成的开源编排框架也可以自己写几十行代码把这几个环节连起来。我个人的建议是刚开始做原型时完全自己写切块函数和检索逻辑加起来也就不到两百行自己写一遍你才知道哪里会出问题。验证完效果之后再决定要不要引入框架来减少重复劳动。2.2 硬件要什么配置才够跑很多人一听到“本地大模型”就觉得要买好几张昂贵的显卡其实没那么夸张。关键在于你怎么给模型做量化。模型显存占用有个简单估算公式参数量B乘以每个参数占的字节数再除以单卡显存利用率。一个7B参数的模型如果用4bit量化每个参数平均占0.5字节那么模型本体大约需要3.5GB显存。再加上推理时的KV Cache和输入输出缓冲实际占用在5到6GB左右。也就是说一张8GB显存的消费级显卡就能跑起来速度虽然不快但做原型验证完全够用。如果你的文档总量不大比如只有几百份PDF文本切块后大约几万个片段那么向量数据库的内存占用也很容易估算。常见嵌入模型的向量维度是768或者1024以768维、float32存储为例每条向量占768乘4等于3072字节约3KB。十万条文本块就是300MB加上索引开销和元数据字段总体不到1GB。这一层对硬件几乎没有压力。我自己的测试环境是一台双卡工作站主力用一张卡跑底座模型另一张卡和CPU内存跑嵌入模型和向量检索。如果你预算有限可以先用小模型把整套链路跑通比如一个7B参数量的中文对话模型配一个轻量嵌入模型确认业务效果没问题后再换13B或者更大体量的模型。换模型只是改一个配置项的事流程代码完全不用动。另外提醒一句如果机器上只有CPU没有GPU也不是不能跑只是推理速度会很感人。7B模型在纯CPU上生成一个词可能要几百毫秒做离线批处理可以接受但做实时对话会非常难受。2.3 微调与RAG的选择思路聊RAG就绕不开微调。这两条路线经常被放在一起比较实际上解决的问题完全不一样。微调是修改模型本身的参数让它学新的表达方式、新的行为习惯比如让模型用更正式的语气写报告或者学会特定领域的结构化输出格式。但微调不适合用来“塞入新知识”因为知识更新快你不可能每个季度都重新训练一次模型而且微调很容易产生灾难性遗忘模型学会了新知识却把老知识忘光了。RAG的优势在于知识和模型解耦。知识更新只需要换文档、重新向量化模型本身不用动成本低、周期短。而且每次回答都能追溯到具体资料片段这个“可追溯性”在企业应用里很重要出了问题能追到是哪份文档给的依据。所以我的原则是能用RAG解决的首选RAG只有模型在输出格式、语气风格、工具调用能力上有硬伤时才考虑用微调去补。大多数企业内部知识问答场景纯RAG加上一套设计良好的提示词就足够了。3. 实操搭建从环境准备到可用问答3.1 环境准备与模型部署开始动手前先确认你的机器上有一块能用的GPU显存至少8GB操作系统建议Linux发行版Windows也能做但坑多一点。规划好一个项目目录先建Python虚拟环境再把相关依赖装进去。mkdir local-kb cd local-kb python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install fastapi uvicorn pip install sentence-transformers pip install pymupdf这里我刻意没有写某个具体的推理框架因为不同框架的安装命令差异不小你只要选择自己熟悉的那一款就行。装好之后把下载好的模型文件放到项目目录下的models文件夹里然后用推理框架暴露一个本地API服务。现在多数推理框架都实现了兼容式接口也就是客户端可以用通用的方式调用这样你的上层代码可以随时切换到不同模型不用改任何一行业务逻辑。启动完底座模型服务后顺手验证一下用命令行发一个最简单的请求确认服务正常返回、显存占用符合预期。这一步别跳过很多问题到最后才发现是模型服务根本没启动好。# 确认模型服务在本地端口正常响应 curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: local-model, messages: [{role: user, content: 你好简单介绍下你自己}], max_tokens: 100}看到一段正常的中文回复就说明底座模型服务通了。接着启动嵌入模型。嵌入模型不需要单独部署服务直接在业务进程里加载就行因为它只做前向计算不涉及文本生成占用资源小得多。这里要提醒一句确保嵌入模型输出向量的维度和向量数据库的索引维度一致不然后面入库那一步会报错。3.2 文档加载与清洗知识库的起点是文档但绝大多数原始文档是不能直接切块入库的。你的文件可能来自PDF、Word、Markdown、网页、Excel每种格式都有各自的坑。我处理得最多的PDF问题集中在三类扫描件、带页眉页脚的导出件、以及多栏排版的论文稿件。扫描件必须先做OCR把图像转成文本页眉页脚如果不清理会被切成大量重复片段严重污染检索结果多栏文档按常规顺序抽取文本时栏与栏之间的内容会串行读起来完全不通顺。清洗阶段我一般按这个顺序处理先把所有文档转成纯文本或结构化文本再统一做编码归一化和规范处理接着去掉页眉页脚、目录页码、水印文字等噪声然后识别文档内部的章节标题把层级结构保留下来最后根据文档类型做结构化输出表格转成Markdown表格或键值对文本代码块转成带标记的纯文本。清洗这一步没有国家标准全靠在实际文档上迭代。我的经验是先拿十份典型文档跑一遍流程看输出质量把规则补到能稳定处理大部分文档为止。不要追求一次把规则做到完美因为内部文档格式经常会变规则能覆盖八成场景就已经很好了。3.3 文本切块做好第一步检索切块是整个RAG链路里最容易被低估的一步。切小了单个片段语义不完整检索到的内容可能只是一句话的碎片切大了一个片段里混进多个主题向量化之后所有主题的信息被“平均”掉检索精度反而下降。这里没有放之四海皆准的固定方案但有几条经过大量项目验证的实践原则。第一条原则优先按文档结构和语义边界切而不是按固定字符数硬切。Markdown的标题、PDF的章节标题、列表项、段落空行都是天然的切分边界。第二条原则给切片设置一个目标长度范围再允许在边界处截断或合并。比如目标长度是600字那么以段落为单位累加超过目标长度且遇到自然边界时切一刀。第三条原则相邻切片之间要有重叠。重叠的作用是防止一个完整的语义单元恰好被切成两半导致信息丢失。中文文本我一般设置目标长度500到800字重叠150字左右实际效果还不错。下面这段代码是我常用的切分逻辑它比固定字符切分要好用得多def split_document_by_structure(text, max_len600, overlap150): # 先按章节标题粗切避免把不同章节的内容混在一起 rough_blocks [] current [] current_len 0 for line in text.split(\n): if line.strip() and len(line.strip()) 50 and ( line.startswith((#, 第, 章节, 一、, 二、)) ): if current: rough_blocks.append(\n.join(current)) current [] current_len 0 current.append(line) current_len len(line) if current: rough_blocks.append(\n.join(current)) # 再按目标长度二次切分确保超大块被拆短 chunks [] for block in rough_blocks: if len(block) max_len: chunks.append(block) continue start 0 while start max_len len(block): split_at block.rfind(。, start, start max_len) if split_at -1 or split_at - start max_len * 0.6: split_at start max_len chunks.append(block[start:split_at 1]) start split_at 1 - overlap chunks.append(block[start:]) return chunks注意我把“第”和“一、”这类中文序号也当成章节边界的信号词因为很多内部文档不会用Markdown规范写标题。切分完之后一定要抽样检查肉眼看看切片是不是语义完整这一步偷懒的话后面检索质量会大打折扣。3.4 向量化与入库文本切好之后下一步就是逐个调用嵌入模型把切片转成向量写入向量数据库。这一步看起来简单但有几个细节决定了你后面排查问题的难度。第一个细节是元数据字段必须设计清楚。我给每个文本块记录的字段包括文档来源、一级章节名、原文页码、入库时间、文档版本。别小看这些字段它们既用来做检索结果的引用展示也是做元数据过滤的基础。比如用户只查某个特定产品的文档检索时可以直接按产品字段过滤大幅提升相关性。第二个细节是批量入库。嵌入模型的推理虽然比大模型生成快得多但逐条调用还是有网络开销和进程切换开销。建议每批处理32或64个文本块把向量和元数据组装好之后一次性写入。这里可以加一个简单的进度打印万一中断了也知道处理到哪里。第三个细节是去重。同一份文档被重复导入、或者不同文档含有大段相同内容在向量库里会产生重复片段导致检索结果高度相似页面显示全是同质内容。入库前对文本内容做一次哈希去重或者用简单的模糊去重都能缓解这个问题。入库完成之后抽查几个典型问题的检索结果确认top-k返回的前几条内容确实是和问题相关的。这一步验证非常重要检索好后续生成才有基础保障。3.5 检索与问答链路检索和生成是串联在一起的先说检索。用户问题进来后第一步先做向量化拿问题向量去向量数据库里做相似度搜索取回top-k个候选片段。这里的k值建议先设5到8看效果再调。k太小可能漏掉关键资料k太大则会在提示词里塞入很多不相关信息反而干扰大模型判断。在返回最终上下文之前我强烈建议加一个重排序步骤。向量相似度是嵌入模型视角的相关性重排序则是用专门的交叉编码器把问题和片段两两拼接打分可以纠正向量检索带回来的“看似相关实则无用”的结果。比如用户问“如何申请加班补贴”向量检索可能拉回一篇同时提到加班和补贴但主要讲“报销”的文档。重排序模型会把真正的补贴申请流程排到最前面。重排序会增加几毫秒到几十毫秒的延迟但对答案质量的提升非常值。然后是拼提示词。这一步最核心的原则是明确告诉模型它只是一个基于资料回答问题的助手不要依赖训练时学到的知识。下面是我在项目里用过的提示词模板效果比较稳定你是一个企业内部知识问答助手。 请严格根据下面提供的资料片段回答用户问题。 要求 1. 如果资料中没有明确答案直接回答“资料中未找到相关内容”并建议用户查阅原始文档。 2. 不要自行推断、扩展或编造任何事实。 3. 回答时先给结论再补充细节并标注信息来源。 资料片段 {context} 用户问题 {question}上面这个模板里的“不要自行推断”是最关键的一句话。模型在开卷考试时仍然有让回答看起来更完整的倾向明确禁止它补写细节幻觉率会直线下降。3.6 服务化与效果验证到这一步核心链路已经能跑通了。为了让别的系统和同事能用起来我通常会在最外层包一个轻量HTTP服务提供两个接口一个是上传文档并触发入库的接口一个是普通问答的接口。接口定义尽量简单问答接口直接接收问题和可选的产品过滤条件返回答案、引用来源片段列表和检索耗时。这里有一件很容易被忽略的事验证不能只靠一两个例子。我当时在项目里建了一个只有二十多条问题的“测试集”覆盖典型提问、边界提问、故意刁难的提问这几种类型。每次改切块参数或提示词模板就用同样的测试集跑一遍对比答案质量和引用正确率。不做回归测试的话你常常会发现某个问题修好了另外三个问题又变差了而且你根本不知道是哪个改动导致的。我自己做过一次印象很深的回归有一次把重叠字数从150改成100有一个问题回答得更好了但另一个问题开始出现引用错位就是因为重叠太小切到一半的段落没被完整召回。有了测试集做回归这种问题几分钟就能定位出来。4. 常见问题与排查技巧实录4.1 检索结果不对怎么办检索结果差是RAG项目里最常遇到的问题大部分人第一反应是“换个更好的嵌入模型”但实话说很多检索问题不是嵌入模型的锅而是前面的数据加工出了问题。排查有一个固定的顺序先查文本清洗质量再查切块策略然后查检索参数最后才换模型。我做过一个印象很深的项目检索不到结果怎么调嵌入模型都没用。后来把切片打印出来一看才发现原始PDF的标题和正文在清洗时被搅在了一起标题全是“XXXX系统操作手册”正文全是“系统登录之后点击左侧菜单……”向量化之后所有片段的内容高度相似当然召不回问题相关的答案。问题现象可能原因排查方法检索结果大量重复文档有大量重复片段未去重打印top-k看内容加哈希去重检索到相关内容但位置靠后k值太小或重排序未生效调大k检查重排序链路的输出包含明显无关文档元数据过滤没有生效检查过滤条件是否被正确传递专有名词检索不到嵌入模型不熟悉领域词汇测试混合检索或换领域嵌入模型4.2 模型还是乱编答案怎么办如果检索结果明明是对的但模型仍然在回答里编内容那就要检查两个地方。第一个是提示词里有没有明确约束“不知道就直说”。有些模型的指令遵循能力比较弱约束写得不强它就选择自由发挥。第二是最终送去生成的上下文到底长什么样。我们组当时遇到过一种很隐蔽的情况检索结果里明明有正确答案但拼完提示词后超长模型窗口把后半段截断了正确答案恰好被切掉模型只能靠前半段没有答案的内容硬编一个回答。排查这一类问题有一个笨但极其有效的方法把每次问答的完整输入和输出都打日志把最终提示词完整打印出来人眼检查一遍上下文里有没有正确答案。这一步能直接定位是检索问题、截断问题还是模型约束问题。绝大多数“检索有结果但回答乱编”的场景经过这一步排查都能快速定位。4.3 性能、内存问题的排查推理速度慢是最容易被感知的问题但它往往不是模型本身太慢而是推理配置没做对。首先要检查的是KV Cache是否开启。不开启的话每次生成一个词都要重新计算之前的全部历史速度大概会慢三到五倍。其次是批量推理如果你要处理的不是实时对话而是离线批量任务把多条请求拼成一个批次交给模型推理吞吐量会明显提升。最后是并发数的控制消费级显卡的显存有限并发太高容易直接触发显存溢出建议设置一个最大并发数超出部分排队等待。另一个常见的显存问题是上下文设置太大。有时为了能塞进更多资料把上下文调到模型支持的上限但KV Cache的显存占用和上下文长度成正比。如果发现显存吃紧优先检查上下文长度设置是否合理而不是直接换显卡。对于绝大多数问答场景上下文开到4K到8K已经足够覆盖几段检索材料了。4.4 中文文档处理的坑中文文档的坑比其他语言多出一大截。我处理过一批表格密集的Word文档用常规方法转成纯文本之后表格结构全丢了每一行是被空格分隔的碎片根本没法看。后来改用表格抽取方案先把表格识别出来转成键值对文本或Markdown表格再作为独立块入库效果才正常。中文文档里还有全角半角符号混用、复杂的排版样式、扫描件里模糊的字体等问题都会直接影响切分和向量化的质量。如果你处理的PDF主要是扫描件那么OCR是绕不开的一步。OCR的质量直接决定知识库的天花板如果OCR出来的文本乱码连篇后面无论用什么模型都救不回来。建议先拿一批样张测试OCR效果确保识别精度让人能接受再批量处理。我见过一个项目OCR在发票上的识别还行但到了营业执照上就错字连天就是因为没先做样张验证几千页都白处理了。最后分享一个我在几次项目里反复踩坑之后养成的习惯每次调整任何参数先完整跑一遍小范围回归再上全量数据。RAG链路里每个环节都互相影响改一个数字可能带来连锁反应。参数调整记录也建议整理成简单的表格把日期、改动项、测试集效果记下来免得过了两周忘了为什么当时要这么调。这套链路本身不复杂但把每一个细节都抠到位才是它真正能落地、能减少幻觉的关键。