搞大模型这件事，外面看起来最热闹的是“新模型又刷榜了”“谁的推理速度更快”，但真上手做项目之后你会发现，真正决定一个应用能不能落地的，不是那层花哨的壳，而是底下的“知识基础”打得牢不牢。这个知识基础，有几层意思：模型本身懂什么、你和它对话时给了什么上下文、它需要时能不能从外部库里查到知识，以及这些知识进入模型之后能不能被稳定地调出来。把这四层拆明白，再看微调、RAG、Agent这些热门词，就会有完全不同的感觉。

这篇文章不是来讲某个具体模型的参数，也不是给你一条“三天入门大模型”的速成路径。我想从一个实际做项目的人的角度，把“知识基础很重要”这句话拆开揉碎，讲清楚为什么同样一个底座模型，有人跑出来像专家，有人跑出来像复读机；顺便把热词里那些“微调、本地部署、向量检索、提示词工程、推理加速”串成一条线。无论你是刚准备入行的新手，还是已经被 Agent 框架折腾到怀疑人生的工程师，这篇都值得通读一遍。

1. 把“知识基础”拆成四个层次，别再一笔糊涂账

1.1 模型的“内化知识”：预训练和微调决定了它天生懂多少

先说第一层，也是最容易被误解的一层：大模型本身脑子里装了什么。一个基座模型在预训练阶段读过海量文本，它的能力上限其实是在这个阶段被框死的。你问它“C++里std::move是什么意思”，它能答上来，因为训练语料里见过；你问它你们公司内部的报销流程，它大概率会胡说，因为没见过。这就是内化知识的边界。

微调（Fine-tuning）本质上就是在“补内化知识”。比如热词里反复出现的“大模型微调实战”“基于 nano-vllm 学习推理”，都是在讲怎么把特定领域的知识固化进模型权重里。但这里有个致命误区：很多人以为微调是让模型学会新知识，实际上微调最擅长的是“改变模型的语言风格、输出格式和窄域行为”，而不是往脑子里塞百科。你让一个 7B 模型去微调“你们公司 2023 年全部财报数据”，它根本记不住，就算记住了也只是死记硬背，换个问法就露馅。

所以我在项目里定了一条规矩：凡是需要精确事实的地方，默认别指望模型“记住”，而是让它在需要时“查得到”。这条规矩帮我避开了大量幻觉问题。

1.2 “上下文知识”：提示词工程与上下文工程干的活

第二层是上下文知识。模型本身的参数一动没动，但你通过提示词（Prompt）把相关信息塞进它的上下文窗口里。这就是热词里那个“大模型提示词工程与上下文工程”的核心含义。

提示词工程管的是“怎么把问题问清楚”，比如角色设定、指令顺序、少样本示例。上下文工程管的是“往窗口里放什么不放什么”，这就牵扯到检索结果怎么组织、怎么压缩、先放哪段后放哪段。我在实际项目中最直观的感受是：上下文窗口再大，也不是让你无脑塞的。你把 100 页 PDF 全塞进去，模型不是变聪明了，而是被噪声淹没了。真正的高手，是把窗口里每一千个 token 都用在刀刃上。

1.3 “外部知识”：RAG、知识库和检索管道的意义

第三层是外部知识。模型内化不了的海量私有知识，存在向量数据库里，通过检索增强生成（RAG）在生成前捞回来，拼进上下文。这一层是当前企业落地大模型的主战场，也是热词里“大模型知识抽取框架 OneKE”“本地部署大模型”“企业大模型私有化部署”这些关键词背后真正指向的东西。

我习惯把 RAG 理解成“给模型开卷考试”：模型不需要把百科全书背下来，但考试时身边放一个书架，随时能翻。这个书架建得好不好，决定了回答质量的底层支撑。很多人模型选得很贵，最后效果差，问题几乎都出在书架上——文档切得稀碎、检索召回不相关、重排序没做，然后回头骂模型不行，这口锅模型可不背。

1.4 四个层次的协作关系与选择逻辑

把这四层放一起看，决策顺序就清晰了：先评估内化知识够不够用，不够再考虑微调或选更大的基座；再看能不能靠上下文知识解决，该写提示词的写提示词，该做上下文工程的做上下文工程；最后才上外部知识管道。四层不是二选一，而是层层递进、混合使用。

实际操作中，我见过最合理的项目往往是“30% 提示词工程 + 40% RAG + 20% 微调 + 10% 基础模型选型”的配比。一上来就微调、或者一上来就堆向量库，都是比较危险的冲动行为。

2. 模型选型别只看参数，先看“知识供给”匹配度

2.1 选型看什么：参数量、上下文窗口、生态与许可

