AI 大模型：模型只是起点，系统才是答案

一、大模型的四个工程特征

在讨论怎么用之前，先要理解它和传统软件组件的根本差异。这四点决定了后面所有工程决策。

第一，输出是概率性的。 同一个输入可能得到不同输出，且可能出错。工程上不能假设"调用即正确"，必须设计校验、重试、兜底。

第二，上下文是稀缺资源。 上下文窗口再大也有成本，且存在"中间遗忘"现象——信息塞得越多，模型对关键内容的注意力反而越分散。上下文不是越多越好，而是越准越好。

第三，成本随 token 线性增长。 每次调用都在付费，且输入输出计价不同、长短上下文价格差异巨大。成本是架构设计的一等约束，不是财务问题。

第四，能力随版本漂移。 供应商更新模型、你调整提示词，效果都可能整体位移。没有评估集，你就不知道自己是在变好还是变坏。

一句话概括：大模型是一个高能力、高方差、有成本、会漂移的组件。 围绕它的工程，本质上是在管理这四项不确定性。

二、技术栈分层：看清自己在哪一层

把大模型相关技术按层次拆开，有助于判断投入重点：

绝大多数团队的工作集中在编排层和应用层。这意味着：你不需要训练模型，但必须精通如何把模型用好。 把精力错配到"自己训一个"上，是很多团队交的第一笔学费。

三、模型选型：不是选最强，是选最合适

选型是最早也最容易做错的决策。常见错误是"一律用最强模型"，结果成本失控、延迟不可接受；或者"一律用最便宜模型"，结果效果不达标、返工无穷。

正确的做法是按任务分层，建立模型路由：

• 简单任务（分类、抽取、格式化、意图识别）：小模型足够，成本低、延迟低。
• 中等任务（摘要、改写、常规问答）：中等模型性价比最高。
• 复杂任务（多步推理、代码生成、长文档分析）：才值得上最强模型。

路由的依据是任务的失败代价和难度。一个实用的起点是：先用最强模型跑出效果上限，再逐级降级测试，找到"效果可接受的最低成本档位"。

# model-routing.yaml —— 按任务分层的路由策略
routes:
  - match: { task: intent_classify }
    model: small-fast          # 延迟敏感，任务简单
    max_tokens: 64
  - match: { task: doc_qa, context_tokens: ">8000" }
    model: mid-context         # 长上下文，中等模型
    fallback: large-reasoning  # 低置信度时升级
  - match: { task: multi_step_reasoning }
    model: large-reasoning
    budget: { max_cost_per_call_usd: 0.05 }

路由策略要可配置、可灰度、可观测——每个路由档位的调用量、成本、成功率都应被记录，否则你无法判断分层是否合理。

四、推理层：延迟、吞吐、成本的三角

如果选择自部署开源模型，推理优化就是绕不开的工程。三者的关系是：批处理提升吞吐、量化降低显存与成本、缓存降低重复计算，但都会在延迟或精度上付出代价。

几个关键手段：

• 量化：INT8/INT4 显著降低显存占用，代价是精度轻微下降，需用评估集验证是否可接受。
• 连续批处理（continuous batching）：提升 GPU 利用率，是吞吐优化的核心。
• KV Cache 与前缀缓存：对固定系统提示词、固定文档的场景收益巨大。
• 投机解码 / 小模型草稿：在延迟敏感场景下提速。

对大多数应用团队，更现实的选择是用托管 API，把推理优化交给供应商，自己专注编排层。自部署只在三种情况下值得：数据不能出域、调用量足够大摊薄成本、需要对模型做深度定制。

五、上下文工程：RAG 是主流，但不是万能

"如何让模型知道它不知道的事"，是应用层最核心的问题。主流方案有三条路：

1. 提示工程：把指令、示例、约束写进提示词。成本最低，适合任务明确、知识固定的场景。关键不是"写得长"，而是结构清晰、约束明确、示例典型。

2. RAG（检索增强生成）：把外部知识检索出来塞进上下文。适合知识量大、更新频繁、需要引用的场景。RAG 的效果上限由检索质量决定，很多 RAG 项目的失败不是生成不行，是召回不准——切分策略、嵌入模型、混合检索、重排序，每一环都要调。

