企业官网建设流程全解析

1. 内容整体设计与底层逻辑

1.1 知识基础到底指什么

我经常在技术社区看到一种现象：新手一上来就追着“最强开源模型榜单”跑，今天试Llama，明天换Qwen，后天又去折腾Mixtral，折腾半天发现自己连一个能落地的业务场景都做不出来。问题出在哪？出在很多人把大模型当成一个“开箱即用”的黑盒，以为模型文件一加载、API一调通，AI能力就自动长出来了。

但实际上，大模型应用落地这件事，真正的分水岭从来不是模型本身的参数规模和榜单分数，而是你喂给它的“知识基础”够不够扎实。这里说的“知识基础”包含两层含义：第一层是通用常识，也就是模型在预训练阶段从海量文本里学到的世界知识；第二层是领域知识，也就是你需要通过RAG（检索增强生成）、微调、提示词工程等方式，额外补充给模型的、你所在行业和业务场景里的专属知识。

打个生活化的比方：一个刚毕业的高材生，底子很好、脑子很快（对应预训练完毕的大模型），但他要是完全不懂你们公司的业务流水线、行业术语、客户习惯，你直接把他扔到客服岗位上，他大概率会把事情搞砸。你得先给他培训手册、历史案例、产品文档（对应你的知识库建设），甚至让他跟着老员工实习一段时间（对应微调和上下文学习），他才能真正上手干活。

所以这篇内容，我不想再重复“什么是Transformer”“注意力机制怎么算”这类教科书知识，而是想从实际工程落地的角度，聊清楚一个核心事实：知识基础的建设和管理，才是大模型项目成败的决定性因素。无论你是做本地部署、微调、还是搭建Agent应用，这条主线都会贯穿始终。

1.2 为什么很多人把“模型”和“知识”混为一谈

这是个很有意思的认知误区。很多初学者会把模型文件本身当成知识的载体，认为“我下载了一个70B的模型，它就什么都知道”。这个理解对了一半。模型确实通过海量预训练把知识压缩进了参数里，但它的知识有几个天然限制：

第一，知识有截止日期。预训练数据通常有固定的采集时间段，之后发生的事情模型一概不知。比如你用2023年初的模型问2025年的行业政策，它只能瞎编或者直接“一本正经地胡说八道”。

第二，知识有覆盖盲区。通用模型对大众领域（新闻、文学、常识、编程）覆盖较好，但对特定行业（比如纺织业的疵点检测标准、某个企业内部的项目管理系统操作规范、某只股票的特殊财务指标含义）几乎是空白。

第三，知识无法自发更新。模型跑推理的时候，参数是冻结的，它不会因为你在对话里纠正了它一次，就永久记住这个修正。很多初学者以为多聊几轮“记住，以后都按这个标准来”，模型就真的记住了——不会的，那是上下文窗口里的临时记忆，关掉对话就归零。

正是这三个限制，决定了我们必须主动构建“知识基础”。而构建的方式，又反过来决定了你的应用是“能用”还是“好用”。我见过太多失败的案例，都是因为团队把99%的精力花在比较模型选型和花大价钱买显卡上，却连一份结构化的领域知识库都拿不出来，最后做出的Demo像是一个知识渊博但脑子混乱的专家——什么都能聊，什么都聊不细，真正干活全是错的。

2. 知识基础的三种构建路径与选型思路

2.1 路径一：RAG —— 外挂知识库，轻量且主流

RAG（Retrieval-Augmented Generation）是目前落地最广泛的知识注入方式，原理通俗讲就三步：先把你的文档切片、向量化存入向量数据库；每次用户提问时，先在库里检索出最相关的片段；然后把片段连同问题一起拼进Prompt，让模型基于检索到的片段作答。

这条路线的最大优势是知识实时可更新。你不需要重新训练模型，也不需要动显卡训练流程，只需要往知识库里新增或删除文档，回答效果就会跟着变化。今天的行业政策变了，把新文件传进去，明天模型就用新知识回答；某个文档过期了，删掉对应向量，它就不会再引用。

但RAG有个关键挑战，就是切分和检索质量。我见过很多人拿了个PDF就一股脑丢进去，切分逻辑粗糙，检索出来的片段文不对题，最终模型拿着不相关的上下文胡编。这块的坑我在后面的实操章节会详细展开。

