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 推荐写法是过时的。

简化示意：

python 复制代码

from langchain.agents import create_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 关键组件：

text 复制代码

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、时间、类型、地域、状态。

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

text 复制代码

authorized_set ∩ ANN_candidates

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

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

三、测试评估题

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

测试金字塔：

unit：parser、chunk、tool schema、权限、引用。
component：retriever、reranker、router、guardrail。
task：端到端 golden set。
adversarial：注入、越狱、secret、资源耗尽。
load/failure：限流、provider 超时、重试、降级。
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 应用到生产？

分层部署：

text 复制代码

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 和人工复核。

核心指标是：

text 复制代码

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 如何实现并行调用和错误重试？

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

text 复制代码

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 复制代码

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。

选型维度：

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

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

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

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

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

text 复制代码

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，部分流程也可优化模型权重。

核心结构：

python 复制代码

class Extract(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。