AI面试八股文-13_12-AI 框架与运维面试题

pdf版下载链：https://pan.quark.cn/s/9cc742e9c2a8

13 AI 框架与运维：技术选型、部署监控与成本治理

更新： 2026-10-12

时效说明：框架、平台和 API 状态截至 2026-10。示例强调稳定概念；生产使用前应锁定版本并查官方迁移指南，不复制旧版 import path 或容器清单。

📋 目录

• LangChain v1、LangGraph v1、LlamaIndex、DSPy
• 向量检索、测试与生产部署
• Coze、Dify、n8n、OpenClaw 选型
• Function Calling、Streaming、Prompt Caching
• Responses API 与运维治理

一、框架使用题

Q1: LangChain 的核心组件有哪些？如何使用？

截至 2026-10，LangChain v1已把核心聚焦到 Agent：

• langchain.agents.create_agent：高层 Agent 入口，内部基于 LangGraph。
• messages / content blocks：统一文本、多模态和工具消息。
• tools：schema、注入和执行接口。
• chat models / embeddings：供应商集成。
• middleware：模型选择、重试、审批、摘要、guardrail 等横切逻辑。

旧版LLMChain、大量 legacy chains/retrievers/indexing 已移到langchain-classic。面试中继续把LLMChain(prompt=..., llm=...)说成 v1 推荐写法是过时的。

简化示意：

fromlangchain.agentsimportcreate_agent agent=create_agent(model="provider:model-from-config",tools=[lookup_order],system_prompt="Use tools only for authorized orders.",)result=agent.invoke({"messages":[{"role":"user","content":"查询订单 A"}]})

模型不能直接获得数据库权限；lookup_order内部仍须鉴权。

Q2: LangGraph 和 LangChain 有什么区别？什么时候用 LangGraph？

• LangChain v1 Agent：常见 tool loop 的高层封装。
• LangGraph v1：低层、持久、有状态 orchestration runtime，适合自定义状态机。

用 LangGraph 当你需要：

• durable execution / checkpoint / resume。
• 明确分支、循环、并行和终止条件。
• human-in-the-loop 审批。
• 确定性节点与模型节点混合。
• 长运行任务的失败恢复和补偿。

用高层 Agent 当标准 ReAct/tool loop 足够。不要为了“画图”引入 LangGraph；持久化状态、幂等和升级兼容才是运维成本。

Q3: 如何使用 LlamaIndex 构建 RAG？和 LangChain 有什么区别？

LlamaIndex 当前定位是 RAG、文档连接、索引、query engine、agent 和 workflow 工具包。

RAG 关键组件：

Reader/Connector → Parser/Node → Embedding + Index → Retriever → Postprocessor/Reranker → Query Engine / Workflow

与 LangChain 的区别是侧重点，不是绝对边界：

• LlamaIndex 对数据接入、node/index/retrieval 抽象更集中。
• LangChain v1 对统一 Agent 接口和 middleware 更集中。
• LangGraph 提供更低层 workflow runtime。

选型看团队现有代码、trace/eval、provider 支持、抽象泄漏和升级成本。简单 RAG 用原生 SDK + 向量库也可能更易维护。

二、向量数据库题

Q4: 向量数据库索引有哪些？怎么选？

• Flat：精确基线。
• HNSW：内存图，高召回低延迟，图内存较大。
• IVF_FLAT/PQ/SQ：聚类分桶，可配量化。
• DiskANN/Vamana、SPANN：内存—SSD 分层。
• GPU CAGRA/cuVS：批量和 GPU 常驻场景。
• sparse / inverted：BM25、learned sparse。
• multivector / late interaction：token/patch 级匹配。

不能按“数据量口诀”选。基于真实 query、filter、写入、硬件和 Recall@k–P99–成本曲线决策。详见本目录 07 专题。

Q5: 如何优化向量检索精度和速度？

质量：

• embedding 领域评测与 query/document 指令一致。
• 结构化 chunk + parent/child retrieval。
• sparse+dense hybrid 与 reranker。
• hard negatives、query rewriting、多向量 late interaction。

性能：

• 按目标召回调ef/nprobe/ candidate depth。
• 原始向量与量化码分层，候选后精排。
• metadata/payload 建索引。
• 批量、分片、缓存与冷热分层。

每次改动必须同时看检索质量、端到端答案、P99、写入和资源。

Q6: Metadata 过滤怎么用？有什么风险？

用途：tenant、ACL、时间、类型、地域、状态。

安全条件必须在检索结果进入模型前强制执行：

authorized_set ∩ ANN_candidates

实现可用 pre-filter、filter-aware graph、iterative filtering 或分区。选择率极低或条件复杂时，ANN 图可导航性和尾延迟会变化。

为常用字段建 scalar/payload index；禁止把 ACL 只写在 prompt 或 top-k 后过滤，否则会越权或返回不足。

三、测试评估题

Q7: 如何测试 AI 应用质量？

测试金字塔：

1. unit：parser、chunk、tool schema、权限、引用。
2. component：retriever、reranker、router、guardrail。
3. task：端到端 golden set。
4. adversarial：注入、越狱、secret、资源耗尽。
5. load/failure：限流、provider 超时、重试、降级。
6. online：shadow/canary/A-B。

