AI 底层逻辑 / 经典论文
AI Architecture Fitness Functions：持续架构治理
一句话:
400 行ai-foundations/papers/88-ai-architecture-fitness-functions-continuous-governance.md
AI Architecture Fitness Functions / Continuous Governance 解读
面向对象: AI Architect / Enterprise Architect / Platform PM / EvalOps Lead / RiskOps Lead / Senior BA。 核心问题: AI 架构不能只在立项和上线前评审一次。模型、数据、prompt、工具、策略、成本和用户行为都会变化, 所以架构治理必须从“会议评审”升级为持续可检查的 architecture fitness functions。 学习目标: 把质量属性、风险控制、评测门槛、runtime telemetry 和产品指标转成可自动或半自动执行的架构约束, 支持 AI 系统从 pilot 到 release 到 scale 的持续治理。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将 AI 风险管理拆成治理、映射、测量、管理活动, 支撑 fitness function 的风险闭环 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、持续改进、管理责任和控制体系 |
| OpenTelemetry | https://opentelemetry.io/docs/ | 用 trace、metrics、logs 支撑 runtime fitness functions 和 SLO 观测 |
| OpenAPI Specification | https://spec.openapis.org/oas/latest.html | 为 API/tool contract fitness checks 提供结构化契约锚点 |
| JSON Schema | https://json-schema.org/ | 为结构化输出、工具参数、事件 payload 和 contract testing 提供 schema 锚点 |
一句话:
AI Architecture Fitness Function 是一条可执行的架构约束: 它把“我们希望系统具备的质量或控制”转成可检查的测试、门禁、监控、阈值或证据查询。
1. 从一次性架构评审到持续架构治理
传统评审常见问题:
architecture review -> launch approval -> drift in production
AI 系统更容易漂移:
- 模型版本更新。
- Prompt 和 system instruction 被频繁调整。
- RAG 知识源变化。
- 检索质量随文档结构变化。
- 工具 API contract 演进。
- 用户开始把系统用于设计之外的任务。
- 成本和延迟随流量、路由、上下文长度变化。
- 安全攻击样式和 prompt injection 变化。
- 人工复核负载和 override 行为变化。
所以 AI 架构治理必须变成:
architecture intent
-> fitness function
-> CI/CD gate
-> runtime monitor
-> evidence binder
-> architecture review cadence
架构师的角色不是审批一次图, 而是定义系统应该持续满足哪些约束, 并让这些约束在交付链路和运行链路中被检查。
2. Fitness Function 的定义
一个好的 fitness function 至少包含:
| 字段 | 说明 |
|---|---|
| Intent | 想保护的质量属性、风险边界或产品目标 |
| Scope | 应用于哪个 use case、服务、组件、路径或风险等级 |
| Measurement | 用什么测试、指标、查询或人工抽样判断 |
| Threshold | 通过、警告、阻断的标准 |
| Execution point | PR、CI、release gate、runtime、daily batch、quarterly review |
| Owner | 业务、产品、架构、平台、风险或运维 owner |
| Evidence | 结果存在哪里, 如何进入 release bundle 或 audit binder |
| Exception rule | 例外如何申请、审批、过期和复查 |
示例:
| Fitness function | Execution | Threshold | Evidence |
|---|---|---|---|
| Customer-facing RAG 引用必须来自 approved source | release eval + runtime sampling | unapproved citation = hard stop | eval report、trace sample |
| 高风险 tool call 必须有 approval id | contract test + runtime policy | missing approval id = block | tool gateway logs |
| P95 latency 不超过 3 秒 | runtime SLO | 7 天滚动违反触发 architecture review | SLO dashboard |
| 模型成本不能超过每 case 0.35 USD | runtime FinOps | 超过预算 20% 触发 routing review | cost ledger |
| Prompt 变更必须关联 eval regression run | CI gate | no eval run = block merge | PR evidence |
3. Fitness Function Taxonomy for AI
3.1 Quality Fitness
| Concern | Fitness function |
|---|---|
| Groundedness | answer 必须被引用 source 支撑, unsupported claim 低于阈值 |
| Citation correctness | 引用文档和回答事实一致 |
| Task success | agent trajectory 完成目标且不违反 policy |
| Regression | 新 prompt/model/retriever 不得低于 baseline |
| Segment quality | 高风险客户群、语言、渠道、产品线单独达标 |
3.2 Safety and Risk Fitness
| Concern | Fitness function |
|---|---|
| Advice boundary | 禁止越界给个性化金融建议 |
| High-impact decision | AI 不得直接做最终拒贷、冻结、赔付等决策 |
| Human oversight | 高风险 case 必须进入 HITL queue |
| Kill switch | 关键服务必须支持按 use case、model route、tool action 熔断 |
| Incident readiness | 每个 material AI system 有 runbook、owner、rollback path |
3.3 Security Fitness
| Concern | Fitness function |
|---|---|
| Prompt injection | 红队样本通过率和攻击阻断率达到阈值 |
| Tool authorization | tool call 必须通过 policy engine 和 identity scope |
| Data exfiltration | 不允许把 restricted context 发送到未批准模型或工具 |
| Contract validation | 工具参数必须符合 JSON Schema / OpenAPI contract |
| Audit trail | high-risk action 必须有 trace id、actor、approval id、result |
3.4 Privacy and Data Fitness
| Concern | Fitness function |
|---|---|
| PII handling | prompt、trace、feedback 的 PII redaction 覆盖率达标 |
| Retention | 日志、上下文、memory 按数据分类自动过期 |
| Permission filtering | RAG 检索必须在 retrieval 前执行权限过滤 |
| Data lineage | answer citation 可追踪到 source version |
| Data minimization | context window 不得包含与任务无关的敏感字段 |
3.5 Cost and Latency Fitness
| Concern | Fitness function |
|---|---|
| Unit economics | cost per successful case 在预算内 |
| Latency | P50/P95/P99 符合用户旅程要求 |
| Routing efficiency | 简单任务使用小模型或 cache, 高复杂度任务才升级 |
| Context efficiency | 平均输入 token 不随文档增长失控 |
| Capacity | 高峰流量下不牺牲安全和 trace completeness |
3.6 Evidence and Governance Fitness
| Concern | Fitness function |
|---|---|
| Release evidence | 每次上线都有 ADR、eval report、risk signoff、rollback plan |
| Control coverage | material risk 至少映射一个 control 和一个 test |
| Trace completeness | 关键 span 覆盖率达到门槛 |
| Exception hygiene | 例外有 owner、expiry、compensating control |
| Management review | 重大系统按季度复核 residual risk 和 value realization |
4. Fitness Function Lifecycle
Concern
-> Quality attribute / risk statement
-> Fitness function spec
-> Implementation as test/gate/monitor/query
-> Evidence capture
-> Exception / remediation
-> Architecture decision update
4.1 Discovery / Design
在 discovery 期定义:
- AI use case risk tier。
- 关键 quality attributes。
- 不能违反的 policy boundary。
- 需要的人类控制点。
- 需要的 eval coverage。
- 初始 SLO 和 unit cost budget。
4.2 Build / CI
在 build 期执行:
- schema validation。
- prompt/eval regression。
- retrieval permission tests。
- red-team test suite。
- ADR link check。
- contract compatibility check。
4.3 Release Gate
上线前执行:
- golden set eval。
- segment eval。
- tool trajectory eval。
- control coverage check。
- evidence bundle completeness。
- rollback readiness。
4.4 Runtime
线上执行:
- trace completeness。
- latency/cost SLO。
- policy violation rate。
- human override rate。
- citation failure sampling。
- drift and anomaly alerts。
4.5 Quarterly Architecture Review
周期性复核:
- fitness function 是否仍然覆盖真实风险。
- 新业务使用方式是否超出原设计。
- 例外是否过期。
- 技术债是否影响质量属性。
- 平台能力是否可以抽象复用。
5. Fitness Function Catalog Template
| Field | Example |
|---|---|
| ID | AFF-RAG-001 |
| Name | Customer-facing answer must be source-grounded |
| Concern | Groundedness, auditability, customer trust |
| Applies to | Customer-facing RAG, risk tier medium/high |
| Measurement | Eval set + citation verifier + runtime sampling |
| Threshold | unsupported claim = 0 for regulated answers; citation correctness >= 95% |
| Execution point | Release gate, daily production sample |
| Owner | Product owner + Model risk + Knowledge owner |
| Evidence | Eval report, trace sample, source version report |
| Exception | Only allowed with compliance approval and human-only release mode |
| Remediation | Improve source registry, retriever, answer template, refusal rule |
6. Gate Matrix
| Gate | Required fitness functions |
|---|---|
| G0 Idea intake | business outcome, risk tier, data boundary identified |
| G1 Discovery | quality attributes and initial eval contract drafted |
| G2 Architecture review | C4 views, threat model, control map, ADRs present |
| G3 Pilot build | schema/tool contracts, telemetry hooks, eval harness ready |
| G4 Pilot launch | baseline eval pass, HITL/runbook ready, trace completeness pass |
| G5 Release | regression eval, risk signoff, rollback, evidence bundle complete |
| G6 Scale | cost/SLO stable, adoption value proven, incident response tested |
| G7 Quarterly review | drift, exceptions, residual risk, tech debt, value realization reviewed |
Gate 不应该只是人工 checklist。每个 gate 至少有一部分可以由测试、查询、dashboard 或 evidence rule 自动检查。
7. Financial Retail Case: Payment Dispute Agent
场景: AI agent 帮助运营人员处理银行卡争议, 可读取交易、政策、历史 case, 生成下一步建议和草稿, 但不能自动退款或通知客户。
7.1 Key Fitness Functions
| ID | Function | Execution | Threshold |
|---|---|---|---|
| AFF-PD-001 | Agent 不得直接执行退款 | tool policy runtime | refund tool unavailable to agent |
| AFF-PD-002 | Case recommendation 必须引用政策和交易证据 | eval + runtime sample | missing evidence < 2% |
| AFF-PD-003 | 高金额 case 必须人工复核 | workflow gate | bypass = 0 |
| AFF-PD-004 | Tool call 参数必须符合 schema | CI + runtime | invalid payload blocked |
| AFF-PD-005 | P95 case triage latency 不超过 5 秒 | runtime SLO | 7 天滚动达标 |
| AFF-PD-006 | Agent 建议被人工 override 比例持续上升触发 review | ops monitor | 2 周上升超过 30% |
| AFF-PD-007 | 每次 prompt/model/tool 变更必须跑 regression eval | CI gate | missing run blocks release |
| AFF-PD-008 | Evidence bundle 包含 ADR、eval、approval、trace sample | release gate | completeness = 100% |
7.2 Architecture Fitness Dashboard
| Panel | Signals |
|---|---|
| Quality | recommendation acceptance, evidence support, override reasons |
| Safety | blocked tool actions, HITL bypass, policy exceptions |
| Security | prompt injection attempts, unauthorized tool attempts |
| Cost / latency | cost per case, model route distribution, P95 latency |
| Operations | incident count, review backlog, failed spans |
| Evidence | release bundle completeness, exception aging |
7.3 Architecture Decisions
| ADR | Fitness function link |
|---|---|
| Use tool gateway for all case system access | AFF-PD-004, audit trail, authorization |
| Keep refund action human-only | AFF-PD-001, AFF-PD-003 |
| Require policy citation in recommendations | AFF-PD-002 |
| Use staged release from internal pilot to limited region | G4/G5/G6 gate matrix |
8. Exception Management
没有例外机制的 fitness functions 会变成僵硬流程; 没有期限和补偿控制的例外会变成治理漏洞。
Exception memo 应包含:
| Field | 内容 |
|---|---|
| Fitness function | 哪条约束未满足 |
| Business reason | 为什么需要例外 |
| Risk impact | 影响哪些 stakeholder concern |
| Compensating control | 临时控制, 如人工复核、限流、只内部使用 |
| Expiry | 过期日期 |
| Owner | 业务 owner 和风险 owner |
| Evidence | 批准记录、监控、补救计划 |
| Exit condition | 什么时候必须恢复合规 |
例外不是绕过架构治理, 而是把 tradeoff 暴露并限时管理。
9. Product and Architecture Metrics
Fitness functions 不能只服务合规, 也要服务产品价值。
| Metric | 解释 |
|---|---|
| Time-to-safe-release | 从 idea 到满足关键 fitness functions 的时间 |
| Fitness pass rate | 每个 gate 首次通过率 |
| Regression catch rate | fitness functions 在上线前发现的问题比例 |
| Production escape rate | 上线后才发现的架构/控制问题比例 |
| Exception aging | 例外平均存活时间 |
| Cost per controlled outcome | 单个合规成功业务结果的成本 |
| Control evidence completeness | 关键控制证据完整率 |
| Fitness maintenance load | 维护测试、阈值、dashboard 的成本 |
高级判断:
- 如果 pass rate 过低, 可能是质量差, 也可能是门槛不现实。
- 如果 exception 很多, 可能是治理太重, 也可能是架构未平台化。
- 如果 runtime incident 多, 说明 release gate 没覆盖真实使用方式。
- 如果 adoption 低但 fitness 全绿, 说明系统可控但未创造足够价值。
10. Common Failure Modes
| Failure mode | 表现 | 修正 |
|---|---|---|
| Checklist theater | 人工勾选很多项, 没有测试或证据 | 把关键项转成自动测试、查询或 dashboard |
| Only quality, no risk | 只看准确率, 不看工具、隐私、安全、HITL | 建立 multi-dimensional taxonomy |
| Only release, no runtime | 上线前通过, 线上漂移无人发现 | 增加 runtime telemetry 和 periodic review |
| Threshold without owner | 有阈值但无人负责修复 | 每条 function 指定 owner 和 remediation path |
| Over-gating | 低风险实验也套高风险流程 | risk-tiered gates |
| No exception expiry | 例外长期存在 | exception 必须有 expiry 和 compensating control |
11. 面试表达
30 秒版本:
我会把 AI 架构治理从一次性评审升级为 architecture fitness functions。每个关键质量属性或风险边界都要转成可检查的测试、门禁、监控或证据查询, 比如 RAG 引用正确率、tool approval id、prompt 变更回归评测、trace 完整率、cost per case。这样架构意图会持续在 CI/CD、release gate 和 production telemetry 中被验证。
2 分钟版本:
以 payment dispute agent 为例, 我会定义几个 hard fitness functions: agent 不能直接退款, 高金额 case 必须 HITL, 推荐必须引用政策和交易证据, 工具参数必须符合 contract, prompt/model/tool 变更必须跑 regression eval, release bundle 必须包含 ADR、eval、approval 和 trace sample。然后把这些检查放到 CI、release gate、runtime dashboard 和季度架构复核里。这样架构治理不靠会议记忆, 而是可执行、可审计、可持续改进。
深挖追问:
| 追问 | 回答要点 |
|---|---|
| fitness function 和测试有什么区别 | 测试是实现形式之一, fitness function 表达架构意图和质量/风险约束 |
| 如何避免治理太重 | risk tier, automated checks, exception with expiry |
| 哪些适合自动化 | schema、contract、eval regression、trace completeness、SLO、cost |
| 哪些需要人工复核 | 价值假设、风险接受、复杂安全案例、客户影响 |
| 如何证明有效 | regression catch rate、production escape rate、evidence completeness、incident reduction |
12. Practice Assignment
选一个 AI use case, 建立 12 条 fitness functions:
- 3 条质量函数。
- 2 条安全函数。
- 2 条隐私/数据函数。
- 2 条工具/行动函数。
- 2 条成本/延迟函数。
- 1 条证据完整性函数。
每条都写清:
- intent。
- measurement。
- threshold。
- execution point。
- owner。
- evidence。
- exception rule。
完成标准:
- 至少 6 条能自动或半自动执行。
- 每个 high-risk action 都有控制。
- 每个 release gate 都有证据来源。
- 至少 1 条 runtime fitness function 能触发架构复核。