两年前，我把第一版大模型功能接进内部系统时，同事半开玩笑地问：“你这不是要起飞了？”当时我也以为，做智能助手不就是把API调通、把请求发出去、把返回值解析一下？结果第一个星期就被现实狠狠教育了一遍：同一个模型、同一批数据，有人能拿到干脆利落的答案，有人拿到的是“很有水平但完全不能用”的废话。后来带团队、做评审、帮别人排查问题，看得越多越确定一件事——大模型应用做得好不好，拼的从来不是谁会用更新奇的工具，而是谁的“知识基础”更扎实。知识基础这个词听起来很虚，但它直接决定你调用的是大模型的哪一层价值：是停留在玩具阶段，还是能当生产工具用。
这篇文章没有贴一堆论文链接，也没让你先学三个月Transformer，而是想把“知识基础到底包含什么、为什么重要、怎么补”这件事讲透。适合那些已经让大模型跑起来、却总觉得结果不稳定的人，也适合正准备进入大模型应用开发、想少走弯路的新手。
1. 为什么“知识基础”这四个字被我反复强调
1.1 同一个大模型，人与人用出来的效果天差地别
我拿带新人的场景举例。同样是让模型分析股票K线图，新手会直接把截图传上去，然后写一句“帮我看看这个走势怎么样”。老手则不一样，他会先告诉模型“你是一名有十年经验的技术分析师”，再规定“只输出趋势判断、关键支撑位、风险提示三个部分”，最后加上一句“不确定的地方写unknown，不要用模棱两可的表述”。两者最终结果的差距，堪比“让人随便猜”和“让人按流程办事”。
做CAD解析也是类似情况。如果直接把图纸交给模型，指望它自动提取尺寸和公差，得到的输出大概率不稳定。但如果先把模型的能力边界、输入格式、输出约束弄清楚，再设计一套从粗到细的提示词，效果立刻就不一样。
我见过太多人把“感觉能做”的需求直接抛给大模型，然后开始抱怨“大模型不行”。说句公道话，大多数时候不是大模型不行，而是操作者缺了一大堆前置知识。这条规律在任何技术领域都成立：工具越强大，对使用者的要求反而越高。
1.2 知识基础拆开看，其实是四个层面
我把大模型的知识基础拆成四个层面，缺哪一层都会翻车：
| 层面 | 具体内容 | 缺了会怎样 |
|---|---|---|
| 模型侧知识 | 模型能力、上下文窗口、token规则、推理参数、部署成本 | 选错模型、预算爆掉、效果一塌糊涂 |
| 应用侧知识 | 提示词工程、上下文工程、结构化输出、工具调用 | 结果不可控，根本没法落地 |
| 数据侧知识 | RAG、向量检索、微调数据、知识库构建 | 模型不知道“你的知识”，只能瞎编 |
| 工程侧知识 | API、并发、缓存、评估、失败降级 | 上线即翻车，没人敢用你的功能 |
这四个层面，完全可以在两三个月内补起来。补完之后你会发现，“我想让大模型做什么”就不再是一句模糊的愿望，而是一条有步骤、可复现、能排查的技术路径。
1.3 先把底层事实搞清楚：大模型不是无所不知
很多新人把大模型当成一个会说话的知识神灯，这是最大的误解。实际情况至少有三个：
- 训练数据有截止日期，之后发生的事情它不知道。
- 它的知识来自统计规律，而不是实时数据库，所以在专业问题上完全可能出错。
- 每次请求能处理的文本量有限，这个限制叫上下文窗口。
这三个事实，是所有大模型知识的起点。想明白它们，你就能理解为什么需要本地部署、为什么需要检索增强、为什么需要微调。所有看似高级的技术，本质上都在回答同一个问题：如何用你的知识，去补齐模型的知识盲区。
2. 模型侧知识：先把工具箱的说明书读完
2.1 选模型的三个维度：能力、成本、部署方式
很多人一上来就问“哪个大模型最强”，这其实是把问题问反了。选模型首先要问：任务是什么？预算多少？数据能不能出本地？
- 如果任务是深度推理、复杂逻辑分析，优先选推理能力强的商用API模型。
- 如果只是做文本分类、信息抽取、格式转换，一个中等参数量的开源模型往往就够用。
- 如果数据敏感、不能出内网，那只能选可本地部署的开源模型。这就是很多人折腾本地部署大模型的根本原因。
我个人的建议是：先选“够用且最便宜”的模型跑通流程，不要一上来就用最强的。原因很简单，流程没跑通时，换再强的模型也救不了你。先把API调通、把提示词和输出格式定型，再根据瓶颈决定是否要升级模型。
这里还有一个常被忽略的点：所谓“最强模型”，往往意味着更高的延迟和更贵的成本。如果任务本身并不需要那么强的推理能力，用强模型反而拖慢迭代节奏。选型不是攀比，是匹配需求。
2.2 Token与上下文窗口：被严重低估的隐形边界
Token是大模型处理文本的基本单位。一个汉字大约对应1到2个token，一篇5000字左右的文章，换算成token通常在6000到8000之间。大多数商用模型给出的上下文窗口是几万token级别，听起来很充裕，但真到用的时候就会发现不够花。
为什么不够花？因为你会习惯性地把背景资料、历史对话、用户问题、参考文档全都塞进去。塞到最后，窗口被占满，生成质量急剧下降。这里有个很多教程不会讲的知识点：模型并不是对窗口内所有内容一视同仁，它对开头和结尾的内容捕捉得更准确，中间部分容易被“淹没”。所以做上下文工程时，核心信息要放在显眼位置，无关内容要果断删掉。
我第一次做长文本问答时，把一份50页的PDF全文塞进上下文，然后问模型“帮我总结第三章节的要点”。结果模型确实回复了，但里面一半内容是从第五章“串台”过来的。后来改成先检索、再裁剪、最后只把关键段落放进去，效果立刻就正常了。这个教训我一直记到现在。
2.3 生成参数：temperature、Top-P这些东西为什么重要
调用大模型的时候，很多人盯着返回结果，却忽略了请求里的参数。temperature是最典型的一个。简单理解，它控制模型生成文本的“随机程度”：temperature越低，输出越稳定、越保守，适合分类、抽取、结构化任务；temperature越高，输出越发散、越有创意，适合写文案、头脑风暴。
Top-P和temperature一样，也是控制随机性的参数，两者可以配合使用。在实际项目里，我的经验是：做数据分析、信息抽取，直接把temperature设为0或者接近0；做创意文案，可以设到0.7到0.9；多数情况下官方默认值是一个平衡点，不要随便改。
我处理过不少“大模型输出不稳定”的求助，最后排查下来，原因就是temperature设得太高。这种情况在结构化输出场景中尤其致命。理解生成参数，是模型侧知识里最基础也最容易见效的一块，建议每个人都亲手调几组对比感受一下。
3. 应用侧知识：提示词工程与上下文工程是生产级应用的入场券
3.1 提示词工程：让模型先听懂你的“需求文档”
提示词工程是应用侧的入门知识，但入门绝不等于简单。我把提示词比作“给一个聪明但没有任何背景的实习生写任务书”。你只写一句“帮我处理一下”，他完全不知道该做什么；但你写清楚角色、任务、输出格式和注意事项，他就知道该怎么干了。
一个合格的提示词一般包含四块：
- 角色设定：你是一名资深的股票分析师，或者你是一名严谨的合同审核专员。
- 任务描述：基于我提供的K线图数据，给出趋势判断，要求逻辑完整。
- 输出要求：只输出结构化JSON，字段包括trend、support、risk，不要额外解释。
- 约束条件：如果没有足够信息判断，输出unknown，不要编造。
把这四块写清楚，效果立竿见影。有些刚入门的朋友觉得写提示词就是在“啰嗦”，其实不是——提示词是把你的领域知识显性化，让模型沿着你的思路走。你脑子里越清楚，提示词才能写得越好。
另一个容易被忽略的点是示例。给模型一两个你期望的输出示例，比写十行说明都管用。这背后是少样本学习的原理，但用起来特别简单：你只需要把“我希望看到的样子”直接贴在提示词里。
3.2 上下文工程：给模型提供恰到好处的背景知识
上下文工程和提示词工程经常被并列提起，但侧重点完全不同。提示词工程管的是“怎么下指令”，上下文工程管的是“给模型喂什么背景知识”。
典型场景是合同问答。用户问“这份合同有没有退款风险”，你不能把用户问题直接丢给模型，更不能把整本合同原文全塞进去。正确做法是：先从合同文档里检索出跟退款相关的条款，按重要程度排序，加上用户的原始问题，一起组织成一段“精简但关键信息齐全”的输入。
这里的知识基础包括：怎么切分文档、怎么检索、怎么排序、怎么压缩、怎么避免无关信息干扰。很多项目效果不好，不是模型的问题，而是上下文里的噪音太多。噪音一多，模型分不清重点，回答自然就飘了。
我自己常用的上下文组织原则只有一句话：让模型看到的内容，都是帮助它做出正确回答的关键信息。凡是跟当前问题无关的内容，一律不放。这个原则写出来很简单，但在实际项目中执行到位，需要反复练习。
3.3 结构化输出：从“自由发挥”到“限定格式”
在真实开发里，大部分场景并不是让模型写一篇小作文，而是要拿它的输出去解析、入库、展示。这时候最核心的技能就是结构化输出。
以分类任务为例，如果任务只允许固定几个类别，那么模型的输出就必须被限定在这几个类别里。有些模型支持功能调用或者结构化生成，直接从上层约束输出空间；有些不支持，那就要通过提示词明确写着“只输出以下类别之一”，并在解析层做兜底。
这里有一个知识点很值得理解：模型生成文本时，每个token都是从概率分布里采样出来的。当你把输出范围限制死，本质上就是在过滤候选token，让它只能在允许的类别里选。明白了这一点，你就知道为什么“输出限制只有这几种类型”能大幅提升稳定性——限制越死，自由发挥空间越小，幻觉概率越低。
结构化输出还有一个配套操作：把temperature调低。如果你既要求JSON格式，又把temperature调到1.5，模型输出很可能就变成“JSON加几句感叹”的混合体。格式稳定性的根基，是“限定格式+低随机性+解析兜底”三者同时到位。
4. 数据侧知识：RAG与微调，给模型“补课”的正确姿势
4.1 为什么必须掌握RAG
仅靠提示词工程，模型的知识范围终究有限。想让模型知道你的私有知识，或者让模型了解训练截止日期之后的信息，目前最主流、见效最快的方式是RAG，也就是检索增强生成。
RAG的思路说起来特别朴素：模型不知道答案时，先从外部知识库里检索相关资料，再把资料作为上下文交给模型，让它基于资料回答。这相当于给模型临时接了一个外挂知识库，完全不需要重新训练。对企业来说，这是成本最低的私有知识落地方式。
我经常对团队说一句话：RAG的本质不是技术炫技，而是“把答案带到模型嘴边”。模型就像一个知识渊博但没有你公司内部资料的外脑，你不用RAG，它就只能靠猜。你用了RAG，它至少能基于真实的文档回答。
做知识库问答、企业私有化部署、智能客服这类场景，RAG几乎是绕不开的一环。它不完美，但它是目前平衡效果、成本、更新速度三者关系的最佳方案。
4.2 RAG链路里每一个环节都可能翻车
RAG不是“检索一下再拼到提示词里”这么简单。完整链路包含文档加载、文本切块、向量化、构建索引、用户查询向量化、检索、重排、上下文拼装、模型生成。每个环节都需要对应的基础知识，任何一个环节出问题，最终效果都会打折。
我被坑得最惨的是文本切块。最开始图省事，按固定字符数切块，比如每500字切一块。结果发现，一个完整概念经常被拦腰截断，模型拿到半截信息，回答自然出错。后来改成按段落、按语义单元切块，再配合重叠窗口，效果才提上来。切块这个细节，看起来只是工程实现问题，其实本质是“粒度”问题：切太粗，检索不精准；切太细，语义不完整。
另一个容易翻车的是向量化。不同的向量模型对语义的理解能力差异非常大，Embedding模型要尽量选跟业务语言接近的。做中文领域的业务，如果直接使用通用英文向量模型，相似度检索效果会很奇怪。我见过一个团队，用英文向量模型检索中文合同，结果“甲方”和“供应商”完全匹配不上，检索准确率惨不忍睹。
判断RAG链路好不好，不要只看单个环节的准确率，要看全链路漏损。文档加载丢内容、切块切坏语义、向量化跑偏、检索排序不准、重排没生效，任何一个环节都在拉低最终效果。检验RAG系统，一定要做端到端的评测。
4.3 微调：先别急着做，动手前问三个问题
顺着热搜词往下走，第二个绕不开的知识点就是大模型微调。不少同学一学到大模型，就觉得必须微调一个自己的模型才算入门，这是个非常危险的误区。
我做微调前的自检习惯，是有三个问题必须先回答：
- 提示词加RAG能不能解决？能解决就不微调。
- 手上有没有高质量数据？不足1000条，通常不值得微调。
- 有没有评估指标？微调完怎么判断“变好了”？没有评估就等于白做。
微调的本质是修改模型内部的权重。权重一旦被改变，模型底层的通用能力可能被削弱，这就是常说的灾难性遗忘。你把模型训练成“只懂合同审核”，它可能连基本的日常对话都变笨了，这种代价需要提前想清楚。
所以在基础知识里，很重要的一条就是“知道什么时候不该微调”。知识基础扎实的人，不会看到什么就往模型里加什么，而是先想清楚：这个能力应该放在提示词里、检索库里，还是模型权重里。放的位置对了，事半功倍；放错了，怎么调都不对劲。
微调数据还有一个关键点：质量远大于数量。1000条精心标注、覆盖各种边界情况的数据，效果可能好过10000条从网上随便扒来的重复数据。数据里的噪音，模型会照单全收，错误标签直接变成错误行为。所以微调之前，先花最多时间清洗数据，而不是急着启动训练。
4.4 知识抽取：把非结构化资料变成可用知识
这里顺便聊一下知识抽取。很多人做知识库时，手里是PDF、表格、扫描件，什么格式都有。直接把这些原始格式扔进去做向量化，效果通常不好。正确做法是先做一轮清洗与知识抽取，把关键实体、关系、要点提取出来，再形成结构化条目。
用大模型做信息抽取，比传统规则方式灵活得多，但也有自己的前提。比如抽取规则要定义清楚，字段边界要明确，抽取后的结果要做人工抽检。我见过不少团队做完知识抽取就以为万事大吉，结果抽查时发现模型把财务术语理解错了，整个知识库的质量都被拉低。
这里有一个实操技巧：用大模型做知识抽取时，可以把输出设计成固定的schema，比如实体名称、实体类型、关联关系、置信度。模型只有按照schema输出，后续才能方便地入库、检索、更新。如果让模型自由发挥，抽出来的东西五花八门，后面用起来全是坑。
5. 实操路线图：把知识基础补齐其实不难
5.1 第一阶段：基本原理加第一次API调用
如果是从零开始，我建议的时间安排是三到四周走完一个完整循环。第一周先搞清楚LLM的基本工作原理。不需要你推导公式，但至少要理解“预测下一个token”这个本质，知道为什么会有幻觉、为什么有上下文限制。
然后把任务落在动手上：申请一个商用API，通读官方文档，跑通一个最简单的调用。这个过程虽然简单，但非常重要，你会亲手看到请求参数、响应结构、token计费这些最实际的东西。
有一个新手经常犯的错是“光看不练，一行API都没写过就去啃论文”。我的建议很直接：先让模型跑起来，再回头看原理。带着问题学，效率高得多。
5.2 第二阶段：练熟提示词工程和上下文工程
第二、三周，把主要精力放到提示词工程和上下文工程上。拿同一个任务做对比实验，比如分析一份合同的风险点。先用弱提示词“分析这份合同的风险”跑一遍，再用强提示词“你是一名资深法务，基于给定合同条款，按主体、金额、时间、违约责任四个维度输出风险清单，不确定时标注unknown”跑一遍。对比之后，你会对提示词的力量有非常直观的认知。
上下文工程也要同步练。找一篇长文档，设置一个复杂任务，尝试“检索加裁剪加排序”的方式组织上下文，和“整篇塞进去”的方式做效果对比。你会惊讶地发现，同样是模型，输入的组织方式不同，输出质量能差出一个量级。
5.3 第三阶段：本地部署一个小模型
想加深对模型侧知识的理解，本地部署大模型是性价比很高的一件事。用Ollama这类工具，下载一个7B级别的小模型，在自己电脑上跑起来，你才会真正体会到几个事：模型文件很大，推理需要显存，量化版本可以削减占用，显存不够时速度会慢得让人崩溃。
本地部署不是目的，是手段。部署之后，你可以观察token生成速度、响应延迟，也可以对比不同量化档位对生成质量的影响。这些一手经验，能帮你在以后做模型选型时更懂行，至少不会被各种宣传话术带偏。
我建议本地部署从最小的模型开始，比如3B到7B的参数规模。不要一上来就想跑70B的大模型，你的显卡大概率扛不住。先跑通一个小模型，把环境、工具链、推理流程摸熟，再逐步挑战更大的模型。
5.4 第四阶段：做一个完整的小项目收尾
最后一个阶段，做一个小而完整的项目，我强烈推荐“个人知识库问答机器人”。把你自己常用的文档、笔记整理成知识库，用RAG搭一个问答链路，让模型基于你的资料回答你的问题。
这个项目做完，提示词工程、上下文工程、RAG、模型选型、结构化输出会全部串起来，知识基础才算真正长在你身上。不要做得太复杂，先求通再求好，一个月时间足够从零跑通。
做完之后还可以做一件事：写一份项目复盘，记录哪里效果好、哪里效果差、改进了什么、为什么改进。这份复盘比项目本身更值钱，因为它会逼你把“感觉”变成“认知”。
6. 常见问题与排查心得分享
6.1 幻觉严重：先检查知识供给
现象是模型一本正经地编造不存在的事实，看起来很像真的，实际上全是错的。排查思路很简单：任务是否涉及私有知识或最新知识？涉及的话，大概率是上下文里没给足资料，优先补RAG。再看提示词里有没有明确要求“不知道就说不清楚”。如果还是不行，让模型先列出依据来源再下结论，这一步能逼着模型减少自由发挥。
6.2 上下文溢出：学会“断舍离”
现象是输入稍微一长，模型就报错，或者回答到一半就截断。这通常就是token超出上下文窗口了。解决方案是压缩输入：把长文档先检索一遍，只保留跟问题最相关的片段，再拼进上下文。另外要设置输出上限，别让模型一口气生成太长的内容。
想判断是不是上下文拥挤导致的，有一个很简单的办法：把相同问题配一个精简的上下文再问一次。如果这次回答质量明显提升，那就是上下文组织方式的问题，不是模型能力的问题。
6.3 本地部署又慢又卡
现象是本地部署模型后推理速度慢，甚至直接显存溢出。排查顺序是：先确认显存够不够模型大小，不够就换小模型或者更低比特数的量化版本。再看是不是同时跑了太多任务，后台进程占满了资源。最后可以切换推理引擎，vLLM这类工具能明显提升整体吞吐量。
有个容易被忽略的细节：本地部署的慢，往往不是显存不足，而是数据带宽不够。你打开任务管理器看一眼，如果显卡利用率不到一半，硬盘却一直在转，那大概率是模型被反复换入换出，俗称“溢出到了内存”。这时候只能换更小的模型。
6.4 结构化输出不稳定：把空间锁死
现象是让模型输出固定类别，结果它时不时多解释一句，或者返回完全不匹配的格式。解决办法是：在提示词里把枚举值写死，明确要求“只输出以下几个值之一”。如果API支持结构化约束，比如JSON Schema或者工具调用，直接开启，从顶层限制输出空间。再把temperature调到0或接近0，最后在解析层做容错。
这里有一个我反复踩过、终于记住的教训：不要把解析层写成“必须成功”。大模型在线生成，总有概率返回不符合预期的内容，解析层必须做好失败兜底，比如重试、默认值、告警日志。稳定性的最后一环，是靠工程兜底而不是靠模型自觉。
6.5 一张表复盘四大高频问题
| 现象 | 常见原因 | 解决思路 |
|---|---|---|
| 幻觉严重 | 知识缺失、提示词不够严 | 补RAG、加输出约束、要求给依据 |
| 上下文溢出 | 输入token太多、窗口太小 | 检索压缩、裁剪无关内容、控制输出上限 |
| 本地部署慢 | 显存不足、模型过大、推理引擎低效 | 换小模型、调低量化精度、使用vLLM |
| 结构化输出混乱 | 没约束、温度过高、解析不健壮 | 枚举限定、temperature调低、解析层加兜底 |
这张表你完全可以贴在工位上，每次项目出问题先对着它自查一遍。很多看起来神秘的问题，根源往往就是这么简单。
6.6 最后一条经验：先归因到知识层，而不是模型层
排查大模型问题时，我基本遵循一个原则：先把问题归因到“知识层”，而不是“模型层”。什么意思？输出不准，先查知识供给；效果不稳，先查提示词和参数；延迟太高，先查上下文长度和部署方式。按照这个顺序排查，90%的问题都能定位到具体环节，剩下那10%，才真正需要换模型。
我在实际项目中见过一个高频现象：团队发现模型回答不准确，第一反应永远是“换个更大的模型”。结果换完依旧不准。为什么？因为问题出在上下文里根本没有正确答案。模型再强，也不可能凭空知道你的内部业务数据。这个认知，是我认为大模型基础知识里最重要的一条。
做技术最怕的就是用行动上的勤奋掩盖思考上的懒惰。追新模型、追新框架当然重要，但那是在知识基础夯实之后的事。地基不牢的时候，追得越快，塌得越快。
