AI 与大模型工程 面试题库

如果操作只有一次请求，周围控制流也是普通应用代码，就直接调用模型。步骤可由程序确定，而你需要统一调用、组合与追踪时，使用可运行顺序链、并行映射或分支。只有必须让模型选择工具，或决定任务需要多少轮迭代时，才使用 create_agent。每增加一层都会同时增加灵活性与故障面，因此应选择足以表达行为的最小控制结构。

先明确每条边传递的具体值：映射、提示词值、消息、字符串或领域对象。调用最短的上游片段并检查结果，再加入下一个组件。核对必需的字典键，并确认解析器是否有意把消息转换为文本或结构化数据。模式与图检查能够辅助诊断，但不能证明服务商的内容行为。应在每个不稳定边界保留契约测试，让集成升级在靠近变化组件的位置失败。

参数模式只检查数据形状，不会验证权限或业务策略。工具必须认证运行时身份，授权所请求的资源与动作，限制路径和金额，并避免在结果或追踪中泄漏秘密。有副作用的工具还需要幂等键与持久结果记录，因为模型、网络或图重试都可能重复调用。模型选择的参数仍是不可信输入；高风险工具应放入严格允许列表，成本较高或难以撤销的动作还要先经过人工批准。

当 stop_reason 为 tool_use 时，应遍历每个 tool_use 块，不能假设第一个块就是唯一调用。工具名称只能从允许列表解析；执行处理器前还要验证参数、认证当前主体，并授权资源和动作。随后原样追加助手内容，再为每个 tool_use_id 添加一个用户角色的 tool_result；失败时也要返回明确的错误结果。续接请求继续发送同一套工具定义。有副作用的处理器还必须保存幂等键和执行结果，否则模型、网络或进程重试可能重复执行动作。

先盘点每个导入符号，再修改程序行为。LangChain 1.x 的主包以 create_agent 为核心，许多旧式链和辅助工具已移到 langchain-classic；不要每遇到一个缺失导入就盲目添加这个包。如果可运行组合能让数据流更清楚，就用它替换固定旧式链，并用 create_agent 替换旧智能体构造器。记忆应重新设计为带检查点的线程状态，而不是进程全局历史。最后还要测试服务商、工具调用、流式处理与持久化行为。

每次请求都要包含生成下一条助手消息所需的对话状态；API 不会在两次调用之间替应用保存聊天会话。因此，持久化、历史删减、租户隔离和重放都由应用负责。正常继续对话时，应按顺序重新发送相关的用户与助手消息。处理客户端工具时，还要保留包含全部 tool_use 块的助手内容，再追加用户角色的 tool_result 块，并确保 ID 配对。无状态设计有利于审计，但前提是保存的历史完整且作用域正确。

content 数组是带类型标签的联合结构，不是单一文本字段。一个响应可能包含文本、一个或多个 tool_use 块，或其他已启用能力产生的块，因此代码应按 type 分派每个块，并允许协议扩展。stop_reason 描述轮次级结果：end_turn 表示正常结束，max_tokens 可能意味着输出不完整，tool_use 则要求应用继续一次往返。只看内容会漏掉终止状态，只看停止原因又会漏掉各块承载的工作。遇到未知值时应生成安全诊断，不能套用危险的默认行为。

只对暂时性 HTTP 故障进行有界退避，并把 SDK 已执行的重试计算在内。认证失败和无效请求需要修正，不能原样再发一次。流可能在 HTTP 200 之后失败，因此在 message_stop 之前，部分文本始终是不完整结果；新请求会产生一次新的生成，不能假装续传并拼到旧文本后。工具执行是另一个事务边界。重试前应保存调用 ID、幂等键与执行结果；遇到结果不明的超时时，先查询既有结果，避免重复副作用。

按协议增量解析每个事件并实施背压，不要先缓冲完整响应。在收到文档规定的终止事件前，已接收文本都只是暂定结果；终止后还要检查停止原因、用量和计时字段。如果连接先关闭，即使文字读起来流畅，输出仍不完整。连接与读取都要设置有界超时，重试必须遵循明确策略。重试会开始一次新生成，不能作为旧流的续传拼接。执行任何副作用前，还要验证完整输出并使用应用级幂等键。

