大模型与提示工程
把 LLM 使用拆成任务说明、资料接入、行为适配和工作流设计，避免把所有问题都塞给提示词。
大语言模型（LLM）不是搜索引擎，也不是一个只会聊天的窗口。它的核心能力是根据上下文生成文本、代码、表格、计划或结构化输出；聊天只是最常见的界面，不是能力边界。
本章把“怎么用好 LLM”拆成四件事：把任务说清楚、把资料接进来、把模型行为调稳定、把复杂任务变成可检查的工作流。提示词很重要，但它不是魔法咒语；如果资料缺失、评估缺位、产品边界模糊，再漂亮的提示词也只是把问题包装得更像样。
先用这张地图定位问题
| 你看到的现象 | 更可能的真实问题 | 优先阅读 |
|---|---|---|
| 回答跑偏、格式不稳、遗漏限制 | 任务说明不够清楚 | Prompt Engineering 解决什么 |
| 缺最新资料、企业文档、引用证据 | 模型上下文里没有可靠资料 | RAG 解决什么 |
| 搜索结果找不到语义相近内容 | 缺少向量表示和语义检索 | Embedding 和 Vector Database 解决什么 |
| 输出风格、字段、分类口径长期不稳 | 行为模式需要训练适配 | Fine-Tuning 解决什么 |
| 模型偏好、拒答边界、排序选择不符合预期 | 需要偏好塑形和评估 | SFT / RLHF / DPO / PPO 先怎么理解 |
| 任务要查资料、调工具、分步骤审核 | 不是单次问答，而是工作流 | 提示词、RAG、微调怎么选 |
本章怎么读
- **先读判断表。**如果你只是想知道该用提示词、RAG 还是微调，先看四类问题判断表和怎么选。
- **再补核心机制。**提示词负责任务表达，RAG 负责资料接入，Embedding / Vector Database 负责语义检索，Fine-Tuning 负责长期行为适配。
- **最后查误区。**如果有人说“微调能解决知识库”“向量库能防幻觉”“提示词越长越好”，先去看常见误解。
本章目录
四类问题判断表
用四类问题判断提示词、RAG、Embedding、微调该怎么选。
Prompt Engineering 解决什么
理解提示词工程适合解决任务表达不清的问题。
RAG 解决什么
理解 RAG 如何通过检索资料提升回答可核查性。
Embedding 和 Vector Database 解决什么
理解向量和向量数据库如何支持语义检索。
Fine-Tuning 解决什么
理解微调适合稳定格式、风格和特定任务适配。
SFT / RLHF / DPO / PPO 先怎么理解
先用偏好塑形理解 SFT、RLHF、DPO、PPO。
提示词、RAG、微调怎么选
用问题类型选择提示词、RAG 还是微调。
常见误解
拆开 RAG、微调、向量库和提示词的常见误解。
继续阅读顺序
按应用链路继续补齐大模型与提示工程词条。
关键术语地图
分清 prompt、上下文、RAG、embedding、向量数据库、微调、偏好优化和幻觉。
三个常见误判
- **把资料问题当成提示词问题。**模型不知道某份合同、政策或内部文档时，优先考虑 RAG，不是继续写“请认真阅读”。
- **把行为稳定性问题当成知识问题。**如果模型知道答案但总是格式漂移，先加输出约束、示例、校验；规模化后再考虑微调。
- **把复杂流程压成一次回答。**需要检索、计算、调用工具、人工确认的任务，应拆成步骤和检查点，而不是赌一次生成。