指标必须按场景：

• RAG：retrieval recall/nDCG、faithfulness、citation。
• Agent：任务成功、步骤/费用、错误副作用、人工接管。
• NL2SQL：execution accuracy、越权、扫描成本。
• 多模态：OCR、grounding、页/bbox/timestamp。

Q8: 如何构建 AI 应用测试集？

• 从真实流量按语言、长度、风险、租户、难度分层抽样并脱敏。
• 补充边界、对抗和历史事故。
• 保存 provenance、rubric、reference、allowed_variants。
• 按来源/时间/实体隔离，防训练污染。
• 双标 + 仲裁；记录分歧，不强造唯一答案。
• 每个重大线上事故都转成回归样本。
• public benchmark 只作参考，发布门槛用私有集。

四、部署运维题

Q9: 如何部署 LLM 应用到生产？

分层部署：

edge/WAF → API gateway → stateless app/orchestrator → model endpoints / inference cluster → retrieval/data/tool services → sandbox workers

核心要求：

• 容器/依赖/SBOM、secret manager、网络策略。
• readiness 与 startup probe 分开；模型加载不等于可服务。
• 有界队列、admission control、取消和背压。
• canary、模型 snapshot、prompt/index 版本、快速 rollback。
• tracing 贯穿模型、检索、工具和审批。
• 多可用区/region 策略与数据驻留。

GPU 服务扩缩不能只看 CPU/QPS；应看 running/waiting tokens、KV Cache、TTFT/ITL 和队列。

Q10: 如何监控成本？如何优化？

成本归因：

• provider 输入/缓存/输出 token。
• embedding、rerank、检索和存储。
• GPU 空闲/利用、KV 容量、跨区网络。
• sandbox CPU/时长、工具 API 和人工复核。

核心指标是：

cost per successful task

优化顺序：消除无效请求 → 改检索/上下文 → 缓存 → 路由 → batch → 量化/自托管。成本下降若导致任务成功率下降，可能总体更贵。

五、低代码与 Agent 平台

Q11: Coze 如何搭建 AI 应用？与传统开发有什么区别？

Coze 官方文档 的核心包括 Agent/App、Workflow、Plugin 和 Knowledge：

• Workflow 用节点表达业务逻辑，可调用 plugin。
• Plugin 是 API tools 集合。
• Knowledge 支持文本、表格、图片等数据与检索。
• 发布后可通过 API 执行 workflow。

适合快速验证、业务人员参与和标准集成。限制：

• 复杂版本管理、自动测试、供应商锁定。
• 数据驻留、网络/插件权限和审计。
• 深度定制、性能和故障恢复。

传统代码开发控制更强，但交付/运维成本更高。企业常用低代码做原型/内部流程，核心高风险路径保留代码和独立 policy。

Q12: Dify 本地部署与性能优化怎么做？