3. 微调：用领域数据调整模型参数。适合风格、格式、领域术语的适配，不适合注入频繁变化的事实知识。微调的成本高、迭代慢，应当作为最后手段。

一个实用的判断顺序是：先提示工程 → 不够就上 RAG → 还不够再考虑微调。顺序颠倒会浪费大量时间。

还要提醒一点：长上下文不等于可以不做检索。把整本手册塞进去，成本高、延迟高、关键信息还容易被淹没。检索的价值在于"精准投喂"，这一点不会因为窗口变大而消失。

六、评估：没有它，一切优化都是盲人摸象

这是整篇文章最重要的一节。大模型工程和传统软件工程最大的区别，就是必须把评估当作一等公民。

评估体系要解决三个问题：

评什么：从真实场景抽样构造评估集，覆盖典型、边缘、已知失败三类。评估集要版本化，只增不减，线上失败案例持续回灌。

怎么评：能用客观判定的用客观判定（结构化字段比对、关键信息命中、格式校验）；主观质量用评分量表 + 人工抽检；大规模可用强模型做裁判，但必须定期人工校准裁判本身。

什么时候不许上线：把阈值写成发布门禁，让"效果不达标"变成流程里的硬阻断。

# gate.py —— 发布前的评估门禁（骨架）
def release_gate(candidate, baseline):
    report = evaluate(candidate, dataset="evals/qa/v7.jsonl")
    assert report.accuracy   >= 0.90, "准确率未达标"
    assert report.groundedness >= 0.95, "事实性未达标"
    assert report.p95_latency_ms <= 3000, "延迟超标"
    assert report.cost_per_call <= 0.004, "成本超标"
    if report.accuracy < baseline.accuracy - 0.01:
        raise ReleaseBlocked("相对基线回退超过 1%")
    return report

这段代码很短，但它把"感觉变好了"变成了"数据变好了"。没有门禁的团队，永远在凭感觉迭代。

七、成本：单位经济模型决定生死

大模型的成本结构有三个特点：随用量线性增长、长短上下文价差大、输出比输入贵。因此成本控制必须进入架构设计：

• 路由分层：简单任务不调用贵模型（见第三节）。
• 缓存：相同或相似请求命中语义缓存，尤其适合客服、知识问答类场景。
• 上下文裁剪：控制检索条数、对话历史长度、系统提示词体积。
• 输出约束：限制 max_tokens、要求结构化输出，减少冗长生成。
• 异步与流式：长任务异步化，交互场景用流式改善感知延迟而非真实延迟。

要持续跟踪两个指标：单任务平均成本和单任务成本分布的长尾。平均值好看但长尾失控，是很多 AI 产品规模化后亏损的原因。

八、安全与合规：不是附加项

大模型应用的安全面比传统应用更宽：

• 提示注入：用户输入或检索内容中可能藏有指令，劫持模型行为。防御手段包括输入隔离、指令与数据分离、输出校验。
• 数据泄露：上下文里可能混入敏感信息，需做脱敏与权限过滤，确保"用户只能检索到他有权限看的内容"。
• 输出合规：生成内容需要审核，尤其涉及医疗、金融、法律等强监管领域。
• 可追溯：记录输入、检索来源、模型版本、输出，便于审计与复盘。
• 内容标识：AI 生成内容按规定标识。

安全要在架构里解决，而不是靠提示词里加一句"请不要做坏事"。

九、常见陷阱

• 唯模型论：以为换更强的模型就能解决产品问题，忽视编排与评估。
• 没有评估集：无法判断改动效果，团队陷入主观争论。
• RAG 只做"能检索"：不调切分、不做重排、不测召回，效果上不去就归咎于模型。
• 上下文塞满：以为窗口大就可以全塞，成本高、效果反而差。
• 过早微调：提示工程和 RAG 都没做透就去微调，投入大、收益小、迭代慢。
• 成本后置：上线后才发现单位经济模型为负。
• 忽视提示注入：把用户输入和检索内容直接拼进提示词，留下安全漏洞。
• 不做版本管理：提示词、模型版本、检索索引没有版本，出问题无法回滚。