Sunqy 文档库

主题

02 模型能力增强技术 ​

速览卡 ​

项内容
一句话定位通用模型到具体业务之间的"适配层"，决定你的 AI 应用好不好用
核心内容提示词工程、RAG、微调三条路线的原理、代价与决策树
现状判断上下文工程取代提示词工程成为主流说法；RAG 是企业落地最广泛的技术；微调门槛持续下降但仍是最后手段
读完能回答我的场景该写提示词、做 RAG，还是微调？
相关板块01 基础模型 ｜ 05 工程化 ｜ 03 Agent

一、先建立一个心智模型 ​

三种技术解决的是不同层次的问题：

技术解决的问题比喻
提示词 / 上下文工程模型会做这件事，但不知道你要它怎么做给员工下工作指令
RAG模型不知道某些事实（内部资料、实时数据）给员工配一个资料库，允许随时查
微调模型不会做这类任务，或行为风格需要改变送员工去专业培训

这个区分是关键。用错层次是浪费成本的主要原因：

  • 用微调灌知识 → 昂贵、易过期、难以追溯
  • 用提示词解决能力缺失 → 反复调也没用
  • 用 RAG 解决行为规范问题 → 检索再准也管不住输出风格

二、提示词工程与上下文工程 ​

从 Prompt Engineering 到 Context Engineering ​

早期叫"提示词工程"，焦点是怎么写那句指令。

随着应用变复杂，重心转向了上下文工程（Context Engineering）：如何动态地组织模型在生成前能够看到的一切——系统指令、检索到的资料、历史对话、工具定义、输出格式约束、少样本示例。

区别的本质：

提示词工程：怎么写好一句话            （静态、单轮、技巧导向）
上下文工程：怎么装配好整个输入窗口     （动态、多轮、系统导向）

在生产系统里，后者才是真正的难点——模型能看到的上下文是被你的系统组装出来的，组装质量直接决定输出质量。

核心技巧 ​

技巧说明适用
明确角色与任务说清楚"你是谁""要做什么"通用，基础操作
结构化指令用分节、编号组织要求，而非一大段文字复杂任务
少样本示例（Few-shot）给 2～5 个输入-输出样例格式固定、风格特殊的任务
思维链（CoT）要求"先分析再给结论"推理、计算、判断类任务
输出格式约束明确要求 JSON / 表格 / 特定结构需要程序解析输出
拆解任务把复杂任务拆成多步，逐步执行复杂任务，也便于定位问题
负面约束明确说"不要做什么"减少越界输出
要求引用来源让模型标注依据出处便于核查幻觉

关键原则 ​

1. 具体胜过华丽

"你是一个专业的资深分析师"这类角色扮演的边际收益远小于"输出必须包含三个字段：结论、依据、置信度"。

2. 把隐性要求显性化

人觉得理所当然的约束，模型不知道。输出长度、语气、禁用词、边界情况处理，都要写清楚。

3. 提示词是代码，要版本化管理

提示词改动会显著改变系统行为。应当：

  • 纳入版本控制
  • 配套的回归评测
  • 改动需评审，尤其是生产环境

4. 不要迷信"提示词模板"

网上流传的模板对特定场景有效，但照搬往往水土不服。有效提示词来自对你自己失败案例的针对性修补。

上下文工程的关键约束 ​

约束说明应对
窗口有限塞不下所有资料检索筛选、摘要压缩
中段信息易丢失长输入中段利用率低关键信息放首尾
成本随长度增长输入 Token 也计费控制上下文，缓存复用
信息冲突上下文里有矛盾内容时模型行为不可预测去重、标注来源与时效
上下文污染无关信息干扰判断严格筛选，宁缺毋滥

反直觉的经验：往上下文里塞更多资料，有时会让效果变差。精准的少量信息优于粗糙的大量信息。

三、RAG（检索增强生成） ​

是什么 ​