RAG适合哪些场景？知识更新频繁、对事实准确性要求高、领域文档数量可观且结构清晰。典型如企业内部知识库问答、客服辅助、合规审查辅助、医疗文献检索辅助。成本上，RAG不需要昂贵的GPU训练环境，CPU也能完成向量化（只是慢一点），上手门槛在三条路径里最低。

2.2 路径二：微调 —— 内化知识，改变行为风格

微调（Fine-tuning）是另一条路，它不再是把知识“挂在外面”，而是通过额外的训练，把特定领域的知识、表达风格、输出规范“刻进”模型的参数里。这条路径适合的任务，往往不只是“知道什么”，还包括“怎么说话做事的风格”。

举个例子：你要做一个面向法律行业的文书生成助手，希望模型输出的裁判文书结构符合法院格式、用词严谨精确、法条引用规范。这种场景下Prompt方式很难彻底约束格式细节，RAG也解决不了“风格内化”问题（检索来的法律条文不会改变模型的写作风格），这时候微调就更合适。

另一个微调的典型用途是指令遵循能力的定制化。基础模型可能输出冗长、口语化的答案，但企业要求必须输出结构化JSON、指定字段名、固定语气，微调可以让模型稳定遵循这些约束。

不过微调的门槛明显更高。你需要准备海量高质量的“输入-期望输出”配对数据，需要有GPU训练环境，需要处理过拟合、灾难性遗忘、数据质量筛选等问题。而且微调并不能让模型“记住”大量新事实——它擅长的是行为模式的改变，而不是百科式知识的事实注入。真想让它掌握某个冷门知识点，RAG仍然是性价比更高的方式。

这里顺便说一句，很多人看到热搜词里“大模型微调实战”“GPU微调大模型”就头热，以为微调是万能的。从我自己的实践来看，微调是最后一公里，不是第一步。在你还没建好一份靠谱的领域知识库之前，不要去碰微调。

2.3 路径三：提示词工程与Agent —— 盘活已有知识

有些场景既不需要RAG也不需要微调，你要用的知识其实模型已经会了，难的是怎么把它按需调度出来。这就是提示词工程和Agent框架的用武之地。

比如“如何使用大模型分析不同股票的K线图”，模型并没有去过你的行情数据库，但你给它完整的K线形态定义（头肩顶、双底、MACD金叉），制定分析步骤的提示词框架，它就能按框架一步步推演。再比如“像工业AI检测、服装检测这类AI用的是云联网还是单机的AI”——这个问题的核心知识点其实在于部署架构选择，模型懂这些概念，你要做的是通过提问技巧把它的知识引导出来，并把行业约束条件说清楚。

Agent框架则是更高阶的玩法。把大模型作为“大脑”，给它注册工具（调用行情API、读取数据库、执行Python脚本、调用检测算法），它负责理解任务、拆解步骤、调用工具、汇总结果。热搜里提到的“主流的Agent框架有哪些”，本质就是在问怎么把大模型的知识能力跟外部系统对接起来。这种情况下，知识基础不再只是文档，还包括“工具使用说明书”——你得告诉模型每个工具是干什么的、参数含义、输出结构，它才指挥得动这些工具。

我在实际开发中，最优的做法往往是三者混合：RAG提供事实依据，微调统一输出风格，提示词工程与Agent负责流程编排和应急兜底。预算不足的团队，我强烈建议先做RAG+提示词工程，跑通了再评估微调的必要性。

3. 知识库建设的实操要点与经验教训

3.1 高质量知识库的“炼金”过程

以我负责过的企业知识问答项目为例，核心流程可以拆成五个阶段：数据采集 -> 清洗与标准化 -> 切分策略设计 -> 向量化与索引 -> 评估与迭代。

数据采集阶段，很多人直接拿一堆PDF、Word、扫描件丢进去完事，这是大忌。你要先问自己三个问题：这些文档多久更新一次？谁负责维护？哪些文档是口径冲突的？企业内部往往存在多个版本的规章制度，新旧述不一致的情况非常常见。建库前必须确立“权威来源清单”，明确哪些文件是知识库的主数据源，其余一律弃用或者标记为低优先级。