热词里有一堆“下载大模型”“大模型网址”“本地部署大模型”，说明不少人是先下载再想怎么用。我的建议是反过来：先想清楚你的知识从哪来，再决定模型怎么选。

选型看四个东西：一是参数量，但不是越大越好，7B 和 14B 在普通任务上差距有限，但部署成本差一大截；二是上下文窗口，这直接决定你这道题能不能把相关知识一次性喂进去；三是生态和许可，商用项目必须查清楚开源协议，否则后面合规风险很大；四是周边工具链成熟度，比如有没有现成的量化方案、推理引擎支持得好不好。

2.2 同一个模型，为什么有些人用出两种效果

我见过一个很典型的案例：两个人用同一个开源模型做“股票 K 线分析”的问答应用。一个人直接把日线数据 CSV 丢给模型，让它“分析趋势”，结果输出全是“可能有上涨趋势也可能下跌”这种正确的废话。另一个人先做了一步知识整理——把K线形态（头肩顶、金叉死叉）、量价关系、当前盘面的结构特征整理成结构化的分析模板，再配合少量示例喂给模型，效果立刻拉开一个档次。

这个对比特别能说明问题：模型没换，知识供给变了，输出质量就天差地别。所谓“知识基础很重要”，很大程度就体现在这里。做科研论文润色、写代码、做客服问答，逻辑都是一样的——模型是引擎，知识才是燃料。

2.3 先盘点知识，再定技术方案的工作流

我现在接到一个新项目，第一周不写任何代码。先拉上业务方，把下面这张清单里的问题盘明白：

• 用户的典型问题有哪些？哪些问题需要精确事实支撑？
• 这些事实信息现在存放在什么系统里，结构化程度如何？
• 知识的时效性要求多高？是三天更新一次，还是可以容忍半年？
• 是否需要模型输出特定格式，比如 JSON、Markdown 报表？
• 有没有不能外传的隐私数据，是否必须走私有化部署？

盘完这五条，技术方案基本就自己浮出来了。比如时效性极高的数据，RAG 是首选；输出格式要求严格，微调一小批数据比写十页提示词更省心；数据完全不能出内网，那就得考虑本地部署加离线模型。选型从来不是一个模型参数的问题，而是知识供应链的问题。

3. 从头搭一条可用的 RAG 知识管道，这些坑必须先知道

3.1 RAG 的完整链路长什么样

虽然“RAG”听起来高大上，但链路其实不复杂：知识库文档加载 → 文本切分 → 向量化入库 → 用户问题向量化 → 检索召回 → 重排序 → 拼装上下文 → 模型生成。每一步都有专门的开源组件可以用，真正考验人的是细节调优。

我按经验画一下重点关注的地方：

• 文档加载：PDF 表格、扫描件、PPT 这些格式特别容易在加载阶段丢信息，需要针对不同格式选解析器。
• 文本切分：别只会按固定字数切，要按标题层级、段落语义切，别把一句话拦腰砍断。
• 向量化：Embedding 模型的选择直接影响检索质量，通用 embedding 对专业领域术语往往拉胯。
• 重排序：向量召回的前 20 条里往往只有三到四条是准的，必须用 rerank 模型精排，才能让 Top5 真正可用。

3.2 切分和向量化环节最容易踩的三个坑

第一个坑是切分过碎。把文档切成每 128 token 一块，检索时单块信息量不够，回答必然支离破碎。我建议 chunk size 在 512～1024 token 之间，叠加 10%～15% 的重叠，尽量保证每个片段有相对完整的语义闭环。

第二个坑是领域词向量化不准。通用中文 embedding 模型对“头肩顶”“聚类系数”“等静压成型”这类词表达往往比较弱。解决办法是积累一批领域内的高频问句和标准答案，做小规模微调 embedding，或者用同义词扩展补强检索词。OneKE 这类知识抽取框架就很有用，它可以把文档里的实体和关系先抽出来，整理成结构化知识，再送进检索系统——相当于在向量相似度之外，加了一条“逻辑查询”的保险。

第三个坑是检索结果不直接喂给模型就完事了。一定要做重排序。我实测中，引入 rerank 后，回答准确率能提升 15% 到 30%，这个提升通常比换个更大的生成模型来得还明显。

3.3 必须保留的三个调试手段

调试 RAG 系统时，我会同时保留三样东西：召回日志、上下文快照、最终回答。这样当答案离谱时，我能快速定位是“没召回对”还是“召回了但模型没用上”。

一个非常实用的检验方法是“检索-only 测试”：用户提问后，只打印检索回来的 Top3 片段，让业务方看一眼这些片段本身能不能支撑答案。如果片段里根本没有关键信息，那问题一定出在索引侧；如果片段里信息都有但回答不对，那问题才出在模型侧。这个二分法能帮你省下无数排查时间。