生成答案前，先从外部知识库检索相关片段，把片段放进上下文，让模型基于这些材料回答。

用户提问
   ↓
检索（向量 / 关键词 / 混合）
   ↓
拿到相关片段
   ↓
组装进上下文
   ↓
模型基于片段生成答案（附引用）

为什么它成了企业落地最广泛的技术 ​

收益说明
知识可更新改文档即可更新知识，无需重新训练
可溯源能标注答案来自哪份文档的哪一段，便于核查
显著降幻觉有据可依，减少凭空编造
支持私有知识内部文档、制度、知识库都能用
成本可控比微调便宜得多，实施周期短
权限可控可结合文档权限做检索过滤

完整链路与关键决策 ​

环节关键决策常见坑
文档解析PDF/表格/扫描件如何提取表格、多栏排版、扫描件解析质量差，直接毁掉后续所有环节
分块（Chunking）块大小、重叠、是否按语义切切太碎丢失上下文，切太大检索不准；按标题层级切通常优于定长切
向量化（Embedding）选什么模型、维度中英混合、领域术语需要选合适的模型
存储与索引向量库选型、元数据设计忽略元数据过滤，导致权限与时效无法控制
检索向量 / 关键词 / 混合纯向量检索在专有名词、编号、精确匹配上表现差
重排（Rerank）是否加 rerank 模型这是提升准确率性价比最高的一步，常被省略
上下文组装片段排序、去重、长度控制片段顺序影响结果；重复片段浪费窗口
生成提示词、引用要求不要求引用就无法溯源
拒答机制检索不到时怎么办没有拒答机制，模型会硬编

提升效果的四个高杠杆动作 ​

1. 混合检索（Hybrid Search）

向量检索擅长语义，关键词检索（BM25）擅长精确匹配。两者结合，在专有名词、产品型号、编号、人名等场景效果提升明显。

2. 重排（Rerank）

先用召回率高的方法粗筛出 50～100 条，再用 rerank 模型精确排序取 Top 5～10。这一步通常是准确率提升最显著的改进。

3. 查询改写

用户的问法与文档的表述往往不一致。用模型把用户问题改写成更适合检索的形式（扩展同义词、拆分子问题、生成多个变体），能大幅提升召回。

4. 多路召回 + 融合

同时走多条检索路径（向量、关键词、知识图谱、SQL），再把结果融合去重。复杂度高，但对复杂问答效果显著。

RAG 的局限 ​

局限说明缓解
不解决能力问题模型不会推理，检索再多也没用该微调就微调
检索错了全盘皆输检索是上限重排、混合检索、查询改写
多跳推理弱需要跨文档多次推理的问题效果差迭代式检索、Agent 化检索
结构化数据不擅长表格、数值、统计类查询差转用 Text-to-SQL 或工具调用
无法学到"风格"行为规范不是检索能解决的提示词或微调

RAG vs 长上下文 ​

长上下文模型出现后，常见疑问："能不能直接把所有文档塞进去？"

场景更合适
文档量小（几十页以内），需要整体理解长上下文，简单直接
文档量大、需要反复查询RAG，成本与延迟都更优
需要跨大量文档精确检索RAG
需要完整把握一份长文档的论证结构长上下文
成本敏感RAG（每次只传相关片段）

现实选择：多数生产系统是混合的——RAG 负责从海量资料中筛选出相关部分，长上下文负责容纳筛选后的内容。

四、微调（Fine-tuning） ​

是什么 ​

用特定任务的数据继续训练模型，改变它的参数。

什么时候真的需要微调 ​

场景说明案例
行为规范难以用提示词描述风格、语气、判断标准很难写清楚，但有很多样例客服话术风格、特定文风
需要稳定的结构化输出输出格式极其严格，提示词约束不住特定格式的抽取、分类
领域术语与推理模式特殊通用模型在该领域表现明显不足医疗、法律、金融的专业判断
用小模型替代大模型把大模型在某任务上的能力蒸馏到小模型，降成本高频任务降本
提示词过长且固定大量固定指令占据上下文，微调后可省去，降延迟降成本高频固定任务

