企业官网建设流程全解析

做了快两年大模型应用落地，我最大的感触是：模型越聪明，越要提防它“嘴硬”。去年组里做内部知识问答，模型对公开资料回答得漂漂亮亮，可一到公司内部流程文档就开始编，条款、编号、负责人全是错的，同事开玩笑说它学会了“汇报式写作”。后来我们把方案从“裸模型对话”改成“本地知识库+检索增强生成”之后，幻觉率肉眼可见地降了下来。这篇就把搭建过程完整梳理一遍，从为什么会幻觉讲起，到选型、部署、切块、入库、检索、排错，一步步写清楚，给同样想落地本地知识库的程序员一个可以直接参考的路线。我默认读者已经会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_len=600, overlap=150): # 先按章节标题粗切，避免把不同章节的内容混在一起 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系统操作手册”，正文全是“系统登录之后，点击左侧菜单……”，向量化之后所有片段的内容高度相似，当然召不回问题相关的答案。

4.2 模型还是乱编答案怎么办

如果检索结果明明是对的，但模型仍然在回答里编内容，那就要检查两个地方。第一个是提示词里有没有明确约束“不知道就直说”。有些模型的指令遵循能力比较弱，约束写得不强它就选择自由发挥。第二是最终送去生成的上下文到底长什么样。我们组当时遇到过一种很隐蔽的情况：检索结果里明明有正确答案，但拼完提示词后超长，模型窗口把后半段截断了，正确答案恰好被切掉，模型只能靠前半段没有答案的内容硬编一个回答。

排查这一类问题有一个笨但极其有效的方法：把每次问答的完整输入和输出都打日志，把最终提示词完整打印出来，人眼检查一遍上下文里有没有正确答案。这一步能直接定位是检索问题、截断问题还是模型约束问题。绝大多数“检索有结果但回答乱编”的场景，经过这一步排查都能快速定位。

4.3 性能、内存问题的排查

推理速度慢是最容易被感知的问题，但它往往不是模型本身太慢，而是推理配置没做对。首先要检查的是KV Cache是否开启。不开启的话，每次生成一个词都要重新计算之前的全部历史，速度大概会慢三到五倍。其次是批量推理，如果你要处理的不是实时对话而是离线批量任务，把多条请求拼成一个批次交给模型推理，吞吐量会明显提升。最后是并发数的控制，消费级显卡的显存有限，并发太高容易直接触发显存溢出，建议设置一个最大并发数，超出部分排队等待。

另一个常见的显存问题是上下文设置太大。有时为了能塞进更多资料，把上下文调到模型支持的上限，但KV Cache的显存占用和上下文长度成正比。如果发现显存吃紧，优先检查上下文长度设置是否合理，而不是直接换显卡。对于绝大多数问答场景，上下文开到4K到8K已经足够覆盖几段检索材料了。

4.4 中文文档处理的坑

中文文档的坑比其他语言多出一大截。我处理过一批表格密集的Word文档，用常规方法转成纯文本之后，表格结构全丢了，每一行是被空格分隔的碎片，根本没法看。后来改用表格抽取方案，先把表格识别出来，转成键值对文本或Markdown表格，再作为独立块入库，效果才正常。中文文档里还有全角半角符号混用、复杂的排版样式、扫描件里模糊的字体等问题，都会直接影响切分和向量化的质量。

如果你处理的PDF主要是扫描件，那么OCR是绕不开的一步。OCR的质量直接决定知识库的天花板，如果OCR出来的文本乱码连篇，后面无论用什么模型都救不回来。建议先拿一批样张测试OCR效果，确保识别精度让人能接受，再批量处理。我见过一个项目，OCR在发票上的识别还行，但到了营业执照上就错字连天，就是因为没先做样张验证，几千页都白处理了。

最后分享一个我在几次项目里反复踩坑之后养成的习惯：每次调整任何参数，先完整跑一遍小范围回归，再上全量数据。RAG链路里每个环节都互相影响，改一个数字可能带来连锁反应。参数调整记录也建议整理成简单的表格，把日期、改动项、测试集效果记下来，免得过了两周忘了为什么当时要这么调。这套链路本身不复杂，但把每一个细节都抠到位，才是它真正能落地、能减少幻觉的关键。