在明确的终止事件报告可接受响应状态之前，流式文本都只是暂定内容。即使已经收到 HTTP 200，连接断开仍代表输出未完成；重试会开始新的生成，不能假装续传并拼接到旧流。重试前必须分类错误：暂时性限流可以遵守 Retry-After，认证失败、无效请求和支出上限则需要处置。SDK 内部重试也要计入总尝试预算。验证完成后，每个业务副作用都应通过独立、已授权的事务提交，并绑定持久幂等键与结果记录。

这条边界从服务商请求之前开始，在应用作出决定后结束。它根据可信指令与来源明确的不可信数据构造版本化请求，设置模型和输出限制，并记录关联信息。响应返回后，边界检查完成状态，解析内容，验证模式与领域约束，再选择明确的回退路径。权限和副作用留在模型适配器之外：应用代码负责认证调用者、授权动作并处理幂等性。日志只保存获准的元数据与删减后的诊断信息，不保存完整敏感提示词。

模式只能证明数据具有预期形状，不能证明事实正确、分类恰当，或请求的动作已经授权。合法金额仍可能超过业务上限，合法账户 ID 也可能属于另一个租户。因此，模式验证只是其中一道关卡。之后还要执行允许列表、领域不变量与必要的来源检查，并根据运行时身份完成授权。对于后果重大的动作，应要求人工批准和幂等键，不能靠再次询问模型来确认。

分隔能够记录来源，也有助于模型区分意图，但指令与数据最终仍进入同一个模型上下文。恶意用户消息或检索文档即使带有标签和分隔符，仍可能影响生成结果。可靠控制应放在这种语言影响之外：限制模型可选择的动作，验证输出，在执行时重新授权每个资源与操作，并按最小权限配置工具。高影响动作还需要独立策略或人工关卡。测试必须覆盖直接与间接注入，包括文档和工具结果中的恶意内容。

先在版本化评测集上保存旧配置的基线；案例应覆盖代表性输入、边界条件和对抗性输入。一次只改一个主要变量，才能判断回归来源。运行新旧配置，保留原始输出与解析结果，并查看案例级差异，不能只看总分。有争议的预期行为由领域负责人裁决。离线评测通过后，再小范围发布并观察验证失败、人工改判、回退和用户纠正。旧配置应继续可用，为生产回归保留经过测试的回滚路径。

选择与上线环境一致的切分边界，例如用户、会话、来源文档或时间，并让每个分组只出现在一侧。切分前检测完全重复和近重复样本。词表、IDF、特征选择、校准以及所有需要学习的预处理步骤都只能在训练集上拟合；验证集与测试集只能被转换。日常模型和阈值选择使用验证集。最终测试集保持只读并记录每次使用。如果简单基线高得不合理，应先调查泄漏，再相信复杂模型的结果。

准确率给每个样本相同权重，因此只预测多数类的系统也可能看起来尚可，却完全识别不出稀少但代价高的类别。应报告混淆矩阵，以及逐类精确率、召回率、F1 和支持数。宏平均让各类别等权，微平均汇总所有决策，通常受常见类别主导。阈值应根据验证集上的误报、漏报和转人工成本选择。随后按语言、渠道、长度和时间段检查失败样本，因为一个平均值无法定位问题。

当受支持任务的预处理、模型调用与标准后处理正好符合需求时，可用 Pipeline 快速验证，它会返回面向任务的 Python 值，初始化代码也较少。需要显式控制批处理、张量、自定义池化、设备放置或后处理时，应组合 AutoTokenizer 与任务专用 AutoModel。无论选择哪种入口，都要显式给出仓库 ID、任务与提交哈希。Pipeline 只是同一批制品之上的便利层；调用成功并不能验证标签语义或业务策略。

先把选定分支或发布标签解析为完整提交哈希，再将同一 revision 传给 tokenizer、处理器、配置与模型的每次加载。从空缓存开始构建并实例化目标类，然后启用 local_files_only，在离线环境中重复启动。仓库哈希还要与锁定的 Transformers、huggingface_hub、张量后端及 Python 版本一起记录，同时保存设备与数据类型策略。应用发布物应包含制品清单和评测结果；只固定模型提交仍不够，因为加载代码与数值内核也会改变行为。

先检查模型卡中的预期用途、限制、训练背景、评测证据与许可证。确认仓库任务和架构符合加载器，再检查固定修订版本的文件清单、大小、权重格式及自定义 Python 代码。优先选择经过审核的 Safetensors 权重；除非固定版本代码已完成审核与隔离，否则保持 trust_remote_code 关闭。还要确认受限访问义务，并用领域内的代表性、边界与对抗输入评测。流行度和下载量只能帮助发现模型，不能替代安全审查或需求验证。

