AI 工程师
AI 工程师构建的产品，其中最关键的组件是一个并非由他们训练的模型。工作内容是检索与答案落地、上下文设计、评测体系、护栏，以及在底层模型不断变化的同时把延迟和开销控制在预算之内。本指南说明这一角色涵盖什么、什么时候它确实是合适的选择，以及如何把真功夫与流利的说辞区分开。
AI 工程师具体做什么？
AI 工程师构建行为依赖于基础模型的软件产品——通常是通过厂商 API 调用、或以托管方式运行的开放权重大语言模型。职责范围包括检索出正确的上下文并让输出有据可依、设计并对送入模型的指令做版本管理、搭建能说明一次改动是否真的带来改善的评测体系、针对被操纵或不安全的响应加装护栏，以及在真实流量到来后控制响应时间与开销。这是把软件工程应用在一个概率性而非确定性的组件上，而且很少涉及训练模型。
定义这一角色的，是一个工程师无法完全审视的依赖。模型有版本、有价格、有速率限制，还有一组会在厂商升级时发生变化的行为。因此，几乎全部工程投入都落在它周围：上下文窗口里放什么、拿回来的东西怎么处理、响应错误时系统怎么办，以及这一切又是如何被知道的。
难度集中在度量上。做一个演示很快，因为一组精心挑选的输入几乎能让任何配置看起来都很称职。而要证明第二个版本比第一个更好就难得多：两条回答可以措辞完全不同却同样正确，也可以几乎一模一样却在唯一要紧的那个事实上分道扬镳。回归集、评分细则、以人工标注校准过的自动评判，以及把检索与生成分开打分，都是常规手段；没有这些的团队，是靠印象在发布。
这里的失败方式与传统软件不同。断言凭空出现，在任何资料里都找不到依据。检索返回读起来相关、实际却不相关的段落。指令藏在用户提供的内容里抵达模型。厂商在服务端做了一次改动，没有报错也没有告警，质量却开始漂移。成本随对话长度增长，而这在压力测试里不会显现。这些要么被提前设计进去，要么被客户发现。
团队在什么情况下需要这项能力
基于基础模型的功能，通常起步于某人用一个周末拼出来的东西，而那个周末版本确实令人印象深刻。从它到客户可以依赖的产品之间的这段距离，正是这一角色的价值所在。
原型必须变成产品
演示能处理它被构建时针对的那些输入，其余的一律退化。要让它可靠，就要界定输入的边界、决定越界之后怎么办，并给质量一个即使有人反对也站得住的数字。
答案必须以自家资料为依据
响应需要来自内部文档、工单、合同或产品数据，而不是模型在训练中吸收的任何东西。这就带来切分策略、嵌入模型选择、混合检索、重排、时效性，以及一条硬性要求：用户永远不能检索到自己无权阅读的文档。
没有人说得清系统在不在变好
改动之所以发布，是因为在几次手工检查里“感觉更好了”。这是生产环境中基于基础模型的功能最常见的状态，它让此后每一个决定都变成猜测，包括这个功能是否还值得留着。
不可信的文本正在抵达模型
上传的文件、收到的邮件、客户消息、抓取的网页。一旦被检索到的内容可能携带指令，问题就不再是“模型被要求做什么”，而是“模型被允许做什么”。
开销的增长快于使用量
重试、越滚越长的对话历史、过大的上下文、没有缓存，以及每一个请求都被路由到可用的最大模型。概率性功能的成本曲线，并不是团队习惯预测的那一种。
你所依赖的模型版本被厂商下线了
一个行为从未被任何文档规定过的组件，迎来了迁移截止日期。没有回归测试集，唯一能知道新版本改变了什么的办法，就是把它发布出去。
核心能力
检索设计
切分边界、嵌入模型选择、词法与向量的混合检索、重排，以及元数据过滤。多数以“模型答错了”开头的反馈，其实是检索失败，而把两者分开正是诊断的第一步。
答案落地与出处
让一条回答可以追溯到支撑它的那些段落，并设计好“没有任何段落能支撑它”时的行为。在多数商业场景里，一个拒答的系统比一个即兴发挥的系统更有价值，而这种行为必须被构建出来，不是靠指令请求出来的。
上下文构造
决定有限的窗口里放什么：指令、检索到的证据、对话历史、工具结果、输出结构。给指令措辞是看得见的那部分；给窗口做预算分配和排序，才是实质的那部分。
评测体系
反映真实输入的精选样本集、换一个人来打分也能得到同样结果的评分细则、以人工标注校验过的自动评判，以及一次挡在“改提示”与“发版”之间的回归运行。
工具调用与编排
函数调用、多步循环、终止条件、重试行为，以及任何具有外部副作用的步骤上的幂等。停不下来的循环和会重复执行的动作，是这里的典型缺陷。
护栏与抗滥用
把模型输出当作不可信输入，在它抵达任何有后果的地方之前先按结构校验，并且限制模型能够触达哪些工具，而不是指望模型自己拒绝。
延迟与成本控制
流式输出、缓存、把简单请求路由到更小的模型、精简上下文，以及按“每完成一次任务的成本”而不是“每次调用的成本”来核算——后一个数字才跟账单对得上。
结构化输出
受结构约束的生成、校验、失败后的修复，以及在边界处做确定性解析，这样下游代码就永远不必去理解一段今天这样、明天可能那样解读的散文。
上线后的监控
包含被检索上下文在内的完整链路记录、按计划进行的人工抽样复核、针对质量变动而不仅仅是错误的告警，以及一条把用户上报的失败案例带回评测集的通路。
边界处的数据处理
清楚知道什么数据离开了自有环境、厂商会保留什么、发送前脱敏了什么，以及在多个客户共用的索引里如何强制租户隔离。
技术生态
以下列出的是 AI 工程领域的常用技术。这描述的是该学科在业界的普遍实践，并非对某位工程师技能的说明。这个方向的框架大约每年就会换一批，因此候选人如何推理检索、上下文与度量，比他最近一个项目里用了哪一个框架，是好得多的信号。
语言与运行时
- Python
- TypeScript
- Go
模型访问与托管
- OpenAI API
- Anthropic API
- Google Vertex AI
- Amazon Bedrock
- vLLM
- Ollama
编排框架
- LangChain
- LlamaIndex
- Semantic Kernel
- Haystack
- DSPy
检索与搜索
- pgvector
- Pinecone
- Qdrant
- Weaviate
- Elasticsearch
- OpenSearch
评测与链路追踪
- Ragas
- DeepEval
- promptfoo
- LangSmith
- Langfuse
- OpenTelemetry
校验与护栏
- Pydantic
- Instructor
- Guardrails AI
- NeMo Guardrails
- JSON Schema
应用层
- FastAPI
- Next.js
- Vercel AI SDK
- Redis
- Celery
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
评估候选人时应当考察什么
基础模型方向很容易吸引到讲得很流利的人。词汇是公开的，演示做起来很快，一个人可以谈检索和智能体谈得头头是道，却从未运维过一个“错误答案会送到付费客户面前”的系统。评测是最快把这两类人分开的办法，因为那是唯一背不出来的部分。
评测纪律
这里能用的、信息量最大的一条追问线，是他们如何知道某次改动带来了帮助。要问数据集、样本从哪来、有多少条、谁来打分、依据什么细则。这里含糊，通常不是表达能力的问题，而是那套度量本来就不存在。
- 在动手改之前就建好了评测集，而不是等有人投诉之后
- 能说明自动评判是如何与人工评分做过校验的
- 把检索与生成分开打分，而不是揉成一个数字
- 任何提示或模型版本上线前都会跑一遍回归集
检索质量
问他们是怎么确认“正确的证据确实被找到了”。调试过这类系统的工程师，会先去看被检索到的段落，再去看指令；只做过演示的人，会先改指令，然后不停地改下去。
- 会度量正确的来源是否出现在返回结果中
- 基于证据而不是直觉去调整切分或加入重排
- 在检索阶段就执行访问权限，而不是在响应阶段
- 能举出一个“检索根本就是错误架构”的案例
答案落地与如实失败
系统在缺乏证据时的行为，比它在证据齐全时的行为更能说明问题。在几乎所有商业场景里，一个自信的编造都比一次拒答更糟，而候选人在是否内化了这一点上差别极大。
- 为“信息不足以回答”设计了明确的处理路径
- 引用能定位到真正支撑该论断的段落
- 度量过答案的落地程度，而不是口头保证
- 把“无依据但听起来合理”的回答当作值得开事故单的缺陷
对抗性思维
任何会读取非自身撰写内容的系统，都存在注入面。弱的回答是写一段更长的指令，告诉模型忽略它遇到的指令。强的回答是限制模型能做什么，让说服本身对攻击者毫无收益。
- 默认把检索到的和用户提供的文本视为有敌意
- 把只读能力与任何具有外部副作用的能力分开
- 在输出抵达工具、查询或邮箱之前先做校验
- 不把指令措辞当作一项安全控制
真实流量下的延迟与成本
问他们这个功能每完成一次任务的成本是多少，以及包含检索和重排在内的九十五分位响应时间是什么水平。在生产环境跑过东西的候选人，两个数字都能给出大致值；没跑过的人，倾向于报一个每 token 的单价。
- 按“每次成功产出的成本”而不是“每次调用的成本”推理
- 把流程中的一部分路由到更小的模型或缓存路径
- 度量端到端延迟，而不只是首个 token 的时间
- 降低过开销，并且证明了质量没有下滑
上线之后的监控
有意思的问题是：他们是如何得知一个自己没有预料到的问题的。要找的是按计划进行的人工抽样复核、能记录实际发送上下文的链路追踪，以及一次“厂商侧改动改变了行为却什么都没报错”的经历。
- 记录完整发送的上下文，而不只是最终响应
- 按固定节奏抽样复核线上输出
- 抓到过一次没有产生任何报错的质量回归
- 把上报的失败案例回流进评测集
对“模型该出现在哪里”的克制
扎实的候选人删掉模型调用的次数，不会少于他们加上去的次数。问他们在哪里得出结论：规则、分类器或普通代码才是更合适的工具，以及决定性因素是什么。
- 曾把一个生成步骤换成确定性代码
- 能说出一个因“出错代价太高”而被否决的任务
- 在足够用的场景下会考虑更小的专用模型
- 在提出架构之前，先问输出会喂给哪一个决策
值得一问的面试问题
请按适合您自己招聘对话的方式使用它们。评估由您做出，结论也由您得出；下面只是指出在这门学科里有价值的回答通常出现在哪里——出现在真正把这类系统持续跑起来的人身上，而不是读过很多相关材料的人身上。
你怎么知道上一次改动让系统变好了？
What a strong answer shows
这门学科里预测力最强的一个问题。要听数据集的来源、规模、评分细则、由谁执行，以及这个结果有没有让他们放弃过一个自己很喜欢的改动。
客户反馈了一条自信但错误的回答。按顺序讲讲你的诊断过程。
What a strong answer shows
他们是否会拆解整条链路。扎实的回答会先调出链路记录、检查被检索到的内容，再去动指令，然后判断证据究竟是不存在、存在但没被检索到、检索到了却被忽略，还是检索到了但被读错了。
你的产品会摄入用户上传的文档。其中一份里写着一段对模型说的话。会发生什么？
What a strong answer shows
注入意识，更重要的是他们的防线究竟是一道能力边界，还是一句更有说服力的指令。面对愿意反复尝试的攻击者，只有前者站得住。
检索返回的段落看起来是相关的，答案却仍然是错的。你会往哪里查？
What a strong answer shows
超出默认配置的深度。预期能听到：切分边界把答案劈开、语义相似但缺少词法重合、缺少重排、文档已过期，或者语料里根本就没有这个答案。
上线后使用量翻倍，开销却涨到三倍。你怎么排查？
What a strong answer shows
成本素养。要看不断累积的对话历史、静默的重试、随每次发布而变长的上下文、没有上限的工具循环，以及一套按任务而不是按 token 记账的模型。
你依赖的模型版本即将下线。你的迁移方案是什么？
What a strong answer shows
回归测试集是否存在。有把握的回答会把新版本跑在一个留出的样本集上、按类别比较分数，并在任何流量切换之前先找出哪些指令对这次变化敏感。
你在什么时候告诉过业务方：语言模型并不是这里合适的工具？
What a strong answer shows
判断力与独立性。扎实的回答会举出一个具体任务，说明是失败代价、延迟预算、可审计性要求还是单纯的确定性，让传统方案成为正确选择。
所有内容看起来都相关，而窗口是有限的。你怎么决定放什么进去？
What a strong answer shows
上下文是否被当作一份带分配策略的预算。要看顺序效应、历史压缩、“试过放更多上下文但并不总是更好”的证据，以及当前这套分配比例有度量依据。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某个产品团队已经上线了一个基于公司文档回答问题的助手。它在演示中表现良好，在真实客户材料上却时好时坏，客服开始转发错误答案过来，而团队里没有人能说清上个阶段的改动到底是帮了忙还是帮了倒忙，因为什么都没有被度量。
- Approach
- 追加的工程能力融入团队已有的工作方式：他们的仓库约定、他们的代码评审、他们的发布流程，以及他们已经确定的架构方向。产品决策和技术决定权仍属于内部工程师，追加的能力在同一个冲刺内承接评测、检索与监控方面的工作。
- What this adds to the team
- 团队获得交付能力，同时保留对产品与其架构的所有权。这个助手应当做什么、发布前必须达到什么标准，仍然由对它负责的人来决定。
Related disciplines
Frequently asked questions
- AI 工程师和机器学习工程师有什么区别？
- AI 工程师围绕别处产出的模型做构建；机器学习工程师则产出并维护模型本身。前者的时间花在检索、上下文、评测、护栏和线上产品的行为上；后者花在特征、训练流水线、服务基础设施、漂移与重训上。要集成厂商基础模型的团队需要前者；竞争位置取决于用自有数据训练出的模型的团队需要后者。
- AI 工程师需要训练模型吗？
- 通常不需要。微调偶尔会出现，多数是为了修正输出格式或语气，而不是为了增加知识，而且往往是在检索和上下文设计都用尽之后才会考虑。如果真实需求是一个用自有数据训练出来的模型，那是另一门学科、另一套工具，用这个头衔去找人只会造成双方都不愉快的错配。
- 提示工程算是一个独立岗位吗？
- 作为独立岗位，它很少能在生产环境中存活下来。指令措辞只是众多产物之一，与检索、上下文组装、评测、护栏、监控和成本控制并列，而且它恰恰是其中最容易在别的环节被认真修好之后被重写的那一个。整套实践只有措辞的人，会在问题变成架构问题的那一刻遇到瓶颈。
- 为什么评测对这个角色如此重要？
- 因为没有它，就无法把“改善”和“改变”区分开。传统软件给你一个通过或失败的测试；一个概率性组件只给你一个不同的回答，而“不同”不是方向。没有评测体系的团队会不断累积没人能论证的调整，最终连“这个功能比半年前更好吗”都答不上来。
- 后端工程师能转到这个方向吗？
- 经常可以，而且这是成功率较高的转型之一。可迁移的部分很大：API 设计、延迟预算、缓存、队列、可观测性和故障处理，构成了系统的大部分。需要新学的，是对一个不可复现的依赖的真正容忍度，以及用统计方式度量行为、而不是用一个测试去断言它的习惯。
- 上下文窗口已经很大了，检索还有必要吗？
- 对多数产品来说，有必要。窗口大并不能回答是哪份文档支撑了某个论断，不能约束谁可以看到什么，也不能阻止成本和延迟随你决定塞进去的所有内容一起增长。检索仍然是出处、权限与经济性的实现机制，而这些要求不会随窗口变大而消失。
- AI 工程师如何与现有的工程团队协作？
- 在技术团队扩展的安排下，方向由您决定：您的架构、您的代码评审、您的发布标准，以及这个冲刺被指向了什么。日常的开发优先级和技术决策由您的团队掌握，日常的技术协作对象是您自己的工程师。Talent.ID 承担雇佣一侧——薪资发放、员工福利、人才管理，以及持续的雇佣关系。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.