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
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某个产品团队已经上线了一个基于公司文档回答问题的助手。它在演示中表现良好，在真实客户材料上却时好时坏，客服开始转发错误答案过来，而团队里没有人能说清上个阶段的改动到底是帮了忙还是帮了倒忙，因为什么都没有被度量。
- 做法
- 追加的工程能力融入团队已有的工作方式：他们的仓库约定、他们的代码评审、他们的发布流程，以及他们已经确定的架构方向。产品决策和技术决定权仍属于内部工程师，追加的能力在同一个冲刺内承接评测、检索与监控方面的工作。
- 为团队带来什么
- 团队获得交付能力，同时保留对产品与其架构的所有权。这个助手应当做什么、发布前必须达到什么标准，仍然由对它负责的人来决定。
常见问题
- AI 工程师和机器学习工程师有什么区别？
- AI 工程师围绕别处产出的模型做构建；机器学习工程师则产出并维护模型本身。前者的时间花在检索、上下文、评测、护栏和线上产品的行为上；后者花在特征、训练流水线、服务基础设施、漂移与重训上。要集成厂商基础模型的团队需要前者；竞争位置取决于用自有数据训练出的模型的团队需要后者。
- AI 工程师需要训练模型吗？
- 通常不需要。微调偶尔会出现，多数是为了修正输出格式或语气，而不是为了增加知识，而且往往是在检索和上下文设计都用尽之后才会考虑。如果真实需求是一个用自有数据训练出来的模型，那是另一门学科、另一套工具，用这个头衔去找人只会造成双方都不愉快的错配。
- 提示工程算是一个独立岗位吗？
- 作为独立岗位，它很少能在生产环境中存活下来。指令措辞只是众多产物之一，与检索、上下文组装、评测、护栏、监控和成本控制并列，而且它恰恰是其中最容易在别的环节被认真修好之后被重写的那一个。整套实践只有措辞的人，会在问题变成架构问题的那一刻遇到瓶颈。
- 为什么评测对这个角色如此重要？
- 因为没有它，就无法把“改善”和“改变”区分开。传统软件给你一个通过或失败的测试；一个概率性组件只给你一个不同的回答，而“不同”不是方向。没有评测体系的团队会不断累积没人能论证的调整，最终连“这个功能比半年前更好吗”都答不上来。
- 后端工程师能转到这个方向吗？
- 经常可以，而且这是成功率较高的转型之一。可迁移的部分很大：API 设计、延迟预算、缓存、队列、可观测性和故障处理，构成了系统的大部分。需要新学的，是对一个不可复现的依赖的真正容忍度，以及用统计方式度量行为、而不是用一个测试去断言它的习惯。
- 上下文窗口已经很大了，检索还有必要吗？
- 对多数产品来说，有必要。窗口大并不能回答是哪份文档支撑了某个论断，不能约束谁可以看到什么，也不能阻止成本和延迟随你决定塞进去的所有内容一起增长。检索仍然是出处、权限与经济性的实现机制，而这些要求不会随窗口变大而消失。
- AI 工程师如何与现有的工程团队协作？
- 在技术团队扩展的安排下，方向由您决定：您的架构、您的代码评审、您的发布标准，以及这个冲刺被指向了什么。日常的开发优先级和技术决策由您的团队掌握，日常的技术协作对象是您自己的工程师。Talent.ID 承担雇佣一侧——薪资发放、员工福利、人才管理，以及持续的雇佣关系。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。