Appearance
第9章:AI工程——会调用模型不是会做AI产品
9.1 明确哪些任务真正需要大模型?
做 AI 产品的首要原则:如果代码规则与传统确定性算法能高效精准解决的问题,坚决优先写传统代码!
mermaid
graph TD
Problem["遇到一个具体的业务问题"] --> Check1{"能否用确定性代码/正则/规则引擎解决?"}
Check1 -- "能" --> Code["使用传统代码解决: 稳定/零成本/毫秒级/100%确定"]
Check1 -- "不能" --> Check2{"是否具备现成的成熟专用算法引擎?"}
Check2 -- "具备专用引擎" --> Engine["使用专业专用算法引擎计算"]
Check2 -- "需要语义理解与解释" --> LLM["交由大语言模型处理"]业务划分正反例:
- 反面教训:把“用户会员是否已到期”、“棋谱走法是否合法合规”、“表单必填项校验”直接打包 Prompt 丢给大模型推断 $\rightarrow$ 不仅慢、昂贵,而且随时会产生不可控幻觉!
- 正面典范:
- 在棋类教学产品中:“盘面最佳着法与胜率评分” 由确定性的 Stockfish / 象眼引擎计算;
- “向学员通俗解释为什么这一步是软手、对手的潜在进攻杀着是什么”,才由大模型结合引擎评分展开拟人化讲解。
9.2 结构化输出(Structured Outputs)与受控工具调用
在商业软件中,大模型生成的自由文本几乎无法被后续程序安全消费。必须强制使用 JSON Schema 模式约束模型输出:
json
{
"weakness_type": "中盘防守不严密",
"evidence_moves": ["第18回合 炮八平五", "第22回合 车一进三"],
"difficulty": "medium",
"recommended_exercises": [1024, 1089],
"confidence_note": "基于近5场同类布局残局数据推导"
}工具调用(Function / Tool Calling)安全准则:
- 大模型仅具备“建议意图”,绝不能把实际数据库或 API 的最终控制权交给它;
- 当模型返回
call: query_user_orders(user_id=88)时,后端服务必须在服务端再次强校验当前用户是否有权查询 ID 为 88 的订单!
9.3 RAG(检索增强生成)什么时候真正有用?
RAG 适合用于基于受控私有知识库(如:专有行业训练教材、企业内部业务文档、产品售后客服知识库)进行事实溯源:
- 核心难点绝不在于“怎么把文本向量化存入向量数据库”;
- 核心难点在于:
- 文档切分策略(Chunking):是否破坏了完整语义段落上下文;
- 检索召回质量与重排(Rerank);
- 事实溯源与引用标注(Citation);
- 知识库检索为空时的优雅拒答。
- 极简建议:如果你的私有知识库内容很少(只有几十页),普通全文搜索(PostgreSQL 全文检索或 BM25)甚至在 Prompt 中直接拼接全部结构化文本,远比引入复杂的向量数据库更可靠!
9.4 评测工程(Evaluation):测试工程师的绝对优势
独立开发者做 AI 产品,最大的竞争壁垒往往不在于写 Prompt,而在于基于专业测试背景建立的自动化评测集(Eval Benchmark)!
mermaid
graph LR
Dataset["评测数据集: 100个精选代表性用例"] --> Run["自动化批量推理"]
Run --> Check1["确定性规则检查: JSON格式/必填项/引用来源"]
Run --> Check2["大模型裁判+人工抽检: 事实性/解答质量/毒性"]
Check1 --> Report["生成版本质量得分看板与回归拦截"]
Check2 --> Report评测样本集覆盖维度:
- 包含正常合规用例、典型初学者失误案例、复杂边缘案例、恶意越狱输入、空白异常输入;
- 每个样本定义明确的量化标准:格式合规率、引用命中率、事实错误率、端到端耗时、Token 成本。
- Prompt 调优与模型升级原则:任何一次 Prompt 调整或模型基座切换,必须跑通全量评测集,用数据证明质量提升,坚决杜绝“人工随手试了两条感觉还可以”的业余做法。
9.5 实战任务:AI 智能讲解接口与回归门禁实操
- 实现一个 AI 分析讲解接口,要求严格按照 JSON Schema 格式输出;
- 构建一份不少于 50 例的高质量评测数据集;
- 输出一份评测分析报告:包含正确率、典型失败类型分布、平均 Token 成本、P95 响应时延与人工抽检复核记录。