方法论
AI 工程方法论
生产级 AI 工程不是“把模型接到产品里”，而是建立一套可以稳定交付、评估、监控、回滚和持续治理的工程系统。大模型应用改变了传统软件的若干基本假设：同样输入可能产生不同输出；自然语言结果难以用单个断言判断；成本和延迟随上下文、输出长度、路由策略大幅波动；知识、模型、prompt、工具和用户行为都会漂移。因此，AI 工程的中心从单点功能实现转向 eval-first、trace-first、gate
451 行AI_ENGINEERING_METHODOLOGY.md
Production AI Engineering Methodology
版本说明（2026-07-01）：本文为课程化重写版（v2）。重写前的第一人称实战版 v1（60 天闭环总结、实测成本数据、L0-L5 成熟度模型、Cost 优化 8 个杠杆、Web3 Agent 考量）已按「历史学习资产保留原则」归档于
docs/archive/AI_ENGINEERING_METHODOLOGY_V1_FIRST_PERSON.md——作品集/面试叙事素材请用 v1，系统学习用本文。
生产级 AI 工程不是“把模型接到产品里”，而是建立一套可以稳定交付、评估、监控、回滚和持续治理的工程系统。大模型应用改变了传统软件的若干基本假设：同样输入可能产生不同输出；自然语言结果难以用单个断言判断；成本和延迟随上下文、输出长度、路由策略大幅波动；知识、模型、prompt、工具和用户行为都会漂移。因此，AI 工程的中心从单点功能实现转向 eval-first、trace-first、gate-first 和 feedback-first。
本文聚焦应用层 AI 系统：LLM、RAG、agent、prompt、eval、guardrails、observability、成本、延迟、发布和运行治理。金融零售案例贯穿全文，因为该领域天然要求证据、权限、审计、人类控制和可解释的收益。
1. 工程化 AI 的问题域
LLM 应用带来的工程挑战不是“模型不够聪明”，而是质量控制对象发生了变化。
| 挑战 | 传统软件 | AI 应用 |
|---|---|---|
| 输出确定性 | 同输入通常同输出 | 同输入可能因采样、版本和上下文不同而变化 |
| 正确性判断 | 可用断言或业务规则 | 需要 rubric、样本、人工复核和统计指标 |
| 成本模型 | 主要由资源和流量决定 | token、context、工具调用、缓存命中、模型路由共同决定 |
| 延迟 | p95 相对可控 | 输出长度、检索、工具调用和重试导致长尾 |
| 漂移 | 主要是业务数据变化 | 模型、prompt、知识库、工具、政策和用户习惯都会变化 |
| 安全 | 入口校验、权限、审计 | 还要处理提示注入、过度代理、泄露、幻觉和自动化偏见 |
工程化 AI 的目标是让概率能力进入受控流程。成熟路径通常从 prototype 走向 production：
| Level | 状态 | 缺口 | 工程升级 |
|---|---|---|---|
| L0 | 单条 prompt 可演示 | 无边界、无评估 | 定义任务、输入输出和风险 |
| L1 | 小 demo 可展示 | 样本少、选择性强 | 建 golden seed 和失败样本 |
| L2 | 开始量化效果 | 手工评估、不可复现 | 建 eval runner、版本和报告 |
| L3 | 有自动化发布链 | 监控和回滚不足 | 接 tracing、gate、canary 和 rollback |
| L4 | 可在生产规模运行 | 需要持续治理 | 建 monitoring、incident、数据回流 |
| L5 | 可用于一线或客户流程 | 需要组织责任和审计证据 | 建 control pack、RACI、季度复审 |
六条总原则：
- Eval-first：还没有 eval contract 时，不扩张功能面。
- Boundary-first：先定义允许行为、禁止行为、人工确认点和停止条件。
- Trace-first：每条请求都能回放输入、检索、工具、模型、输出和用户动作。
- Version-first：prompt、model、index、policy pack、tool schema 都可版本化和回滚。
- Cost-aware：架构设计包含 routing、cache、budget、quota 和单位经济。
- Controlled launch：任何高风险能力都通过 shadow、pilot、limited release 和 monitoring gate 扩张。
2. 模型策略与路由
模型选择不是排行榜问题，而是任务、风险、成本、延迟、上下文、工具调用、数据边界和供应商治理之间的系统权衡。不要用单个 benchmark 代表业务质量；业务 golden set 才能反映真实流程。
| 维度 | 关注点 | 评估方式 |
|---|---|---|
| Domain quality | 金融术语、政策推理、摘要、表格和数值稳定性 | 本机构 golden cases、专家复核 |
| Cost | 输入、输出、缓存、工具、重试、评估成本 | 单位任务成本和月度 run-rate |
| Latency | 首 token、输出速度、检索、工具调用长尾 | p50、p95、p99、timeout 和 fallback |
| Context | 长文档、lost-in-middle、证据引用 | needle tests、citation eval |
| Tool use | schema 遵循、函数选择、错误恢复 | tool-call eval、simulated failures |
| Safety | 越权、拒答、提示注入、敏感内容 | red-team set、policy eval |
| Governance | 数据处理、日志、区域、供应商变更 | contract review、model registry |
多模型策略通常优于单模型。低风险、结构化、重复任务可以使用低成本模型；复杂推理、高风险草稿、评估 judge 或关键异常可以升级到强模型。路由层要有明确输入特征和升级规则：
request
-> classify task, risk, context size, required tools
-> choose route: cheap / main / premium / human review
-> run guardrails and eval checks
-> record trace, cost and decision
常见路由策略：
| Strategy | 适用 | 风险控制 |
|---|---|---|
| Task-based routing | 分类、摘要、检索问答、复杂分析分开 | 每类任务单独 eval |
| Risk-tier routing | 低风险自动，高风险强模型加人工复核 | risk tier 不由模型单独决定 |
| Disagreement escalation | 小模型和 judge 分歧时升级 | 记录分歧原因 |
| Confidence routing | 低置信或缺证据时降级或转人工 | confidence 必须校准 |
| Budget-aware routing | 成本超预算时降级或排队 | 不让降级绕过风险门禁 |
3. Prompt Engineering as Controlled Artifact
Prompt 不是写在代码里的临时字符串，而是影响系统行为的受控资产。它需要输入输出 schema、版本、owner、变更记录、评估报告和回滚路径。
设计流程：
define task and output schema
-> collect happy-path and edge cases
-> define prohibited behavior
-> write prompt v0
-> run small eval and inspect failures
-> revise prompt and add failed cases
-> run expanded eval against baseline
-> release through gate
Prompt 文件建议包含：
| Field | Purpose |
|---|---|
| purpose | 任务和边界 |
| owner | 负责业务和质量的人 |
| input contract | 必要上下文、可选上下文、禁止输入 |
| output schema | JSON schema、字段含义、格式约束 |
| behavior rules | 引用、未知处理、升级、拒答、语气 |
| examples | 正例、边界例、失败修复例 |
| eval set | 关联的数据集和阈值 |
| version | prompt、policy pack、tool schema 的版本 |
Structured output 是生产集成的基本要求。非结构化文本适合辅助阅读，不适合作为下游系统契约。对可写入系统的输出，应使用 function calling、tool schema、JSON schema、validator 和 retry 策略。
Prompt 变更的发布规则：
| Rule | Rationale |
|---|---|
| 每次变更走 pull request 或等价审批 | prompt 改动等同系统行为改动 |
| 必须附带 old vs new eval report | 防止靠主观感受发布 |
| 至少新增一个失败样本 | 让系统从问题中学习 |
| 高风险 prompt 必须回归全量关键样本 | 防止小改动破坏边界 |
| 生产发布先 canary | 观察 real trace、成本和用户覆盖 |
4. RAG, Long Context, Fine-Tuning 与工具
知识策略不是单选题。生产系统经常混用 prompt、RAG、long context、fine-tuning、规则和工具。
| 方法 | 改变的对象 | 优势 | 局限 |
|---|---|---|---|
| Prompt | 指令和上下文组织 | 快、便宜、可迭代 | 不适合大量变化知识 |
| RAG | 检索并注入证据 | 知识可更新、可引用、可权限控制 | 检索质量和来源治理复杂 |
| Long context | 直接提供大范围上下文 | 简化检索，适合少量稳定长文档 | 成本、延迟、lost-in-middle |
| Fine-tuning | 模型行为或风格 | 可改善格式、术语、分类稳定性 | 不适合频繁变化知识 |
| Deterministic tools | 计算、查数、写系统 | 准确、可审计 | 需要集成、权限和失败处理 |
| Rules / policy engine | 明确边界和审批 | 稳定、可解释 | 不处理开放式语言 |
决策逻辑：
需要最新或授权知识 -> RAG
单文档、稳定、高频复用 -> long context with caching
输出格式或风格长期稳定且样本充足 -> fine-tuning
数值、实时数据、系统写入 -> tool
高风险政策边界 -> rules / policy engine
复杂多步任务 -> workflow or bounded agent
金融研究、信贷材料、监管文本和客服知识库通常不是“RAG 或微调”的问题，而是：
policy and product facts -> RAG with metadata and citation
calculations -> deterministic tool
customer-specific data -> permissioned API
memo style -> prompt or fine-tuning
high-risk decision boundary -> policy engine and human review
5. RAG 架构层级
RAG 的质量差异主要来自 chunk、retrieval、rerank、metadata、citation、权限和评估，而不是向量数据库品牌。
| Level | Pattern | 适用 | 关键指标 |
|---|---|---|---|
| L1 Naive RAG | chunk -> embed -> top-k -> answer | 小规模原型 | retrieval recall、answer accuracy |
| L2 Hybrid + rerank | BM25 + dense + reranker | 企业文档问答默认起点 | Recall@k、citation support |
| L3 Structured RAG | metadata、section、proposition、summary 多粒度 | 长文档、政策、合同 | source authority、version correctness |
| L4 Agentic retrieval | 多轮检索、反思和补证 | multi-hop、复杂比较 | tool steps、evidence completeness |
| L5 Graph-assisted RAG | 实体关系图 + 检索 | 关系密集知识 | relationship correctness、graph coverage |
RAG 的生产控制点：
| Control | Why it matters |
|---|---|
| Source registry | 确定来源 owner、版本、生效日期和权限 |
| Retrieval-time ACL | 防止通过摘要泄露无权内容 |
| Metadata filter | 按产品、地区、渠道、客户类型、日期筛选 |
| Citation verifier | 检查引用是否真正支持结论 |
| No-answer behavior | 缺证据时拒绝确认，避免幻觉 |
| Freshness monitor | 政策更新后触发 re-index 和回归 |
| Retrieval eval | 不只评估回答，也评估是否找到了正确证据 |
6. Agent 设计模式
Agent 的价值不是让模型自由行动，而是让模型在受限任务中协调工具、上下文和步骤。金融零售场景更偏向 bounded agent 和 workflow orchestration，而不是开放式自主代理。
| Pattern | 特征 | 适用 | 风险 |
|---|---|---|---|
| Workflow | 步骤和分支由代码控制，模型做局部判断 | 稳定流程、低风险分类、文档抽取 | 灵活性有限 |
| Single agent with tools | 模型在循环中选择工具 | 工具少、任务边界清楚 | 选错工具、上下文膨胀 |
| Plan-and-execute | 先计划再执行 | 多步骤研究、复杂摘要 | 计划错误会放大 |
| Supervisor + specialists | 一个协调器调用专项能力 | 多领域处理、分工清楚 | 协调和责任复杂 |
| Human-in-the-loop agent | 高风险动作前人工确认 | 支付、账户、信贷、投诉 | 复核负担和延迟 |
Agent 不该拥有的能力：
| Forbidden by default | Reason |
|---|---|
| 无限制读取企业知识库 | 权限和记录风险 |
| 自动发送客户承诺 | 客户权益和合规风险 |
| 直接执行不可逆金融动作 | 财务和审计风险 |
| 自行扩大工具权限 | 最小权限原则被破坏 |
| 隐藏推理和工具 trace | 无法审计和复盘 |
Agent tool contract 至少包含：
tool purpose
input schema
permission requirement
risk tier
approval requirement
idempotency behavior
rollback behavior
logging fields
failure mode
rate limit
7. Eval 体系：四层防线
AI 质量保障由多层 eval 构成。单一 benchmark、单一人工试用或单一 judge 都不足以支撑生产发布。
| Layer | 目标 | 例子 |
|---|---|---|
| L1 Deterministic tests | 保证结构、权限、规则、工具边界 | schema、citation exists、forbidden phrase、tool allowlist |
| L2 Model behavior eval | 评估开放式输出质量 | groundedness、completeness、tone、policy compliance |
| L3 Scenario and red-team eval | 覆盖边界、攻击和高风险 | prompt injection、missing evidence、policy conflict |
| L4 Production monitoring | 观察真实流程中的质量和漂移 | override、complaint、QA defect、latency、cost |
Eval dataset 需要分层：
| Dataset | Purpose |
|---|---|
| smoke | 每次变更快速检查核心边界 |
| golden | 稳定高价值样本，比较版本 |
| regression | 历史失败和事故回归 |
| red-team | 攻击、绕过、泄露、越权 |
| production sample | 真实 trace 抽样 |
| expert set | 高风险场景人工复核 |
Eval report 应包含：
| Section | Content |
|---|---|
| decision requested | 该报告支持 experiment、pilot、release、scale 还是 rollback |
| dataset | 样本来源、版本、切片、覆盖和限制 |
| evaluator | deterministic、judge、专家、生产抽样 |
| results | 总体、切片、关键阈值和置信说明 |
| failures | critical/high/medium/low 分类、根因和 owner |
| comparison | 与 baseline 或上版本对比 |
| decision | go、limited go、no-go、rollback、exception |
8. Cost Engineering
AI 成本不是只看模型 API 单价。生产成本包括模型、检索、rerank、工具、缓存、评估、人工复核、支持、日志、存储和事故成本。
| Cost lever | 机制 | 注意事项 |
|---|---|---|
| Model routing | 简单任务走低成本模型，高风险或复杂任务升级 | 路由本身要被 eval |
| Prompt compression | 减少无效上下文和重复指令 | 不得删掉关键政策边界 |
| Retrieval precision | 少召回无关 chunk | 不能为了省 token 牺牲证据完整性 |
| Prompt cache | 稳定系统提示、政策包和长文档复用 | 需要版本和失效策略 |
| Semantic cache | 高频相似问题复用答案或中间结果 | 高风险和个性化场景谨慎 |
| Batch and async | 非实时任务批处理 | 不适合客户实时流程 |
| Output budget | 限制冗长回答 | 不能截断必要证据 |
| Eval sampling | 全量 smoke + 分层抽样 deep eval | 高风险样本不能随意抽少 |
单位经济公式：
net value per task =
gross benefit
- model and platform cost
- retrieval and tool cost
- human review and QA cost
- support and training cost
- rework and incident adjustment
9. Latency and Reliability
AI 延迟要按工作流预算设计。客服实时建议、支付异常处理、信贷后台 memo、监管文本分析对延迟的容忍完全不同。
| Technique | Use |
|---|---|
| Streaming | 改善用户感知，但不减少最终完成时间 |
| Parallel retrieval | 同时跑 lexical、vector、metadata search |
| Rerank budget | 控制候选数量和 rerank 成本 |
| Tool timeout | 避免 agent 卡死 |
| Progressive disclosure | 先给可用摘要，再补证据 |
| Fallback route | 模型或工具失败时退回低风险路径 |
| Async processing | 长文档、批量分析、非实时任务 |
| Circuit breaker | 质量或成本异常时停止或降级 |
可靠性指标：
| Metric | Why |
|---|---|
| p95 / p99 end-to-end latency | 真实用户体验 |
| timeout rate | 工具、模型和检索稳定性 |
| fallback rate | 主路径健康度 |
| retry rate | 输出格式、工具失败和网络问题 |
| partial completion rate | agent 中途失败情况 |
| user abandonment | 延迟是否破坏流程 |
10. Safety and Guardrails
Guardrails 不是一个库，而是一组分层控制。
| Layer | Controls |
|---|---|
| Input | prompt injection detection、PII classification、intent risk、entitlement check |
| Context | source authority、retrieval ACL、metadata filter、policy pack version |
| Runtime | tool allowlist、approval gate、rate limit、budget、self-check |
| Output | citation verification、forbidden commitment、PII redaction、policy classifier |
| Human | review trigger、override reason、escalation、training |
| Monitoring | unsafe output sampling、complaint linkage、incident response |
常见误区：
| Misconception | Reality |
|---|---|
| “加了系统提示就安全” | prompt 是一层控制，不是安全边界 |
| “RAG 能消除幻觉” | 检索错、引用错、版本错仍会造成幻觉 |
| “人工复核一定降低风险” | 需要 criteria、抽样、日志和复核能力 |
| “低风险内部工具不用治理” | 内部输出可能影响客户、控制和数据泄露 |
| “拒答越多越安全” | 过度拒答会破坏流程并诱导 shadow use |
11. Observability and Operations
没有 tracing，就无法调试 AI 系统。每条生产 trace 应覆盖：
| Trace element | Examples |
|---|---|
| request context | workflow、stage、role、case type、risk tier |
| prompt and versions | system prompt、policy pack、model id、tool schema |
| retrieval | query、filters、sources、scores、citations |
| model call | latency、tokens、route、cost、finish reason |
| tool calls | input、output、permission、approval、errors |
| output checks | schema、citation、policy、safety |
| user action | accept、edit、reject、override、escalate |
| outcome | case closed、QA result、complaint、rework |
LLMOps 工具栈通常包含：
| Capability | Examples |
|---|---|
| Prompt management | registry、frontmatter、approval workflow |
| Eval runner | deterministic checks、judge、expert sample、reports |
| Tracing | OpenTelemetry-compatible traces、session drilldown |
| Retrieval ops | index build、freshness、source inventory |
| Model gateway | routing、quota、provider abstraction、audit |
| Guardrails | input/output filters、policy checks |
| Cost dashboard | unit cost、budget、chargeback |
| Incident workflow | severity、triage、rollback、postmortem |
12. Web3 and On-Chain Agent Considerations
链上数据的优势是公开、可验证、时间序列完整；风险是资金动作、合约交互、私钥、合规和提示注入的叠加复杂度。
| Area | Engineering implication |
|---|---|
| On-chain data | 数字必须可追踪到 tx hash、block number、contract address |
| Wallet authority | agent 不应持有无限权限；使用 session key、smart account、限额 |
| Tool action | swap、bridge、sign、approve 都需要 explicit approval 和 simulation |
| Cost | token cost + gas + RPC/indexer cost |
| Latency | LLM latency + RPC + indexer lag + chain finality |
| Safety | prompt injection 可能诱导恶意交易或授权 |
| Compliance | 投资建议、资产管理、KYC/AML 和地区限制需要边界 |
Web3 agent 的 eval 应额外覆盖：
| Dimension | Eval |
|---|---|
| Faithfulness | 数字和状态是否引用链上证据 |
| Transaction safety | 是否识别恶意合约、异常 allowance、滑点和高 gas |
| Permission | 是否遵守 session scope、限额和到期时间 |
| Economic risk | 是否解释价格、流动性、MEV、桥风险 |
| Regulatory boundary | 是否避免个性化投资建议或受限地区行为 |
13. Team and Delivery System
AI 产品需要跨角色协作，但核心不是角色名称，而是责任界面。
| Responsibility | Main work |
|---|---|
| Product and workflow ownership | 定义业务问题、目标行为、采用证据和价值假设 |
| Domain expertise | 提供政策、边界、样本、错误代价和复核标准 |
| AI engineering | 构建 RAG、agent、model gateway、tool integration |
| EvalOps | 维护数据集、rubric、judge、报告和门禁 |
| Platform and operations | tracing、monitoring、cost、security、deployment |
| Risk and compliance | 控制、人工监督、incident、审计证据 |
| Data engineering | source inventory、权限、管道、质量和 lineage |
交付节奏：
| Stage | Evidence |
|---|---|
| Discovery | workflow、baseline、risk tier、AI fit、data source |
| Prototype | small golden set、trace sample、main failure modes |
| Hardening | expanded eval、guardrails、observability、cost model |
| Pilot | limited cohort、monitoring、support、stop rule |
| Release | eval report、runbook、rollback、RACI、training |
| Scale | adoption proof、unit economics、risk trend、platform reuse |
14. Open Engineering Questions
一些问题仍需要持续观察，不应在架构中过早假设已经被行业解决：
| Question | Current engineering stance |
|---|---|
| Agent complexity scaling | 工具越多、规划越深、协作越复杂，错误和成本会放大；优先 bounded workflow。 |
| Multi-agent coordination | 协议、共享记忆、失败隔离和责任归属尚未稳定；用明确 orchestration 和日志。 |
| Safety verification | 无法证明绝对安全；使用 layered defense、red-team、monitoring 和 incident response。 |
| Model price curve | 推理价格会变化；架构要支持 provider swap、routing 和预算控制。 |
| Regulation | 不同地区和业务线要求不同；保留 trace、解释、人类监督和禁用路径。 |
15. Operating Principle
生产级 AI 工程的能力差距，不在于是否会写 prompt，而在于是否能把模型行为变成可评估、可观测、可控制、可回滚和可持续改进的系统。
Build the feature only after the eval is clear.
Ship the model only after the gate is explicit.
Scale the capability only after value, risk and adoption are evidenced.