截至 2026-10，[Dify Docker Compose 官方文档显示当前部署包含 API、WebSocket、worker、plugin daemon、agent backend、sandbox、SSRF proxy、数据库、Redis、向量库等多个服务。旧文只列 6 个容器和固定端口已过时。

生产注意：

• 固定 release tag，不直接用 main。
• 从最新.env.example生成配置，升级逐项合并新增变量。
• 首次上线前更换SECRET_KEY，关闭 debug，配置 HTTPS。
• 外置数据库/Redis/对象存储时验证 HA、备份和恢复。
• sandbox、SSRF proxy、plugin egress 默认最小权限。
• Web/worker/beat 分别扩缩；按队列、耗时和任务类型拆 worker。
• 备份 volumes、数据库、对象存储和.env，并演练恢复。

不要承诺“连接池调一下从 100 到 500 QPS”或“HNSW 让延迟 500ms 到 50ms”；这些数字必须来自自己的压测。

Q13: Function Calling 如何实现并行调用和错误重试？

模型只生成调用意图，应用执行工具：

model → function_call(name, args) app → auth + validate + execute app → function_result model → final response / next calls

并行条件：

• 调用相互独立、无顺序依赖。
• 每个工具有独立超时、取消和配额。
• 汇总结果保留 call ID。

有副作用工具：

• 幂等键、乐观锁、预览和审批。
• 不自动重试非幂等写入。
• 业务错误结构化返回，模型不可伪造成功。

schema 校验之外还要做语义授权，例如order_id是否属于当前用户。

Q14: 如何实现 LLM 流式输出？

后端应把供应商事件转换为稳定内部协议，而非只拼字符串：

text.delta reasoning.summary.delta（若供应商提供且允许展示） tool.call tool.result usage done/error

浏览器文本优先 SSE/fetch stream；双向语音/视频用 WebSocket/WebRTC（按供应商协议）。

Nginx/网关：

• 关闭响应 buffering。
• 调整 idle timeout，而不是无条件设 600 秒。
• 客户端断开传播 cancellation。
• 对慢消费者设 buffer 上限。
• 不把内部 reasoning 原样暴露给用户。

Q15: 2026 年 Dify、Coze、n8n、OpenClaw 怎么选？

这四者不是完全同类：

• Dify：AI 应用/Chatflow/Workflow、知识库、模型管理和 API 发布，可自托管。
• Coze：托管/Studio 形态的 Agent、Workflow、Plugin、Knowledge，强调快速搭建和发布。
• n8n：通用自动化/integration workflow，AI 节点、MCP、Agent 与大量 SaaS 连接；适合跨系统流程。
• OpenClaw：更偏个人/任务型 Agent runtime 与 gateway，不是同级低代码应用平台；部署必须重视 gateway auth、sandbox 和 egress。

选型维度：

1. 托管还是自托管、许可证与数据驻留。
2. 工作流版本化、测试、审批、可观测性。
3. connector/plugin 供应链和 secret 管理。
4. sandbox 隔离、网络策略、租户权限。
5. API/SDK 可扩展性和迁移成本。

n8n AI 文档 已覆盖 Agent、tools、memory、vector DB、MCP 和 evaluations；其 AI starter kit 官方明确仅用于起步/测试，生产必须加固。

六、缓存、声明式编程与 API 迁移

Q16: Prompt Caching 是什么？如何正确优化？

缓存的是完全匹配的 prompt prefix 对应中间计算。稳定内容放前面，动态内容放后面：

tools + system + stable documents + examples | dynamic user turn

截至 2026-10：

• OpenAI prompt caching 对支持模型自动启用；GPT-5.6+ 还支持显式 breakpoint/TTL 配置。
• Anthropic prompt caching 支持顶层自动 caching 或在 content blocks 放显式cache_control。

不要硬编码旧价格/TTL 进业务逻辑。监控：

• 可缓存 tokens、cache read/write tokens。
• token-weighted hit rate。
• TTFT 和实际账单。
• model、tools、图片、adapter 或 prompt 变化导致的 miss。
• 租户隔离，避免 cache key 泄漏。

Q17: DSPy 是什么？为什么叫声明式 LLM 编程？

DSPy 用 typed signatures/modules 表达输入输出和组合结构，再用 optimizer 根据训练样例与 metric 搜索 instructions、demonstrations，部分流程也可优化模型权重。

核心结构：

classExtract(dspy.Signature):"""Extract normalized fields with evidence."""text:str=dspy.InputField()fields:dict=dspy.OutputField()program=dspy.Predict(Extract)optimizer=dspy.MIPROv2(metric=my_metric,auto="light")optimized=optimizer.compile(program,trainset=trainset)

优势：把 prompt 优化从手工字符串迭代变为可评测程序优化。限制：

• 必须有代表性 train/dev 和可靠 metric。
• optimizer 会产生较多模型调用和成本。
• 容易对小测试集过拟合。
• 编译产物、模型 snapshot 和数据必须版本化。

Q18: OpenAI Assistants API 还应该用吗？如何迁移？

不应该用于新项目。截至 2026-10，官方迁移指南 明确：Assistants API 已于2026-08-26 sunset，接口不再可用。

迁移映射：

• Assistants/Threads/Runs → Responses + Conversations 或应用自管历史。
• assistant instructions/tools → 应用配置或版本化 prompt。
• run steps → Responses typed output items / tool calls。
• thread message history → Conversations 或应用数据库。
• file search/code interpreter → Responses hosted tools（按当前能力）。

新项目使用：

• Responses API：直接模型调用或自建 agent loop。
• Agents SDK：应用内 agent、tools、handoff、guardrail。
• Agents API：需要供应商托管长运行 harness 时评估。

迁移时不能再依赖已下线 Threads 读取历史；必须使用迁移前保存的数据或自有数据库。

七、生产运维清单

发布

• 锁代码、SDK、模型 snapshot、prompt、tool schema、index 和容器 digest。
• 离线质量/安全、负载、故障和恢复测试。
• shadow → canary → progressive rollout。
• 数据库、向量库、对象存储、checkpoint 备份恢复演练。

可观测性

• OpenTelemetry trace 贯穿 gateway、retriever、model、tool、sandbox。
• 指标：TTFT、ITL、E2E、queue、tokens、cache、tool success、task success。
• 高基数 ID 放 trace/log，不直接做 metric label。
• 日志 PII/secret 脱敏与 TTL。

安全

• 每个工具最小权限；写操作审批和幂等。
• sandbox 默认 deny egress 和资源上限。
• plugin/MCP/connector 供应链审计。
• 多租户 ACL 在数据层执行。
• gateway 非 loopback 必须强认证、TLS 和 scope。

📝 速记卡片

• LangChain v1 用create_agent；旧LLMChain在 classic 兼容层。
• LangGraph 适合 durable state、审批和复杂状态机。
• Dify/Coze 是 AI 应用平台，n8n 是自动化平台，OpenClaw 是 Agent runtime/gateway。
• Prompt caching 依赖前缀精确匹配，监控 token-weighted hit。
• DSPy 用 metric 编译 prompt/demo，不会消除评测集需求。
• Assistants API 已于 2026-08-26 下线，新项目用 Responses/Agents。