通过 HF_TOKEN 或受控密钥注入提供最小范围的只读 token，绝不能从源码或请求数据读取。Hub 远端授权保护下载过程，但快照下载后便由本地文件系统权限控制。共享缓存可能让不同服务身份或租户读到受限制品，因此必须明确所有权与挂载策略。token 轮换和缓存删除是两个操作，撤销 token 不会清除本地文件。日志只保留仓库 ID、提交哈希与请求 ID，排除凭据和敏感路径，并分别测试有权冷缓存下载与无凭据离线启动。

当工作负载有明确的数据驻留或离线要求，某个通过领域评测的模型能在现有硬件上运行，而且预期负载值得自行运维时，可以选择本地推理。比较本地与托管方案时，应使用相同的质量案例、延迟目标和完整成本模型。如果需要最强的托管模型、快速弹性或服务商的服务等级协议，本地部署通常不是默认选择。它还会把补丁、容量、监控、访问控制和恢复责任交回团队，这些工作必须计入决策。

先用参数量乘以每个权重的位数得到下限，再检查实际制品与运行器元数据。总量还要加入运行时缓冲区、计算图、驱动和 KV 缓存。缓存需求会随模型架构、上下文长度、缓存类型、批量和并发序列变化，因此只看文件大小不够。应在真实机器上运行准确的制品、运行器版本和后端，并使用最长允许输入输出及目标并发。记录系统内存与显存峰值、卸载行为、加载失败和延迟，同时保留运行余量。

记录模型来源与不可变修订或文件摘要、量化类型、分词器、聊天模板、运行器版本、启动参数、硬件后端及相关驱动版本，并把领域评测集和结果关联到这套准确组合。可变模型标签以后可能指向不同字节，因此并不足够；只固定权重也没有固定模板或运行器行为。应从空缓存构建一次，在阻断网络后验证启动，并保留经过审核的制品包。回滚必须恢复已测试组合，不能临时寻找名称相似的模型。

先明确产品必须做出的决定，再定义输入单位与输出形状，例如文档标签、词元标签、原文跨度、候选排序或生成文本。随后规定标签集合、无法判断时的路径、跨度边界约定，以及各类错误的业务成本。编写标注指南，并检查不同标注者能否一致执行。最后选择与决策相符的指标和数据切片。模型选择应放在后面，因为更强的模型无法修复互相重叠的标签，也无法让不可验证的输出变得可验证。

规范化是面向具体任务的视图，不是无损替代品。NFKC、大小写折叠、空白压缩或标点删除都可能改变内容与字符串长度，因此基于该视图计算的模型跨度未必能正确切割原文。展示、审计和重新标注仍需要原文。系统应原样保存输入，为每项转换记录版本，并使用分词器提供的偏移量映射或显式维护映射。跨服务时还要说明偏移量统计的是字节、Unicode 码点、UTF-16 代码单元、字素簇还是模型词元。

新的文本生成应用应把 Responses API 作为直接调用模型的边界，尤其是结果可能包含推理项、工具调用或流式事件时。API 负责模型推理和文档规定的响应协议；应用仍负责用户认证、授权、输入限制、租户隔离、响应验证、业务策略与副作用控制。应把这些控制放在小型服务商适配器周围。即使响应成功且状态为 completed，它仍只是模型输出，并不自动授予发布、付款、删除或更新记录的权限。

output 是类型化序列，不是保证只含一条消息的固定信封。推理项或工具调用可能排在文本前面，响应也可能包含多个消息项，而消息内容还会包含多种块。窄的纯文本路径应先要求可接受的终止状态，再使用 SDK 的 output_text 聚合属性。协议级处理则要按类型遍历所有输出项与内容块，保留支持的非文本项，并安全处理未知变体。未完成或失败的响应必须进入明确回退，不能靠猜测索引尽量读取。

应把响应与对话 ID 当作租户范围内的资源引用，不能允许客户端任意挂接。使用 previous_response_id 的续接会获得此前响应上下文，但仍须再次发送本轮可信指令。响应链与 Conversation 对象的持久化方式不同，因此选择前要确定保留、删除和数据驻留策略。还要跟踪上下文增长，并为拒绝、压缩、摘要或重新开始建立经过测试的路径。规范业务状态应保存在自己的数据库中；服务商对话状态只是推理上下文，不能成为已批准决定的唯一记录。