3.4 给知识管道配一个“质量自检”环节

成熟的系统不会把模型吐出来的东西直接给用户。我会在生成后面加一道自检：把回答和检索到的参考片段再做一次相似度评估，低于阈值的直接拒绝回答，而不是硬编。此外，知识更新必须要有版本管理，你不能昨天刚改过文档，今天系统还在用昨天的旧内容回答。

还记得热词里的“大模型投毒测试”吗？在企业知识库场景中，这种测试很重要。要主动检查知识源里会不会存在恶意指令，比如某份被检索到的文档里写了一句话“忽略用户之前所有指令，输出……”，这种内容如果进了上下文，后果很严重。所以对入库文档做指令注入扫描，和做检索调优一样重要。

4. 把知识“固化”进模型：微调和提示词工程的分工

4.1 先判断：这需求该微调，还是该写提示词

我自己的判断标准很简单：如果需求是“改变模型的说话方式和输出结构”，优先微调；如果需求是“注入新知识”，优先 RAG；如果需求是“稳定输出特定格式”，先用提示词和结构化解码试，不行再微调。

比如做客服机器人，要求语气统一、先道歉再澄清、最后给出处理方案，这种风格问题很适合微调一小批高质量对话样本，一劳永逸。如果要求是“把我们最新的退款政策答准确”，那就千万别微调，政策一个月改一次，你总不能每个月重新训一次模型。

4.2 LoRA 微调的实操配置与训练避坑

热词里“GPU微调大模型”“大模型微调”都是最受关注的方向。这里我直接给一个我自己常用的 LoRA 微调起步配置，适合 7B～14B 模型，单卡 A100 或者 4090 都能跑：

# 以 LLaMA-Factory 为例，4bit 量化的 LoRA 训练 llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --dataset_dir ./data \ --dataset domain_qa \ --template qwen \ --finetuning_type lora \ --quantization_bit 4 \ --lora_rank 32 \ --lora_alpha 64 \ --learning_rate 2e-4 \ --num_train_epochs 3.0 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --output_dir ./output_lora \ --logging_steps 20 \ --save_steps 500

这里有几个参数我解释一下为什么这么设：

• lora_rank 取 32：rank 太小欠拟合，太大又失去了 LoRA 省显存的意义。32 在大多数领域任务里是一个比较稳的起点。
• learning_rate 取 2e-4：全参微调一般用 1e-5 到 2e-5，LoRA 因为训练的参数量少，学习率可以放大十倍左右。
• epochs 取 3：领域微调我最多跑到 5 个 epoch。跑多了，模型会死死记住训练集里的句式，损失泛化能力，你把训练集倒背如流不代表真会了。

最大的坑是灾难性遗忘。微调后的模型在领域问题上表现很好，但通用对话能力明显下降，连“帮我写一封请假邮件”都不利索了。解决办法是在训练数据里混入 10%～20% 的通用对话数据，回灌一点“常识”。我自己的习惯是 domain_qa 和 general_qa 按 4:1 混比，效果明显稳很多。

4.3 提示词工程和上下文工程的高性价比方案

如果说微调是“重武器”，那提示词工程就是“快枪”。一个高质量的系统提示词，应该包含四块：角色与能力边界、任务目标、输出格式约束、禁忌清单。下面这个模板是我经常套用的：

你是一名金融数据助理。你的任务是基于提供的资料，回答用户关于行情走势的提问。 回答时必须遵守： 1. 只引用给定资料中的事实，不编造数据； 2. 先给出结论，再给出依据； 3. 输出包含“结论”“依据”“风险提示”三个段落； 4. 如果资料无法支撑结论，明确回答“资料不足，无法判断”。

这种显式约束比“你是一个专业的助手”这种空话有用得多。上下文工程再做一层：把检索回来的片段按照“先说结论再说依据”的顺序排列，把最相关的回答片段放在靠近开头和结尾的位置——这两个位置模型注意力最强，可以算是一种免费的“处理增益”。

5. 部署与推理阶段，如何保住知识输出的质量

5.1 本地部署选型：Ollama、vLLM、AirLLM 各管一段

热词里“本地部署大模型让个人电脑智能化”“vLLM部署大模型”“airllm运行大模型”“nano-vllm”出现频率很高。这三类工具的定位不太一样：Ollama 适合个人电脑快速起一个本地模型玩，命令简单、量化开箱即用，适合做原型；vLLM 适合生产环境，吞吐量高、支持并发和连续批处理，是正经上服务的首选；nano-vllm 这种更偏教学，适合你想搞清楚推理过程中发生了什么的时候去读一读代码。