清洗阶段最为耗时但最容易被忽视。PDF常见的表格提取错乱、扫描件的OCR识别错误、Word里的批注残留，都会让最终切分出来的文本片段质量惨不忍睹。我踩过的坑包括：一段文本中间因为表格跨页被硬生生切断，导致前后毫无上下文关联；某份合同的关键金额被OCR识别成了奇怪的字符，模型还一本正经地引用。清洗的目标不是让文档“看起来干净”，而是让文本语义连贯、无噪声、无断点。

切分策略设计非常考验功力。固定长度切分（比如每512个token一段）实现最简单，但对语义的破坏很严重——一个完整的方法论章节可能被切成三段，检索时可能只召回其中无关紧要的一段，回答自然缺胳膊少腿。我更推荐按文档结构切分：先识别标题层级，以章节为单位切分；章节过长再按段落和语义边界递归切分。每段之间保留一些重叠区域（我常用1/10左右的重叠比例），避免检索命中了段落边缘导致上下文信息丢失。

3.2 向量化与检索：不止“Embedding一下”那么简单

向量化这一步，技术选型上很多人会纠结用哪个Embedding模型。说实话，如果你的文档是通用领域中文，主流的开源模型（比如BGE系列、M3E系列）表现都不错；如果是垂直行业，强烈建议用你自己领域的语料试跑一遍检索效果再定。判断标准就是召回率——针对100道你事先准备好的、有标准答案的领域问题，看检索系统能不能召回正确答案所在的片段。

Embedding模型选好之后，更关键的是混合检索策略。只靠向量相似度检索有两个天然短板：一是对精确编号、专有名词、型号参数的召回不如关键词精准，比如用户问“GB/T 12345标准”，向量可能因为语义相近召回一堆关于其他标准的文本，而关键词检索能直接命中；二是对同义改写很敏感，同一个意思换种说法向量相似度可能掉得厉害。我目前的方案是“BM25关键词检索 + 向量检索”双路召回，再用RRF（Reciprocal Rank Fusion）把两路结果合并排序。实测下来，对包含大量专业术语的工业文档，召回率比纯向量检索能提升10个点以上。

送到模型之前的最后一步，上下文压缩也别忽略。检索回来的片段往往很长，直接全塞进Prompt既浪费token，又可能给模型带来干扰信息。我在这一步用一个小模型做“相关性重排”（rerank），把召回的top 20挤压到top 3~5，裁掉与问题无关的冗余句子，再拼进Prompt。这个小改动让最终回答的准确性提升明显，尤其在知识库里相似文档较多的时候，干扰问题会非常突出。

3.3 本地部署对知识库的影响

近几年“ollama部署本地大模型”“本地部署大模型让个人电脑智能化”的热度一直很高。很多个人用户在自己电脑上跑7B或13B模型，然后用它做知识库问答。方向是对的，但有一个认识需要澄清：本地部署模型的能力上限，直接影响你知识库回答质量的天花板。

7B量化模型的逻辑推理能力、指令理解能力，跟70B级别模型相比有明显差距。知识库内容如果偏简单（比如公司制度问答、产品FAQ），7B模型勉强够用；一旦涉及复杂分析（比如要求模型对比多个文档的矛盾之处、做多步推理），小模型往往力不从心——它可能检索到的信息是对的，但综合归纳时把逻辑搞乱了。

我的建议是：个人电脑跑知识库问答，优先选7B~14B范围内推理和中文能力均衡的模型；如果显卡显存允许，上14B的量化版本体验会好很多。另外，用ollama这类工具部署时，记得把上下文长度（context length）调大——默认的2K上下文对RAG来说远远不够，我一般至少设到8K，很多场合16K更稳妥。这个参数很多人忽略了，但它直接影响你能往Prompt里塞多少检索片段，进而影响回答质量。

4. 实操过程：一个可直接抄作业的知识库问答搭建

4.1 环境准备与工具选型

我以一个“技术文档问答机器人”为例，完整跑一遍RAG流程。环境是一台32GB内存、8GB显存的消费级显卡机器，系统Ubuntu 22.04。这种配置在个人用户里比较常见，跑7B量化模型没有问题。

工具选型如下：

4.2 知识库构建与检索的详细步骤

