大模型应用系统怎么设计？
Q: 设计一个企业知识库问答系统，你会怎么做？
A: 我会拆成 5 层：
- 接入层：用户认证、请求限流、会话管理。
- 知识层：文档解析、切分、embedding、向量库、权限 metadata。
- 检索层：query rewrite、hybrid search、rerank、权限过滤。
- 生成层：prompt 拼接、LLM 调用、引用来源、格式控制。
- 观测层：日志、trace、反馈、评估集、成本统计。
回答模板：
我会先保证知识进入模型前是干净、可检索、带权限的；再保证生成阶段 grounded in evidence；最后通过 trace 和评估集持续优化。
成本怎么控制？
Q: 大模型应用成本太高怎么办？
A:
- 缓存相同 query 或相同检索结果。
- 小模型做分类、改写、初筛，大模型做复杂生成。
- 控制 topK 和上下文长度。
- 对工具结果和文档片段做摘要压缩。
- 批量 embedding，异步处理文档入库。
- 设置最大 Agent 步数和超时。
- 对高频问题沉淀 FAQ 或规则答案。
面试表达：
成本主要来自 token、模型调用次数、embedding、rerank 和工具调用。优化时要先通过日志知道钱花在哪里。
缓存怎么做？
Q: 大模型应用里哪些地方可以缓存？
A:
- Embedding cache：同一文本不重复向量化。
- Retrieval cache：相同或相似 query 的检索结果。
- LLM response cache：确定性强的问题可以缓存答案。
- Tool result cache：外部工具结果短时间复用。
- Prompt fragment cache：固定系统提示和模板复用。
注意：
涉及权限和实时数据时，缓存 key 必须包含 user、tenant、权限范围和数据版本，否则可能返回越权或过期答案。
效果怎么评估？
Q: 你怎么判断大模型应用是真的成功，而不是表面跑通？
A: 不能只看 demo。要看离线评估和线上指标。
离线：
- 检索命中率。
- 答案准确率。
- 引用正确率。
- 幻觉率。
- 格式通过率。
- bad case 回归集。
线上：
- 用户采纳率。
- 点赞/点踩。
- 平均延迟。
- token 成本。
- fallback rate。
- 人工介入率。
关键句：
表面成功是链路能跑通，真实成功是答案可靠、成本可控、问题可定位、业务指标有改善。
没有解释信息怎么办？
Q: 如果模型给了答案但没有解释依据，怎么处理？
A:
- 要求输出 citation 或 evidence。
- 把检索证据和最终结论分开生成。
- 对答案做 verifier 检查。
- 如果证据不足，返回不确定而不是编造。
- 必要时调用外部工具补充事实。
面试表达：
对企业应用来说，答案可解释性很重要。没有证据的正确答案也很难被信任。
单 Agent 还是多 Agent？
Q: 一个复杂任务应该做成单 Agent 还是多 Agent？
A: 先从单 Agent 开始，只有任务复杂到需要明确职责隔离时再拆多 Agent。
适合单 Agent：
- 流程短。
- 工具少。
- 状态简单。
- 延迟要求高。
适合多 Agent：
- 任务可拆成规划、检索、执行、校验。
- 不同子任务需要不同模型或工具。
- 需要并行处理。
- 需要独立评估每个步骤。
面试回答：
多 Agent 不一定更好。它会增加通信成本、状态同步和调试难度。工程上我会先做清晰的 workflow，再判断哪些节点值得 Agent 化。
高并发和稳定性
Q: 大模型应用高并发怎么扛？
A:
- API 层限流和鉴权。
- 长任务放进消息队列。
- Worker 异步执行 Agent steps。
- 模型调用设置超时和重试。
- 工具服务做隔离和熔断。
- 对 session state 做持久化。
- 用 trace 系统观察每一步耗时。
追问：
Q: 怎么避免 Agent 死循环？
A: 设置最大步数、最大 token、最大运行时间、重复动作检测、任务完成判断和人工 fallback。
常见踩坑
Q: 大模型应用落地有哪些坑？
A:
- 只做 demo，不做权限、日志和评估。
- prompt 写死，后续无法版本管理。
- RAG 没有 citation，无法解释答案。
- 忽略缓存中的权限问题。
- 所有任务都用最贵模型。
- Agent 没有终止条件。
- 失败 case 无法复现。