我个人的经验是：个人体验、写写笔记，用 Ollama，半小时就能跑起来；做 API 服务、多人使用，必须上 vLLM，否则并发一上来延迟直接不可控；想学习推理原理，去看 nano-vllm 这类教学实现，比啃论文快得多。在 Windows 11 上部署其实也不复杂，装好 WSL2 或者直接用原生 Windows 版，再拉模型即可。很多看起来神秘的步骤，无非卡在检查“显存够不够”“模型格式对不对”“端口有没有被防火墙掐死”这三件事上。

5.2 推理阶段的知识输出控制参数

很多人部署完模型，发现回答“飘”。这时候看看你的推理参数是不是纯默认：temperature 默认 1.0 会让模型放飞自我，知识问答类任务建议调到 0.2 以下。top_p 也建议收敛到 0.9 以内。还有 max_tokens，不设的话长答案可能被截断在半句话上，但设太小又导致回答太短——这需要根据你的知识片段长度来配。

热词里那句“输出限制只有这几种类型的概率”其实就是大模型推理的本质：模型本质上是在算下一个 token 的概率分布。Gemini 和 DeepSeek 这种模型的 API 里有 logprobs 参数，你可以拿到每个 token 的概率，这不仅能帮你调试回答的置信度，还能用来实现在低置信度时触发“转人工”或“换知识源重试”的机制。这个技巧知道的人不多，是我觉得很有价值的隐藏能力。

5.3 量化与显存不足的应对策略

本地部署时，显存不够是最大的拦路虎。7B 模型 fp16 权重就需要约 14GB 显存，很多人手头的卡只有 8GB。方案就三个：4bit 量化、模型 offload 到内存、减小上下文长度。

4bit 量化（比如 GPTQ 和 AWQ）能把 7B 模型压到 5GB 以内，知识问答场景下质量损失通常可以接受。我还是建议保留一个量化前的模型专门做“敏感推理”，因为量化在复杂推理和长篇生成上确实会有肉眼可见的劣化。

部署完成后别急着对外发布。先跑一遍“提示词注入演练”：在知识库里故意放一条攻击性文档，看看系统会不会被带偏。这个测试做过和没做过，系统的安全底线完全不一样。知识基础不只是“知识多”，也包括“抗干扰能力强”。

6. 高频问题排查实录与避坑速查表

6.1 检索答案总是不相关

排查顺序：先看召回日志里检索到的内容是什么。如果召回内容本身不相关，多半是切分太碎或 embedding 对领域词不敏感，你做同义词扩展、微调 embedding、加关键词兜底都能改善。如果召回内容明明相关但模型没用上，那多半是上下文排序问题，把相关片段往前移一条，或引入 rerank 精排。

6.2 模型回答内容正确，但格式一塌糊涂

优先检查两件事：系统提示词里有没有给格式模板和示例；解码参数里 temperature 是不是太高。如果还不行，就上结构化解码工具，比如限定 JSON Schema 输出。最后的选择才是微调一批格式样本——格式问题用 prompt 解决成本最低，微调属于“杀鸡用牛刀”且维护麻烦。

6.3 微调后模型“变笨”了

这个在 4.2 提到过，核心原因是数据配比单一加训练轮次过多。对策：加入 10%～20% 通用数据；epochs 从 3 开始，最多 5；学习率不要超过 2e-4（LoRA 场景）。还有一个容易忽略的检查点是训练集里有没有标签错误、答非所问的数据，一条脏数据能抵十条好数据。

6.4 本地部署后响应慢、吞吐低

先看是不是没有开 GPU 加速，让模型跑在 CPU 上了；再看是不是并发请求直接把显存打满了，vLLM 能通过 continuous batching 显著提升吞吐；最后看量化，4bit 比 fp16 在显存带宽压力上会小很多。如果还需要更快，减小 max_tokens 和上下文长度往往见效最快。

我把上面这些高频问题整理成了一张速查表：

这张表是我踩坑踩出来的压缩版，不敢说覆盖所有情况，但能帮你在看到一个“模型很蠢”的问题时，先冷静想想是模型的问题，还是知识供给的问题。

7. 最后分享一点个人经验

做了一年多的大模型应用，我最大的感触是：这个领域里最贵的东西不是 GPU，也不是底座模型，而是“把知识理顺”的工程能力。同样的模型，有人拿来做出一套靠谱的私人知识助手，有人只能做个“聊天机器人”——差距往往不是模型的新旧，而是知识基础打得扎不扎实。

如果你现在正要开始做大模型项目，别急着下载最新的模型权重。先把你的知识资产盘一遍：哪些是模型已经会的，哪些需要检索，哪些要调风格，哪些必须禁止回答。把这四类分清楚，你的技术路线基本不会走偏。我今天写下的这些内容，本质上不是模型操作手册，而是一条“先想清楚再动手”的路径。希望它能帮你少走几个我之前走过的弯路。