第一步：文档清洗与切分。我用Python写了个简单的预处理脚本，先把PDF用pdfplumber提取文本，检测并修复表格错乱，删除页眉页脚，然后以文档的二级标题为边界切分。切分后的每个片段控制在300~500个中文字符左右，对于特别长的段落再按句号分割，同时保证相邻片段有10%的重叠。

第二步：向量化入库。用BGE-M3给每个片段生成向量，存进Chroma。Chroma的使用非常简单，几行代码就能创建collection、add documents、执行查询。我自己在这个阶段会额外给每个片段打上“元数据标签”，比如来源文档名、章节路径、文档版本日期。这些元数据是后面做检索过滤的重要基础——比如用户只问“2025版”的制度，我就能直接通过元数据过滤掉旧版本文档的向量。

第三步：检索增强。用户提问后，我先做两个动作：一是把问题转化为向量，在Chroma里做相似度检索；二是对问题做分词，用BM25跑关键词检索。两路结果各自取前20名，用RRF算法合并重排，再把前5名片段做冗余过滤和去重，交给一个小的rerank模型精筛到前3名。

第四步：构造Prompt。我固定用一套带“引用来源”强调的提示词模板：先说明你是知识问答助手，只依据给定资料回答；然后按照“相关资料 + 用户问题 + 回答要求”的顺序组装。回答要求里明确“如果资料中没有答案，直接说不知道，不要编造；引用资料内容时标注来源文档名”。最后把组装好的Prompt发给Ollama提供的本地模型。

第五步：回答质量检查。收到模型输出后，我会额外跑一次“答案与资料来源一致性校验”。最简单的做法是把回答中出现的实体和关键数字提取出来，跟资料片段做匹配比对。这一步在当前代码实现里不复杂，但能拦截掉相当一部分幻觉输出——比如模型引用了资料里根本没有的张三，或者写错了标准编号。

4.3 关键参数与调优记录

一个容易踩坑的参数是Embedding的chunk_overlap（块重叠）。我看到很多教程推荐完全不重叠，理由是省存储；但实际检索中，文档段落边界处经常是“引言后半段+结论前半段”，重叠太短，检索到边界片段时容易丢失关键句。我在10%~15%之间反复测试，最后定为10%，单片段500字左右，重叠50字。存储成本增加不多，但边界片段的召回准确率明显更好。

温度（temperature）参数我也要特别提一句。知识库问答场景追求精确，温度我是直接调到0或接近0（比如0.1）。很多人图“回答更自然”把温度调到0.7甚至更高，结果是同一个知识库回答同样的两个问题，两次生成的关键结论都能不一致，这种“性格不稳定”对于知识问答是致命的。

还有检索数量（top_k）。我一开始图省事，直接把top_k调到20全塞给模型，结果模型被一堆弱相关文本干扰，反而把答案带偏了。后来改成先召回20、重排精筛到3，回答针对性提升非常明显。这个思路也很好理解：知识库问答吃的是“精准”，不是“材料多”；只给模型最相关的三块材料，它专心多了。

4.4 几个典型问题的现场排查记录

问题一：模型总是答非所问，引用的内容跟问题毫无关系。

排查步骤：先看检索阶段返回的片段相关性，如果片段不对，说明切分或向量化有问题；如果片段是对的，模型还是答错，再排查Prompt构造和模型能力。我遇到过一次切片边界切断了关键定义句，导致检索召回的内容是残句，模型只能对着半截文本硬编。最后通过切分策略调整（按语义段落切，不只按长度切）解决。

问题二：检索结果里的片段本身包含错误信息，模型也跟着引用。

因为知识库里的某个Excel转出来的表格文本是乱的，数字完全对不上。这个问题的根源是清洗不到位，不是检索和生成的问题。后来我在入库前加了自动化格式校验——对每个切分片段做“信息完整性检测”，比如截面含数字型文本就抽查关键字段是否能被正则正确匹配。

问题三：模型用通用知识“编造”资料里没有的答案。

这种人最容易误解为“模型能力不够”。其实根源在于Prompt约束不到位。我给Prompt里加了一句硬约束：“若检索资料中无直接答案，必须明确回复无法作答，禁止自行补充”，并且把检索到的最低相关度阈值也做了限制——如果所有召回片段的相关度都低于0.5，就直接丢弃检索结果，让模型回答“知识库中暂无相关信息”。这个调整下来，编造率大降。

