工程化、评估与场景设计
一、工程化与最佳实践
Q1: 从零构建一个AI应用的完整流程
┌──────────────────────────────────────────────────────────────┐
│ AI应用工程化完整流程 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: 需求与设计（1-2周） │
│ ├── 明确业务场景与目标指标 │
│ │ · 我们要解决什么问题？ │
│ │ · 成功的衡量标准是什么？（准确率/满意度/成本） │
│ │ · 人工处理的基线水平是多少？ │
│ │ │
│ ├── 评估技术可行性 │
│ │ · 纯Prompt工程能否解决？ │
│ │ · 是否需要RAG？需要哪些知识库？ │
│ │ · 是否需要Agent/工具调用？ │
│ │ · 是否需要微调？（通常不需要，除非有严格格式/风格要求） │
│ │ │
│ └── 技术选型决策 │
│ │
│ Phase 2: MVP与快速验证（2-4周） │
│ ├── 构建最小可用原型 │
│ ├── 准备100条测试用例 │
│ ├── 收集反馈，识别痛点 │
│ └── 判断是否需要深入优化 │
│ │
│ Phase 3: 系统优化（2-4周） │
│ ├── Prompt优化（迭代至少3-5轮） │
│ ├── RAG优化（切分策略、混合检索、重排序） │
│ ├── 知识库完善（数据清洗、结构化） │
│ ├── 缓存与性能优化 │
│ └── 边界case处理 │
│ │
│ Phase 4: 生产部署（1-2周） │
│ ├── 部署与监控配置 │
│ ├── A/B测试框架 │
│ ├── 告警与降级方案设计 │
│ ├── 灰度上线（1% → 10% → 50% → 100%） │
│ └── 成本预算与控制 │
│ │
│ Phase 5: 持续迭代（持续进行） │
│ ├── 用户反馈收集与分析 │
│ ├── 失败案例归因 │
│ ├── 知识库更新与维护 │
│ ├── 定期重训/更新Prompt │
│ └── 指标监控与ROI分析 │
│ │
└──────────────────────────────────────────────────────────────┘Q2: AI系统的架构设计（RAG应用为例）
┌──────────────────────────────────────────────────────────────┐
│ 生产级RAG系统架构 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 接入层 │ │
│ │ · REST API / WebSocket │ │
│ │ · 认证鉴权（API Key / JWT） │ │
│ │ · 限流与配额管理（防止滥用） │ │
│ │ · 负载均衡（多实例部署） │ │
│ └────────────┬──────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 业务逻辑层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 查询改写 │→│ 混合检索 │→│ 答案生成 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ · Prompt模板管理 │ │
│ │ · 工具调用编排（Agent模式） │ │
│ │ · 答案后处理（格式、引用、敏感词过滤） │ │
│ └────────────┬──────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 数据层 │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │ │
│ │ │ 向量数据库 │ │ 关键词索引 │ │ 知识库文档 │ │ │
│ │ │ (Milvus等) │ │ (Elasticsearch) │ (S3/OSS) │ │ │
│ │ └──────────────┘ └──────────────┘ └────────────┘ │ │
│ │ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Embedding │ │ LLM推理服务 │ │ │
│ │ │ 服务 │ │ (vLLM/OpenAI)│ │ │
│ │ └──────────────┘ └──────────────┘ │ │
│ └────────────┬──────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 监控与日志层 │ │
│ │ · 请求日志（脱敏后存储） │ │
│ │ · 性能指标（延迟/Token消耗/成本） │ │
│ │ · 质量指标（满意度/准确率/引用率） │ │
│ │ · 告警（异常检测、成本突增） │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘二、AI系统评估方法
Q3: 如何评估一个RAG系统的质量？
评估维度与方法：
┌────────────────────────────────────────────────────────────┐
│ 1. 检索质量评估 │
├────────────────────────────────────────────────────────────┤
│ Precision@K (P@K) │
│ 含义：检索到的Top-K文档中有多少是相关的 │
│ 公式：相关文档数 / K │
│ 目标：P@5 > 0.8（80%的检索结果是相关的） │
│ │
│ Recall@K (R@K) │
│ 含义：所有相关文档中有多少被检索到了Top-K │
│ 公式：检索到的相关文档数 / 总相关文档数 │
│ 目标：R@5 > 0.9 │
│ │
│ NDCG@K │
│ 含义：考虑排序位置的加权评分（排在前面的相关性更重要） │
│ 目标：NDCG@5 > 0.85 │
│ │
│ 人工评估（黄金标准） │
│ 抽样100+真实查询，由人工标注每个返回文档的相关性 │
│ 评分：0分（完全不相关）→ 1分（部分相关）→ 2分（高度相关）│
│ │
└────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ 2. 回答质量评估 │
├────────────────────────────────────────────────────────────┤
│ Faithfulness（忠实度/事实正确性） │
│ · 答案中的每个陈述是否都能在检索到的文档中找到依据 │
│ · 可以用LLM-as-a-Judge自动评测（让更强的模型打分） │
│ · 目标：> 90% │
│ │
│ Answer Relevance（回答相关性） │
│ · 答案是否直接回答了用户的问题 │
│ · 避免答非所问、回避问题 │
│ · 可以用LLM自动评分（1-5分） │
│ │
│ 引用覆盖率（Source Coverage） │
│ · 答案中引用了多少检索到的文档 │
│ · 避免模型用自己的"知识"回答而不是用文档 │
│ │
│ 人工满意度 │
│ · 用户点赞/点踩（👍/👎） │
│ · 收集"不满意"的案例，做归因分析 │
│ · 目标：满意度 > 80% │
│ │
└────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ 3. 性能与成本评估 │
├────────────────────────────────────────────────────────────┤
│ 延迟指标 │
│ · P50 / P95 / P99 响应时间 │
│ · 首token延迟（Streaming模式） │
│ · 目标：P99 < 5秒（简单查询）/ < 15秒（复杂查询） │
│ │
│ Token成本 │
│ · 平均每次调用消耗多少Token？ │
│ · Token消耗与回答质量的平衡 │
│ · 监控：每日/每周Token消耗趋势 │
│ │
│ 吞吐量 │
│ · QPS（每秒查询数） │
│ · 并发处理能力 │
│ · 系统饱和度 │
│ │
└────────────────────────────────────────────────────────────┘Q4: LLM-as-a-Judge（用大模型评测大模型）
用更强的LLM（如GPT-4）自动评测答案质量
评测Prompt示例：
"你是一个严格的评审员，请基于以下标准评估AI助手的回答：
标准1: 正确性（0-5分）
- 答案是否准确，有没有事实错误？
- 关键信息是否完整？
标准2: 相关性（0-5分）
- 是否直接回答了用户的问题？
- 有没有答非所问？
标准3: 引用可信度（0-5分）
- 答案是否基于提供的参考文档？
- 是否有幻觉（编造文档中没有的信息）？
标准4: 表达清晰度（0-5分）
- 语言是否流畅、逻辑是否清晰？
- 格式是否易读？
用户问题: {query}
参考文档: {context}
AI回答: {answer}
请输出JSON格式：
{
"correctness": <0-5>,
"relevance": <0-5>,
"faithfulness": <0-5>,
"clarity": <0-5>,
"total_score": <总分>,
"issues": ["问题1", "问题2", ...]
}"Q5: 构建评测数据集的方法
黄金评测集构建方法：
Step 1: 收集真实用户查询
· 从产品日志中筛选有代表性的100-300条查询
· 按问题类型分类（事实类/操作类/对比类/开放类）
· 补充边界case（超长、模糊、多语言、敏感词）
Step 2: 准备标准答案/参考文档
· 每个问题标注"黄金文档"（应该检索到哪些文档）
· 编写高质量参考答案
· 由2人独立标注，不一致时讨论解决
Step 3: 自动化评测脚本
· 每次代码更新后，自动跑完整评测集
· 对比基线版本，确保没有退化（Regression Test）
· 记录关键指标变化趋势
Step 4: 持续维护
· 每月补充新的失败案例到评测集
· 定期更新答案标准（随着产品需求变化）
· 淘汰过时案例
提示：评测集规模
· 初期：50-100条（快速验证）
· 中期：200-500条（较为稳定地衡量质量）
· 成熟期：1000+条（稳定监控，支持A/B测试统计显著）三、场景设计题（System Design）
Q6: 设计一个企业级智能客服系统
需求场景：
- 大型企业，客服部门500人，日均咨询10万次
- 咨询内容：产品使用、账户问题、售后服务、技术支持等
- 知识库：现有2万+篇帮助文档，每年新增约3000篇
- 目标：AI客服能解决60%常见问题，复杂问题转人工
设计方案：
┌──────────────────────────────────────────────────────────────┐
│ 企业级智能客服系统设计 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. 整体架构（5层） │
│ │
│ 用户层 → 接入层 → 路由层 → 处理层 → 资源层 │
│ │
│ 用户层 │
│ ├── Web聊天组件 │
│ ├── App SDK │
│ ├── 工单系统（人工介入时自动创建工单） │
│ └── 反馈收集（👍/👎 + 文本反馈） │
│ │
│ 接入层 │
│ ├── API Gateway（鉴权/限流/日志） │
│ ├── 会话管理（Context存储、历史记录） │
│ └── 负载均衡 + 多可用区部署 │
│ │
│ 路由层（关键，决定"能否回答"的第一道关卡） │
│ ├── 意图识别（Intent Classification） │
│ │ ├── 产品咨询类 → RAG问答 │
│ │ ├── 账户问题类 → 工单系统API + RAG │
│ │ ├── 技术支持类 → 知识库搜索 + Code Interpreter │
│ │ ├── 投诉/建议类 → 情感分析 + 转人工优先 │
│ │ └── 闲聊/寒暄类 → 轻量回答（不经过RAG，节省成本） │
│ │ │
│ └── 复杂度判断 │
│ ├── 简单问题：直接回答（<2轮对话） │
│ ├── 复杂问题：多轮澄清 + 搜索 + 总结 │
│ └── 不确定问题：给出参考+引导转人工 │
│ │
│ 处理层（核心） │
│ ├── RAG问答引擎 │
│ │ · 多知识库检索（帮助文档/FAQ/工单历史/产品文档） │
│ │ · 混合检索（向量 + 关键词 + 标签过滤） │
│ │ · 答案融合 + 引用标注 │
│ │ └── Prompt工程（不同场景不同模板） │
│ │ │
│ ├── 对话管理（Agent模式） │
│ │ · 对话状态追踪 │
│ │ · 槽位填充（收集必要信息：订单号、产品型号） │
│ │ · 澄清反问（问题不明确时反问用户） │
│ │ └── 多轮上下文理解（避免重复问题） │
│ │ │
│ └── 工具调用 │
│ ├── 查询订单状态（订单系统API） │
│ ├── 创建工单（客服工单系统） │
│ ├── 推送产品文档（文档系统） │
│ └── 敏感信息验证（如修改手机号需要二次验证） │
│ │
│ 资源层 │
│ ├── 向量数据库：Milvus（存储文档向量） │
│ ├── 传统数据库：PostgreSQL/MongoDB（用户信息/会话日志） │
│ ├── 缓存：Redis（Embedding缓存/热门问答缓存） │
│ ├── 对象存储：OSS/S3（原始文档） │
│ └── LLM服务：自研（vLLM）/ 商用API（有降级策略） │
│ │
│ │
│ 2. 关键设计决策 │
│ │
│ (1) 知识库组织 │
│ ├── 按产品/主题分库分表，独立检索 │
│ ├── 元数据：产品版本、更新时间、阅读量、有效性标记 │
│ └── 过期文档自动归档（避免用旧版本文档回答） │
│ │
│ (2) 转人工时机与策略 │
│ ├── 用户明确说"要人工" │
│ ├── 连续2轮无法提供满意答案（基于用户点踩） │
│ ├── 检测到负面情绪（愤怒/投诉） │
│ ├── 涉及金钱/账户安全的敏感操作 │
│ └── 超过最大对话轮次（如5轮）仍未解决 │
│ │
│ (3) 风控与安全 │
│ ├── 敏感词过滤（输入+输出） │
│ ├── 话题边界控制（如拒绝回答竞品对比、政治相关问题） │
│ ├── PII（个人身份信息）检测与脱敏 │
│ └── LLM输出审核（检查幻觉/不当内容） │
│ │
│ 3. 监控与优化闭环 │
│ │
│ 用户对话 → 记录全量日志 → 人工抽检失败案例 → │
│ ↓ │
│ 更新Prompt/知识库 ← 分析归因（检索问题/LLM问题/数据问题） │
│ │
│ 关键指标： │
│ · 自动化解决率（目标60%+） │
│ · 用户满意度（目标>4.2/5） │
│ · 平均响应时间 │
│ · 转人工率（越低越好，但不能牺牲质量） │
│ · 人均成本（对比全人工客服） │
│ │
└──────────────────────────────────────────────────────────────┘Q7: 设计一个代码助手系统
需求场景：企业内部IDE插件，帮助开发者：
- 代码补全与生成
- Code Review建议
- 代码解释（理解陌生代码库）
- 单元测试生成
- Bug排查建议
设计要点：
┌──────────────────────────────────────────────────────────────┐
│ 代码AI助手设计 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. 核心能力分层 │
│ │
│ (1) Line-level补全（实时，<200ms） │
│ ├── 小模型 + 本地缓存 │
│ ├── 基于当前文件上下文推理 │
│ └── 类似GitHub Copilot的体验 │
│ │
│ (2) Block-level生成（按需，1-3秒） │
│ ├── 生成函数/类/测试用例 │
│ ├── 需要更多代码库上下文 │
│ └── 用RAG检索相关代码作为reference │
│ │
│ (3) 指令式问答（用户提出需求，5-15秒） │
│ ├── "重构这个函数" / "添加错误处理" │
│ ├── 需要理解完整函数/文件上下文 │
│ ├── Agent模式：分析 → 规划 → 生成 → 审查 → 输出 │
│ │
│ 2. 上下文管理（最关键的设计决策） │
│ │
│ 问题：大模型上下文窗口有限（8K/32K tokens） │
│ 一个中型代码库可能有百万行代码，无法全部传给LLM │
│ │
│ 解决方案：分层上下文 + 按需检索 │
│ │
│ Local Context（LLM直接可见）： │
│ ├── 当前打开的文件 │
│ ├── 当前光标位置的前后50行 │
│ ├── 相关文件（import的模块/被调用的函数） │
│ └── 最近编辑的2-3个文件 │
│ │
│ Retrieval Context（按需检索）： │
│ ├── 当前函数/类的定义 │
│ ├── 相关API文档 │
│ ├── 代码库中相似的实现（提供参考模式） │
│ ├── 团队编码规范/最佳实践 │
│ └── 项目README/架构文档 │
│ │
│ 3. 代码检索（Code RAG） │
│ │
│ 关键挑战： │
│ · 代码的结构化信息（函数、类、依赖）需要保留 │
│ · 简单按行切分会破坏代码结构 │
│ · 需要理解AST（抽象语法树） │
│ │
│ 解决方法： │
│ ├── 按函数/类切分（AST-based chunking） │
│ ├── 提取函数签名 + docstring + 关键代码作为检索单元 │
│ ├── 用Tree-Sitter解析多语言代码结构 │
│ └── 索引元数据：语言/文件路径/函数名/导入依赖 │
│ │
│ 4. 关键Prompt工程技巧 │
│ │
│ (1) Code Review Prompt │
│ "你是资深代码审查专家，请审查以下代码，关注： │
│ 1) 潜在Bug和逻辑错误（最高优先级） │
│ 2) 性能问题（时间/空间复杂度） │
│ 3) 代码风格与可读性 │
│ 4) 安全漏洞（如SQL注入、XSS、权限问题） │
│ 5) 缺少的边界case │
│ │
│ 请按重要性排序输出建议，每条建议提供：问题 → 原因 → 修改后代码"│
│ │
│ (2) 测试用例生成 Prompt │
│ "为以下函数生成全面的单元测试： │
│ 要求覆盖：正常流程 / 边界条件 / 异常输入 / 空值 / 并发场景│
│ │
│ 用 pytest + unittest.mock 编写，包含： │
│ · fixtures（准备测试数据） │
│ · 描述性的test_case名称 │
│ · 断言信息完整 │
│ · 注释说明测试意图 │
│ │
│ 5. 隐私与安全（企业内部代码的核心关切） │
│ │
│ · 禁止上传代码到外部LLM服务（除非有严格数据保护协议） │
│ · 优先选择私有化部署模型（如CodeLlama + vLLM） │
│ · 数据传输加密，日志脱敏（去除API密钥/密码等） │
│ · 审计日志：记录哪些代码被发送给了LLM │
│ · 禁止在prompt中包含敏感配置（数据库密码、内部token等） │
│ │
└──────────────────────────────────────────────────────────────┘Q8: 设计一个多模态知识库系统
需求：除了文本，还需要处理PDF、代码、图片、表格等多种格式
设计要点：
不同内容类型的处理策略：
1. 纯文本（.md/.txt）
· 直接按语义切分 → 向量库
2. PDF文档
· PDFMiner提取文本
· 按页+段落切分（保留页码元数据）
· 检测图片 → OCR提取
· 检测表格 → 结构化转成Markdown表格
3. 代码文件（.py/.js/.java等）
· Tree-Sitter解析AST
· 按函数/类切分
· 向量：用CodeBERT/code-embedding模型
· 元数据：文件名、函数签名、类名、import依赖
4. 表格数据（Excel/CSV）
· 转成JSON/Markdown格式
· 每行/每段生成一个向量
· 关键：保留表头信息（每个chunk都带上表头）
· 示例："月份: 1月, 销售额: 100万, 同比: +15%"
5. 图片与图表
· 提取图片标题/说明文字（作为文本向量化）
· 用OCR提取图片中的文字
· 或用多模态Embedding模型（如CLIP/BLIP-2）
· 产品内优先用图生文，再对文本做向量化
混合搜索设计：
┌─────────────────────────────────────────────────┐
│ 用户查询 → [查询解析] │
│ │ │
│ ┌────────────┴────────────┐ │
│ ↓ ↓ │
│ 文本向量检索 元数据/标签检索 │
│ (Milvus) (Elasticsearch) │
│ │ │ │
│ └────────────┬────────────┘ │
│ ↓ │
│ RRF融合 + 重排序 │
│ ↓ │
│ LLM生成答案（带上引用来源） │
└─────────────────────────────────────────────────┘四、常见面试场景问答
Q9: 如何避免LLM产生幻觉？
工程化解决方案（从强到弱排序）：
✦ 1. RAG + 引用检查（最有效）
├── 强制模型只基于检索到的文档回答
├── 答案中引用来源标注（方便用户核查）
├── 用LLM-as-a-Judge检查答案是否都能在文档中找到依据
└── 对没有引用的内容进行标记或删除
✦ 2. Prompt约束（简单有效）
├── "只基于参考资料回答，如果资料中没有明确信息，请说明'暂无相关信息'"
├── "禁止输出没有依据的推测内容"
├── "回答前先在参考资料中找到依据，用 [来源:x] 标注"
✦ 3. 限制回答空间
├── 让模型只做选择题/判断题（减少自由发挥空间）
├── 输出格式严格限制（JSON Schema、选项列表）
└── 多步推理：让模型先列证据，再给答案
✦ 4. 检索增强
├── 更多的相关文档 → 更少需要"猜测"
├── 增加检索top-K（从5个增加到10-20个）
├── 混合检索 + 重排序，确保召回质量
└── 多跳检索：根据第一轮结果生成新查询再检索
✦ 5. 自我验证
├── 让模型自己检查："你的回答中每个陈述都能在参考文档中找到依据吗？"
├── 让模型给出"置信度"分数
└── 用不同的方式问同一个问题，检查答案一致性
✦ 6. 数据层面
├── 确保知识库完整性（覆盖率高、时效性好）
├── 定期更新知识库
└── 标注和优化：收集幻觉案例，用于改进Prompt和知识库
✦ 7. 模型选择
├── 更大的模型幻觉更少（GPT-4 < GPT-3.5 < Llama）
├── 经过RAG-finetune的模型表现更好
└── 调整temperature：降低温度（0-0.3），让模型更保守
实际项目中：通常组合使用1+2+3+5，可将幻觉率从20-30%降到5%以下Q10: 如何设计LLM系统的缓存策略？
缓存层级设计（从热到冷）：
Layer 1: Query语义缓存（命中率约30-50%）
├── 把用户Query → Embedding → 用向量相似度找命中
├── 如果找到非常相似的历史查询，直接返回缓存答案
├── TTL: 1-7天（根据知识库更新频率）
└── 成本极低，提升体验显著
Layer 2: Embedding缓存（稳定的高命中率）
├── 文档向量化结果（文档不变，Embedding不变）
├── 常见Query向量化
└── 用Redis/Milvus持久化存储
Layer 3: 检索结果缓存（中等命中率）
├── Query → 检索Top-K文档列表
├── TTL: 几小时到1天
└── 适合知识库更新不频繁的场景
Layer 4: LLM输出缓存（高ROI，但风险大）
├── 仅缓存事实性问答（确定性答案，不缓存主观性问题）
├── 加版本号（知识库版本+Prompt版本）
├── 知识库更新后清理相关缓存
└── TTL: 7-30天
缓存失效策略：
· TTL到期（时间衰减）
· 知识库更新事件触发（主动失效）
· 用户点踩/不满意 → 从缓存中移除
· Prompt版本更新 → 全量失效
缓存监控：
· 命中率、平均节省时间/成本
· 缓存污染检测（缓存了错误答案）
· 热点Query识别Q11: 如何处理AI系统的成本控制？
成本构成（按占比排序）：
1. LLM推理（占50-70%）
2. Embedding推理（占10-20%）
3. GPU/云服务器成本（占10-20%）
4. 向量数据库存储（占5-10%）
5. 人力/运维
优化手段：
✦ LLM成本优化
· 选合适大小的模型：简单任务用gpt-3.5-turbo/本地小模型，
复杂任务才用GPT-4
· 缓存（参见Q10）
· 严格控制max_tokens（避免生成过长回答）
· 混合策略：先用小模型尝试，不行再升级到大模型
· 批量处理：将多个简单请求合并为一个
✦ Embedding成本优化
· 用轻量模型（如BGE-small替代text-embedding-3-large）
· 缓存（大多数文档只需要向量化一次）
· 批处理（一次调用处理多个文本）
· 离线构建：冷数据用便宜的CPU批量向量化
✦ 工程化成本优化
· 合理设置超时（避免"卡住"的请求持续消耗资源）
· 监控异常请求模式（如某用户/IP频繁调用 → 限流）
· 定期清理不活跃数据（降低向量库压力）
· 混合部署：高频简单请求用本地小模型，低频复杂请求用云API
✦ 成本监控与告警
· 每日/每小时Token消耗报表
· 设置预算阈值（超过X美元/天告警）
· 异常检测：突然成本飙升可能是bug
· 按业务来源分析：哪些入口消耗最高？是否值得？Q12: 如何做一个可维护的Prompt工程体系？
生产级Prompt管理最佳实践：
1. Prompt版本化
· 像代码一样管理Prompt（Git管理）
· 每个变更都有commit message
· 每次变更后在评测集上跑回归测试
· 支持快速回滚（"这个版本效果变差了，回到上一版本"）
2. Prompt模板化
· 抽取公共部分（角色定义、格式要求）
· 按场景组织：qa_prompt / code_review_prompt / summarize_prompt
· 支持配置化：不同场景用不同模板 + 动态注入变量
3. A/B测试框架
· 新Prompt先对10%用户生效
· 对比实验组 vs 对照组的关键指标（满意度/准确率）
· 统计显著后全量推广
· 保留优秀的Prompt版本，淘汰效果差的
4. 评测与回归
· 维护一个"金标准"评测集（100-1000条）
· 每次Prompt变更都跑这个评测集
· 记录历史分数趋势（确保不会"优化"反而变差）
· 收集用户不满意的case加入评测集 → 驱动下一轮优化
5. Prompt元数据管理
· 每个Prompt都有：版本号、更新时间、预期效果、
关联的评测集、负责的工程师
· 定期检查：是否有不再使用的Prompt？是否过期？
6. 应急方案
· 关键场景有降级Prompt（简化版，更保守）
· 线上出问题：一键回退到已知稳定版本 + 人工兜底
· 定期演练"Prompt事故响应流程"
7. Prompt安全
· 检测Prompt注入（用户尝试让模型忽略系统指令）
· 禁止输出系统指令/提示词
· 检测越权（绕过系统限制的用户输入）五、系统设计核心原则总结
┌─────────────────────────────────────────────────────────────┐
│ AI应用设计的10条原则 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 简单优先原则 │
│ 先实现最简单可工作的版本，再逐步优化 │
│ 能用Prompt解决的就不用RAG，能用RAG解决的就不用微调 │
│ │
│ 2. 评估驱动开发 │
│ 先建立评估指标和评测集，再开始优化 │
│ 没有评估的优化是赌博 │
│ │
│ 3. 错误是设计出来的，不是调试出来的 │
│ 设计时就考虑：系统可能怎么失败？降级方案是什么？ │
│ │
│ 4. 可观测性优先 │
│ 从Day 1开始就要有日志、监控、告警 │
│ 如果你看不到它如何工作，你也无法改进它 │
│ │
│ 5. 不要试图让LLM做一切 │
│ 把确定性逻辑用传统代码实现（公式计算、条件判断、正则）│
│ 只把真正需要语义理解的部分交给LLM │
│ │
│ 6. 知识是产品的核心资产 │
│ 对于RAG应用，知识库的质量 > 模型大小/架构设计 │
│ 数据清洗、去重、时效性维护值得投入80%的精力 │
│ │
│ 7. Prompt是代码 │
│ 需要版本控制、Code Review、测试、回归、文档 │
│ │
│ 8. 成本从第一天开始考虑 │
│ 设计时就要考虑Token成本与扩展性 │
│ 100 QPS时还省钱的系统，1000 QPS时才不会崩 │
│ │
│ 9. 用户反馈是优化引擎 │
│ 建立从"用户不满意"到"系统改进"的闭环 │
│ 1个失败案例的价值 > 100个成功案例的价值 │
│ │
│ 10. 安全不是可选项 │
│ 隐私保护、内容合规、反滥用、审计追踪是核心功能 │
│ 不是后期再打补丁 │
│ │
└─────────────────────────────────────────────────────────────┘场景设计高频问题速查
| 问题 | 关键设计思路 |
|---|---|
| 如何避免LLM幻觉？ | RAG+引用标注、Prompt约束、自我验证、降低temperature |
| 如何做成本控制？ | 模型分层（简单任务小模型）、缓存、设置预算告警 |
| 如何评估RAG效果？ | 检索指标(P@K/Recall@K) + 答案质量(LLM-as-a-Judge/人工评测) |
| 知识库如何维护？ | 按主题分区、元数据管理、定期清理过期、版本追踪 |
| 如何做Prompt工程体系？ | 版本化、模板化、A/B测试、评测集、可回滚 |
| 多模态数据如何处理？ | 不同类型用不同切分策略/Embedding模型，统一向量库 |
| 如何做系统可观测性？ | 全链路日志、指标监控、异常告警、用户反馈闭环 |
| 系统设计中什么最重要？ | 评估体系 + 知识库质量 + Prompt工程 + 可观测性 + 安全合规 |