什么时候不要微调 ​

情况为什么替代方案
只是缺知识微调灌知识昂贵、易过期、无法溯源RAG
数据不足（少于几百条高质量样本）容易过拟合，效果不如少样本提示提示词 + Few-shot
任务还在快速变化每次变化都要重新训练提示词，快速迭代
通用模型已经够好投入产出比低直接用
需要可解释的输出依据微调后更难追溯RAG

主流方式 ​

方式成本效果适用
全参数微调最高最好领域差异极大、数据充足
LoRA / QLoRA低接近全参绝大多数场景，首选
提示微调（Prompt Tuning）极低有限简单适配
蒸馏中取决于教师模型用小模型复刻大模型能力
DPO / RLHF较高偏好对齐好需要精细控制输出偏好

微调的关键难点：数据质量 ​

微调的成败 80% 在数据，不在超参数。

要点说明
数量通常几百到几千条高质量样本就能见效，不是越多越好
质量噪声数据的伤害大于数据量的收益
一致性标注标准必须统一，矛盾的样本会让模型困惑
分布训练数据分布必须匹配线上真实分布
覆盖边界要包含边界情况与拒答样例

常见失败：花大力气调参，但训练数据里有一半是错的或标准不一致。

五、三者决策树 ​

                    你的问题是什么？
                          │
    ┌─────────────────────┼─────────────────────┐
    │                     │                     │
 缺知识              缺行为规范              缺能力
（不知道内部资料）  （格式/风格/标准）    （通用模型做不好）
    │                     │                     │
    ▼                     ▼                     ▼
   RAG              先试提示词              数据是否充足？
                    （90% 能解决）              │
                          │              ┌──────┴──────┐
                    提示词解决不了？        充足          不足
                          │              ▼              ▼
                          ▼            微调         换更强模型
                        微调                       或重新设计任务

成本与周期对比 ​

维度提示词工程RAG微调
实施周期小时～天天～周周～月
前期成本极低中（解析、索引、调优）高（数据、算力、人力）
维护成本低中（知识库维护）高（数据更新需重训）
知识更新不适用即时（改文档即可）需重新训练
可解释性低高（可标注来源）低
能力上限提升无无（补知识不补能力）有

组合才是常态 ​

真实系统通常是三者叠加：

微调     → 让模型学会这个领域的说话方式与判断标准
RAG     → 给它随时可查的最新资料
提示词   → 在具体调用时约束本次任务的输出格式

六、其他增强技术 ​

技术作用说明
量化降内存、提速度INT8/INT4，轻微能力损失，端侧部署常用
蒸馏大教小用小模型复刻大模型在特定任务的能力
投机解码提速度小模型草稿 + 大模型校验，降低延迟
缓存降成本前缀缓存（Prompt Caching）对长固定提示效果显著
Guardrails输入输出约束过滤敏感内容、校验输出格式、拦截越界请求
结构化输出约束保证格式约束解码，强制输出符合 Schema
工具调用扩展能力让模型调计算器、数据库、API，见 03 篇

七、常见误区 ​

误区事实
"RAG 能解决幻觉"显著降低但不消除。检索错、理解错、拼接错仍会出错
"微调能让模型学会我的业务知识"微调主要改变行为模式，灌知识是 RAG 的活
"提示词越长越详细越好"过长会稀释关键信息、增加成本、拖慢响应
"RAG 就是搭个向量库"难点在解析、分块、检索质量与重排，向量库只是其中一环
"微调数据越多越好"几百条高质量 > 几万条含噪声
"加了 rerank 就一定更好"绝大多数场景是，但要评估它带来的延迟成本
"一次调优，长期有效"业务数据分布会漂移，需要持续评测与迭代

八、延伸方向 ​