5. 从知识库到微调再到Agent的进阶路线

5.1 什么时候该从RAG升级到微调

做了几个RAG项目之后，你会慢慢摸到它的天花板。最典型的三个信号：第一，输出风格始终不受控，Prompt里怎么写约束，模型还是按它自己的语言习惯来；第二，领域术语的稳定性差，模型一会儿用“客户”一会儿用“用户”，对于严谨场景是硬伤；第三，指令执行模式固化不下来，比如你希望模型凡是遇到某类问题都先追问缺失参数再回答，它时做时不做。

出现这些信号，才开始考虑微调。我在做工业领域的一个质检报告生成项目时，就是这种情况：RAG已经能把参考标准找得很准，但生成的报告文本格式总是不统一，同样的缺陷描述有时写“表面划痕明显”，有时写“表面存在明显划痕，长度约xx毫米”，检测人员还得逐条核对修改。后来拿了历史报告做微调，统一了描述口径和报告结构，才真正解决了问题。

微调的实操要点，我只强调几个很容易翻车的细节。数据量上，领域风格微调通常几千条高质量数据足够，不必追求几万条；数据质量上，宁可要1000条人工精校的样本，也不要一万条从网上乱抓的噪声数据；训练策略上，用LoRA这类参数高效微调（PEFT）方法，不要轻易全参数微调——前者在消费级显卡上就能跑，后者动辄专业服务器。

5.2 Agent框架下的知识调度

一旦进入Agent领域，“知识基础”的定义又得拓展。模型除了要掌握领域事实（通过RAG或微调获得），还要能理解“工具怎么用”“任务怎么拆”。热搜里“目前主流的Agent框架有哪些”，我常用的有LangGraph、AutoGen、以及一些轻量自研框架。

一个很实用的经验是：Agent框架的复杂度要与任务复杂度匹配。简单的“查知识库回答一个问题”，没必要上Agent，RAG直连就够了；但“每天自动抓取行情数据 -> 分析K线形态 -> 生成投资分析报告”这种多步骤任务，就需要Agent编排。我设计这类Agent时会专门给模型配置“工具说明书”知识片段——每个工具的名称、功能、输入输出结构、常见报错，都作为知识库条目供模型检索。这样模型在需要时能准确调用工具，而不是靠猜。

5.3 关于大模型选型的一个清醒认识

最后说一个经常被问到的问题：“到底选哪个模型好？”我的回答一直是：先定知识基础方案，再选模型。你的知识库质量、切分策略、检索链路决定了下限，模型只决定上限。对于很多场景，7B级别的模型加上精良的知识库，已经能跑出远好于裸用70B模型的效果。反过来，知识库一团糟，再强的模型也是拿着垃圾材料写满分作文——错得有理有据。

如果非要给选型一个参考，我的经验是：通用聊天助手类，Qwen系列和GLM系列的中文综合体验都不错；知识问答重事实准确性，选指令遵循能力强、幻觉少的模型（可以拿你自己的知识库问题集去横向测）；代码生成类，CodeLlama和DeepSeek系列我用的比较多；多模态OCR类场景，Qwen-VL系列表现稳定。

个人实操体验与最后两个建议

这套方法论我实践了近一年，最大感触是：大模型项目没有那么多“玄学”，大部分问题出在知识基础工程上。那些网上被吹得神乎其神的“调参魔法”，很多时候不如把文档清洗干净、把切分策略调对、把检索链路做扎实来得有效。

最后给你两个建议。第一，在动手做任何大模型应用之前，先拿出一周时间专门建设知识库：梳理权威来源、清洗文档、设计切分、做检索效果测试。这一周花得很值，它决定了你后面所有的效果调优是事半功倍还是事倍功半。第二，建立“知识库版本管理”习惯——知识库跟代码一样需要版本控制，每次修改都要能回溯。我在做过一次旧版本文档误覆盖、导致线上回答完全跑偏的事故之后，就再也不敢跳过这一步了。

知识基础这件事，听起来不酷，做起来也不像微调那样能发论文、能讲故事，但它恰恰是让大模型从“玩具”变成“工具”的那道门槛。跨过去的人，后面会越走越顺。