1. 从零搭建AI工程体系为什么我劝你别一上来就啃论文这两年AI工程这个词被炒得火热打开任何一个技术社区满屏都是大模型微调、RAG、Agent、向量数据库这些词。很多刚入行的朋友第一反应就是去搜论文、看开源框架文档结果啃了两周Transformer的注意力机制公式回头发现自己连一个能跑通的推理服务都搭不起来。我自己带过好几个从算法岗转AI工程岗的同事也见过不少应届生在这个阶段卡住核心问题其实不在数学功底而在于没有建立起一套完整的工程视角。所谓ai-engineering-from-scratch说白了就是从零开始把AI能力真正落地成一个可运行、可维护、可扩展的工程系统而不是停留在notebook里跑通一个demo。它解决的是模型能跑到系统能用之间那段最脏最累的活数据怎么流转、推理怎么服务化、显存怎么管、延迟怎么压、版本怎么控、成本怎么算。这套东西适合谁适合有一定编程基础、想往AI工程方向转的开发者也适合已经在做AI应用但总觉得系统脆、一改就崩的工程师。你不需要先把深度学习理论啃透但你需要对HTTP服务、数据库、容器这些基础工程概念不陌生。我写这篇东西的出发点很简单把我自己从零搭一套AI工程体系时踩过的坑、做过的取舍、验证过的方案原原本本讲一遍。不堆公式不吹框架就讲怎么让一个AI系统真正跑起来、扛得住、改得动。2. 整体架构设计先想清楚数据怎么流再想模型怎么放2.1 为什么我坚持先画数据流再选模型很多人做AI项目的第一反应是我要用哪个模型这其实是个危险的起点。模型是会换的今天用这个开源模型明天可能换成另一个但数据流一旦设计歪了换模型的时候你会想死。我自己的习惯是任何AI工程项目启动前先在一张白纸上画清楚三件事数据从哪来、经过哪些处理、最终以什么形式被消费。举个具体的例子。假设你要做一个文档问答系统数据流大致是原始文档上传 → 解析抽取文本 → 切块 → 向量化 → 存入向量库 → 用户提问 → 问题向量化 → 检索 → 拼装上下文 → 调用模型 → 返回答案。这条链路里模型只是其中一环真正决定系统好不好用的是切块策略、检索质量、上下文拼装这些脏活。如果你一上来就纠结用哪个embedding模型很可能切块策略没设计好再好的模型也救不回来。从工程角度看先定数据流有三个好处。第一它让你明确每个环节的输入输出契约后面换任何组件都只影响局部。第二它帮你识别真正的瓶颈在哪很多时候瓶颈不在模型推理而在IO或者检索。第三它让团队协作有共同语言前后端、算法、运维能对着同一张图讨论而不是各说各话。2.2 分层架构把会变的和不变的隔离开我习惯把AI工程系统分成四层接入层、编排层、能力层、基础设施层。这个分法不是教科书标准是我自己用下来最顺手的。接入层负责和外界打交道处理请求鉴权、限流、协议转换。这一层要尽量薄不要塞业务逻辑因为它是系统对外的门面改动风险最高。编排层是核心负责把一次请求拆解成多个步骤决定调用哪些能力、按什么顺序、失败了怎么重试。能力层就是各种具体能力比如文本向量化、模型推理、检索、重排。基础设施层是向量库、缓存、消息队列、对象存储这些。这么分的关键逻辑是能力层是最容易变的今天用A模型明天用B模型所以它要被编排层通过稳定接口调用而不是被上层直接依赖。编排层相对稳定因为它描述的是业务流程。接入层和基础设施层基本不变。把变化隔离在能力层你的系统就能在换模型、换向量库的时候上层几乎不用动。提示分层不是目的隔离变化才是。如果你的项目很小一个人维护硬套四层反而累赘。但只要你预期系统会持续演进这个分层能帮你省下大量重构时间。2.3 技术选型的取舍逻辑选型这块我不给具体品牌推荐因为技术迭代太快给了也很快过时。我讲取舍的维度你自己套。第一个维度是可控性 vs 开发速度。用托管服务开发快但你没法控制底层行为出问题只能等对方修。自建可控但运维成本高。我的经验是核心链路自建边缘能力用托管。比如向量检索是核心自建或者用可私有部署的方案而一些辅助的文本清洗用现成服务就行。第二个维度是同步 vs 异步。模型推理往往慢如果整个请求链路全同步用户会等到怀疑人生。我的做法是能异步的都异步比如文档解析、批量向量化走消息队列只有用户直接等待的那一步才同步。第三个维度是有状态 vs 无状态。AI服务尽量做成无状态的会话状态外置到Redis或者数据库。这样扩容、重启、灰度都简单。我见过把对话历史存在服务内存里的系统一扩容就串话这种坑千万别踩。3. 核心环节实操从环境到第一个能跑的推理服务3.1 环境准备别小看这一步一半的坑在这从零搭环境我建议用容器别在宿主机上直接装一堆依赖。原因很简单AI相关的依赖版本冲突极其严重今天装个库把另一个库搞崩是家常便饭。用容器把环境固化下来至少保证我这能跑你那也能跑。基础镜像选择上我一般基于官方提供的深度学习镜像因为CUDA、cuDNN这些底层依赖自己配太痛苦。但要注意官方镜像往往很大几个G起步拉取和分发都慢。我的做法是分阶段构建把编译依赖和运行依赖分开最终镜像只保留运行时需要的东西能压到原来的一半甚至更小。Python依赖管理我强烈建议用锁文件把每个包的精确版本固定下来。AI生态里一个小版本升级导致行为变化太常见了不锁版本你今天跑通明天就崩。我自己的习惯是用依赖管理工具生成锁文件CI里严格按锁文件安装。注意GPU相关的依赖宿主机驱动版本和容器内CUDA版本必须匹配。我踩过一次坑宿主机驱动太老容器里CUDA版本太高结果容器启动就报错排查了半天才发现是驱动问题。装之前先用命令确认宿主机驱动支持的CUDA最高版本。3.2 模型加载与推理服务化把模型跑起来和把模型做成服务是两码事。跑起来只要几行代码做成服务要考虑并发、显存、超时、降级。先说模型加载。大模型加载慢动辄几十秒如果每次请求都加载系统没法用。所以模型要在服务启动时加载一次常驻显存。这里有个细节加载的时候要指定设备别让它默认往CPU上放。我见过有人模型加载到CPU上推理慢得像蜗牛还以为是模型问题。推理服务化我推荐用专门的推理框架而不是自己用Web框架裸写。推理框架帮你处理了动态批处理、显存管理、并发调度这些复杂问题。动态批处理特别重要它能把多个并发请求合并成一个批次推理吞吐量能提升好几倍。自己实现这套逻辑非常容易出bug用成熟框架省心。服务接口设计上我建议同步接口和异步接口都提供。同步接口给实时性要求高的场景设置合理超时超时就返回降级结果。异步接口给批量任务提交后返回任务ID客户端轮询或者回调拿结果。这样一套服务能覆盖两种需求。参数配置这块几个关键参数必须调最大批大小决定吞吐上限太大显存爆太小浪费算力最大序列长度决定能处理多长的输入设太大浪费显存设太小长文本被截断超时时间决定用户等多久设太长用户流失设太短正常请求被误杀。这些参数没有标准答案要根据你的硬件和业务实测。3.3 数据管道AI系统的隐形地基数据管道是AI工程里最不起眼但最重要的部分。模型再强喂进去的数据是脏的输出就是垃圾。我见过太多项目模型选型讨论了几周数据管道随便写写结果上线后各种诡异问题都出在数据上。数据管道一般分三步采集、清洗、切分。采集要考虑数据源多样性PDF、Word、HTML、Markdown格式各不相同解析库的选择很关键。有些解析库对复杂排版支持差表格、公式、多栏布局会解析乱。我的经验是先用几个代表性文档测试解析效果别等全量跑完才发现解析错了。清洗这步最容易被忽略。原始文本里往往有大量噪声页眉页脚、乱码、重复段落、无意义符号。这些噪声会严重影响检索和生成质量。清洗规则要针对你的数据源定制没有通用方案。我一般会先抽样看几十个文档把常见噪声列出来再写规则。切分是重头戏。文本太长模型处理不了太短语义不完整。切分策略直接影响检索质量。固定长度切分简单但会切断语义按段落切分语义完整但长度不均按语义切分效果好但实现复杂。我的做法是混合策略先按段落切段落太长再按句子切相邻块之间保留一定重叠避免关键信息正好落在边界上被切断。提示切分块的大小要和你用的embedding模型匹配。有些模型对输入长度有限制超过就被截断。切块前先确认模型的输入上限别切完了才发现超了。3.4 向量检索让系统真正懂你的数据向量检索是RAG类系统的核心。它的原理是把文本转成高维向量语义相近的文本向量距离近检索时找距离最近的几个。听起来简单实操坑很多。第一个坑是embedding模型的选择。不同模型在不同语言、不同领域上表现差异很大。通用模型在专业领域可能表现很差。我的建议是如果你的数据是特定领域先用领域数据测试几个候选模型看检索准确率别盲目用排行榜第一的。第二个坑是向量维度和索引类型。维度越高表达力越强但存储和计算成本越高。索引类型影响检索速度和召回率有的索引快但召回低有的召回高但慢。这个要根据数据量和延迟要求权衡。数据量小的时候暴力检索就行别过早优化。第三个坑是检索结果的多样性。纯按相似度检索可能返回一堆内容重复的块浪费上下文窗口。我一般会加去重和多样性控制比如同一文档最多返回N个块或者用MMR算法平衡相关性和多样性。3.5 上下文拼装与提示词工程检索出来的内容怎么拼进提示词直接决定生成质量。这块没有银弹但有几条经验。上下文不是越多越好。模型上下文窗口有限塞太多反而稀释关键信息还增加推理成本。我一般会控制检索块数量比如3到5块每块控制在几百字。如果检索质量高少而精比多而杂好。拼装顺序也有讲究。相关度高的放前面还是后面不同模型表现不同。有的模型对开头和结尾的内容更敏感重要的信息放这两端。这个要实测。提示词要明确告诉模型怎么用上下文。比如仅根据以下资料回答资料中没有的信息不要编造这句话能大幅降低幻觉。但也要注意提示词太长会占用上下文要精简。注意提示词里的上下文和用户问题之间要有清晰分隔避免模型把资料和问题混淆。我一般用明确的分隔标记让模型清楚哪部分是资料哪部分是问题。4. 性能与成本让系统跑得快还花得少4.1 延迟优化用户等不了那么久AI系统的延迟主要花在模型推理上但推理之外的环节也不能忽视。我一般会先做延迟分解把一次请求的耗时拆到每个环节找出真正的瓶颈。很多时候你以为瓶颈在推理一测发现是检索或者网络。推理延迟优化几个方向。一是量化把模型权重从高精度降到低精度速度能提升不少精度损失通常可接受。二是蒸馏用大模型教小模型小模型推理快。三是缓存相同或相似的请求直接返回缓存结果。缓存这块要注意语义相似的请求用向量相似度匹配别用精确匹配否则命中率极低。检索延迟优化主要是索引和缓存。索引选合适的类型热数据放内存。检索结果也可以缓存相同查询直接返回。网络延迟优化服务部署要离用户近内部服务调用尽量走内网减少序列化开销。4.2 成本控制算力是钱别浪费AI系统的成本大头是GPU。控制成本的核心是提高GPU利用率。动态批处理是提高利用率最有效的手段把零散请求攒成批GPU就不空转。但批大小要调好太大延迟高太小利用率低。模型选择上不是越大越好。很多任务小模型够用成本却低一个数量级。我的做法是先用小模型效果不达标再换大的。有些场景可以用模型级联简单请求小模型处理复杂请求才走大模型。缓存也是省钱利器。相同问题重复问直接返回缓存不消耗算力。缓存命中率哪怕只有百分之二三十成本也能降不少。还有一点容易被忽略闲置资源回收。很多系统为了应对峰值常驻大量GPU但峰值一天可能就几小时其余时间资源闲置。用弹性伸缩峰值扩容低谷缩容能省不少钱。4.3 监控与可观测性出问题能快速定位AI系统的监控比传统系统复杂因为多了模型相关的指标。我一般监控三类指标系统指标、业务指标、模型指标。系统指标就是CPU、内存、GPU利用率、显存占用、网络IO这些用常规监控工具就行。业务指标是请求量、成功率、延迟分布、错误率这些反映系统健康度。模型指标是AI系统特有的比如推理延迟、批大小分布、缓存命中率、检索召回率、生成质量评分。日志要记全尤其是请求的输入输出。AI系统出问题往往和具体输入有关没有输入输出日志根本没法排查。但要注意隐私敏感信息要脱敏。链路追踪对AI系统特别有用因为一次请求经过多个环节哪个环节慢、哪个环节出错追踪图上一目了然。5. 常见问题与排查实录5.1 模型相关的高频问题问题一模型输出不稳定同样的问题答案不一样。这通常是采样参数导致的。温度参数控制随机性温度高输出多样但可能跑偏温度低输出稳定但可能死板。生产环境一般用较低温度。另外如果用了top-k或top-p采样也会引入随机性。要完全确定用贪心解码。问题二模型幻觉严重编造不存在的信息。幻觉是生成模型的固有特性只能缓解不能根除。缓解手段包括提示词明确要求基于给定资料回答、降低温度、检索增强、输出后校验。输出后校验可以用规则或者另一个模型检查但会增加延迟和成本。问题三长文本处理效果差。模型对长文本的处理能力有限中间部分容易被忽略。解决办法是分段处理再汇总或者用支持长上下文的模型。但长上下文模型成本高要权衡。5.2 工程相关的高频问题问题一服务启动慢。通常是模型加载慢。可以预热服务启动后先跑几个请求把模型加载到显存。也可以用模型缓存把加载好的模型状态保存下来启动时直接恢复。问题二并发一高就崩。检查是不是没有做限流和队列。AI服务处理能力有限超过就排队或者拒绝别硬扛。另外检查显存是不是爆了动态批处理没配好容易爆显存。问题三换模型后效果变差。换模型不是换个权重文件那么简单提示词、参数、后处理可能都要调。新模型的输入格式、输出格式、对提示词的敏感度都可能不同。换模型要重新测试整条链路。5.3 排查速查表现象可能原因排查方向推理特别慢模型在CPU上、没用量化、批处理没开检查设备、量化配置、批处理参数显存溢出批太大、序列太长、模型太大调小批和序列长度、换小模型、用量化检索结果不相关embedding模型不匹配、切块策略差换模型、调切块、加重排输出答非所问提示词不清、上下文拼装乱优化提示词、检查上下文格式服务频繁重启内存泄漏、OOM、健康检查太严查日志、调资源限制、放宽健康检查成本居高不下利用率低、缓存命中低、模型过大开批处理、优化缓存、换小模型提示排查AI系统问题第一步永远是看日志里的输入输出。很多问题看一眼实际输入就明白了比瞎猜快得多。6. 我踩过的几个印象深刻的坑第一个坑是切块重叠设太小。当时为了省存储块之间几乎不重叠结果关键信息正好落在两块边界上检索时两块都只包含半句话模型拿到残缺信息回答质量很差。后来把重叠调到块大小的百分之十到二十问题解决。这个参数看着小影响很大。第二个坑是缓存用精确匹配。上线后发现缓存命中率极低因为用户问法稍有不同就匹配不上。改成向量相似度匹配后命中率上来了但要注意设相似度阈值太低会返回不相关缓存。第三个坑是没做降级。有次模型服务挂了整个系统全挂用户什么都拿不到。后来加了降级策略模型不可用时返回检索到的原文至少用户能拿到相关信息。降级方案不一定要多好有比没有强太多。第四个坑是版本管理混乱。模型、提示词、切块策略都改过但没记录版本出问题回滚都不知道回滚到哪。后来把所有配置纳入版本控制每次变更记录清楚排查效率高了很多。7. 后续可以怎么扩展这套从零搭起来的框架往上可以长很多东西。比如加评测体系用标注数据定期评估检索和生成质量量化每次改动的效果。比如加反馈闭环收集用户对回答的评价用来优化检索和提示词。比如加多模型路由根据问题类型自动选合适的模型简单问题小模型复杂问题大模型。比如加Agent能力让系统能调用外部工具处理需要多步推理的任务。我个人在实际操作中的体会是AI工程最难的不是某个技术点而是把一堆不完美的组件拼成一个能用的系统并且在持续变化中保持稳定。模型会换框架会换但数据流设计、分层隔离、监控排查这些工程基本功不会过时。把基本功打扎实换什么新东西都能快速上手。
从零搭建AI工程体系：数据流设计与推理服务化实战
1. 从零搭建AI工程体系为什么我劝你别一上来就啃论文这两年AI工程这个词被炒得火热打开任何一个技术社区满屏都是大模型微调、RAG、Agent、向量数据库这些词。很多刚入行的朋友第一反应就是去搜论文、看开源框架文档结果啃了两周Transformer的注意力机制公式回头发现自己连一个能跑通的推理服务都搭不起来。我自己带过好几个从算法岗转AI工程岗的同事也见过不少应届生在这个阶段卡住核心问题其实不在数学功底而在于没有建立起一套完整的工程视角。所谓ai-engineering-from-scratch说白了就是从零开始把AI能力真正落地成一个可运行、可维护、可扩展的工程系统而不是停留在notebook里跑通一个demo。它解决的是模型能跑到系统能用之间那段最脏最累的活数据怎么流转、推理怎么服务化、显存怎么管、延迟怎么压、版本怎么控、成本怎么算。这套东西适合谁适合有一定编程基础、想往AI工程方向转的开发者也适合已经在做AI应用但总觉得系统脆、一改就崩的工程师。你不需要先把深度学习理论啃透但你需要对HTTP服务、数据库、容器这些基础工程概念不陌生。我写这篇东西的出发点很简单把我自己从零搭一套AI工程体系时踩过的坑、做过的取舍、验证过的方案原原本本讲一遍。不堆公式不吹框架就讲怎么让一个AI系统真正跑起来、扛得住、改得动。2. 整体架构设计先想清楚数据怎么流再想模型怎么放2.1 为什么我坚持先画数据流再选模型很多人做AI项目的第一反应是我要用哪个模型这其实是个危险的起点。模型是会换的今天用这个开源模型明天可能换成另一个但数据流一旦设计歪了换模型的时候你会想死。我自己的习惯是任何AI工程项目启动前先在一张白纸上画清楚三件事数据从哪来、经过哪些处理、最终以什么形式被消费。举个具体的例子。假设你要做一个文档问答系统数据流大致是原始文档上传 → 解析抽取文本 → 切块 → 向量化 → 存入向量库 → 用户提问 → 问题向量化 → 检索 → 拼装上下文 → 调用模型 → 返回答案。这条链路里模型只是其中一环真正决定系统好不好用的是切块策略、检索质量、上下文拼装这些脏活。如果你一上来就纠结用哪个embedding模型很可能切块策略没设计好再好的模型也救不回来。从工程角度看先定数据流有三个好处。第一它让你明确每个环节的输入输出契约后面换任何组件都只影响局部。第二它帮你识别真正的瓶颈在哪很多时候瓶颈不在模型推理而在IO或者检索。第三它让团队协作有共同语言前后端、算法、运维能对着同一张图讨论而不是各说各话。2.2 分层架构把会变的和不变的隔离开我习惯把AI工程系统分成四层接入层、编排层、能力层、基础设施层。这个分法不是教科书标准是我自己用下来最顺手的。接入层负责和外界打交道处理请求鉴权、限流、协议转换。这一层要尽量薄不要塞业务逻辑因为它是系统对外的门面改动风险最高。编排层是核心负责把一次请求拆解成多个步骤决定调用哪些能力、按什么顺序、失败了怎么重试。能力层就是各种具体能力比如文本向量化、模型推理、检索、重排。基础设施层是向量库、缓存、消息队列、对象存储这些。这么分的关键逻辑是能力层是最容易变的今天用A模型明天用B模型所以它要被编排层通过稳定接口调用而不是被上层直接依赖。编排层相对稳定因为它描述的是业务流程。接入层和基础设施层基本不变。把变化隔离在能力层你的系统就能在换模型、换向量库的时候上层几乎不用动。提示分层不是目的隔离变化才是。如果你的项目很小一个人维护硬套四层反而累赘。但只要你预期系统会持续演进这个分层能帮你省下大量重构时间。2.3 技术选型的取舍逻辑选型这块我不给具体品牌推荐因为技术迭代太快给了也很快过时。我讲取舍的维度你自己套。第一个维度是可控性 vs 开发速度。用托管服务开发快但你没法控制底层行为出问题只能等对方修。自建可控但运维成本高。我的经验是核心链路自建边缘能力用托管。比如向量检索是核心自建或者用可私有部署的方案而一些辅助的文本清洗用现成服务就行。第二个维度是同步 vs 异步。模型推理往往慢如果整个请求链路全同步用户会等到怀疑人生。我的做法是能异步的都异步比如文档解析、批量向量化走消息队列只有用户直接等待的那一步才同步。第三个维度是有状态 vs 无状态。AI服务尽量做成无状态的会话状态外置到Redis或者数据库。这样扩容、重启、灰度都简单。我见过把对话历史存在服务内存里的系统一扩容就串话这种坑千万别踩。3. 核心环节实操从环境到第一个能跑的推理服务3.1 环境准备别小看这一步一半的坑在这从零搭环境我建议用容器别在宿主机上直接装一堆依赖。原因很简单AI相关的依赖版本冲突极其严重今天装个库把另一个库搞崩是家常便饭。用容器把环境固化下来至少保证我这能跑你那也能跑。基础镜像选择上我一般基于官方提供的深度学习镜像因为CUDA、cuDNN这些底层依赖自己配太痛苦。但要注意官方镜像往往很大几个G起步拉取和分发都慢。我的做法是分阶段构建把编译依赖和运行依赖分开最终镜像只保留运行时需要的东西能压到原来的一半甚至更小。Python依赖管理我强烈建议用锁文件把每个包的精确版本固定下来。AI生态里一个小版本升级导致行为变化太常见了不锁版本你今天跑通明天就崩。我自己的习惯是用依赖管理工具生成锁文件CI里严格按锁文件安装。注意GPU相关的依赖宿主机驱动版本和容器内CUDA版本必须匹配。我踩过一次坑宿主机驱动太老容器里CUDA版本太高结果容器启动就报错排查了半天才发现是驱动问题。装之前先用命令确认宿主机驱动支持的CUDA最高版本。3.2 模型加载与推理服务化把模型跑起来和把模型做成服务是两码事。跑起来只要几行代码做成服务要考虑并发、显存、超时、降级。先说模型加载。大模型加载慢动辄几十秒如果每次请求都加载系统没法用。所以模型要在服务启动时加载一次常驻显存。这里有个细节加载的时候要指定设备别让它默认往CPU上放。我见过有人模型加载到CPU上推理慢得像蜗牛还以为是模型问题。推理服务化我推荐用专门的推理框架而不是自己用Web框架裸写。推理框架帮你处理了动态批处理、显存管理、并发调度这些复杂问题。动态批处理特别重要它能把多个并发请求合并成一个批次推理吞吐量能提升好几倍。自己实现这套逻辑非常容易出bug用成熟框架省心。服务接口设计上我建议同步接口和异步接口都提供。同步接口给实时性要求高的场景设置合理超时超时就返回降级结果。异步接口给批量任务提交后返回任务ID客户端轮询或者回调拿结果。这样一套服务能覆盖两种需求。参数配置这块几个关键参数必须调最大批大小决定吞吐上限太大显存爆太小浪费算力最大序列长度决定能处理多长的输入设太大浪费显存设太小长文本被截断超时时间决定用户等多久设太长用户流失设太短正常请求被误杀。这些参数没有标准答案要根据你的硬件和业务实测。3.3 数据管道AI系统的隐形地基数据管道是AI工程里最不起眼但最重要的部分。模型再强喂进去的数据是脏的输出就是垃圾。我见过太多项目模型选型讨论了几周数据管道随便写写结果上线后各种诡异问题都出在数据上。数据管道一般分三步采集、清洗、切分。采集要考虑数据源多样性PDF、Word、HTML、Markdown格式各不相同解析库的选择很关键。有些解析库对复杂排版支持差表格、公式、多栏布局会解析乱。我的经验是先用几个代表性文档测试解析效果别等全量跑完才发现解析错了。清洗这步最容易被忽略。原始文本里往往有大量噪声页眉页脚、乱码、重复段落、无意义符号。这些噪声会严重影响检索和生成质量。清洗规则要针对你的数据源定制没有通用方案。我一般会先抽样看几十个文档把常见噪声列出来再写规则。切分是重头戏。文本太长模型处理不了太短语义不完整。切分策略直接影响检索质量。固定长度切分简单但会切断语义按段落切分语义完整但长度不均按语义切分效果好但实现复杂。我的做法是混合策略先按段落切段落太长再按句子切相邻块之间保留一定重叠避免关键信息正好落在边界上被切断。提示切分块的大小要和你用的embedding模型匹配。有些模型对输入长度有限制超过就被截断。切块前先确认模型的输入上限别切完了才发现超了。3.4 向量检索让系统真正懂你的数据向量检索是RAG类系统的核心。它的原理是把文本转成高维向量语义相近的文本向量距离近检索时找距离最近的几个。听起来简单实操坑很多。第一个坑是embedding模型的选择。不同模型在不同语言、不同领域上表现差异很大。通用模型在专业领域可能表现很差。我的建议是如果你的数据是特定领域先用领域数据测试几个候选模型看检索准确率别盲目用排行榜第一的。第二个坑是向量维度和索引类型。维度越高表达力越强但存储和计算成本越高。索引类型影响检索速度和召回率有的索引快但召回低有的召回高但慢。这个要根据数据量和延迟要求权衡。数据量小的时候暴力检索就行别过早优化。第三个坑是检索结果的多样性。纯按相似度检索可能返回一堆内容重复的块浪费上下文窗口。我一般会加去重和多样性控制比如同一文档最多返回N个块或者用MMR算法平衡相关性和多样性。3.5 上下文拼装与提示词工程检索出来的内容怎么拼进提示词直接决定生成质量。这块没有银弹但有几条经验。上下文不是越多越好。模型上下文窗口有限塞太多反而稀释关键信息还增加推理成本。我一般会控制检索块数量比如3到5块每块控制在几百字。如果检索质量高少而精比多而杂好。拼装顺序也有讲究。相关度高的放前面还是后面不同模型表现不同。有的模型对开头和结尾的内容更敏感重要的信息放这两端。这个要实测。提示词要明确告诉模型怎么用上下文。比如仅根据以下资料回答资料中没有的信息不要编造这句话能大幅降低幻觉。但也要注意提示词太长会占用上下文要精简。注意提示词里的上下文和用户问题之间要有清晰分隔避免模型把资料和问题混淆。我一般用明确的分隔标记让模型清楚哪部分是资料哪部分是问题。4. 性能与成本让系统跑得快还花得少4.1 延迟优化用户等不了那么久AI系统的延迟主要花在模型推理上但推理之外的环节也不能忽视。我一般会先做延迟分解把一次请求的耗时拆到每个环节找出真正的瓶颈。很多时候你以为瓶颈在推理一测发现是检索或者网络。推理延迟优化几个方向。一是量化把模型权重从高精度降到低精度速度能提升不少精度损失通常可接受。二是蒸馏用大模型教小模型小模型推理快。三是缓存相同或相似的请求直接返回缓存结果。缓存这块要注意语义相似的请求用向量相似度匹配别用精确匹配否则命中率极低。检索延迟优化主要是索引和缓存。索引选合适的类型热数据放内存。检索结果也可以缓存相同查询直接返回。网络延迟优化服务部署要离用户近内部服务调用尽量走内网减少序列化开销。4.2 成本控制算力是钱别浪费AI系统的成本大头是GPU。控制成本的核心是提高GPU利用率。动态批处理是提高利用率最有效的手段把零散请求攒成批GPU就不空转。但批大小要调好太大延迟高太小利用率低。模型选择上不是越大越好。很多任务小模型够用成本却低一个数量级。我的做法是先用小模型效果不达标再换大的。有些场景可以用模型级联简单请求小模型处理复杂请求才走大模型。缓存也是省钱利器。相同问题重复问直接返回缓存不消耗算力。缓存命中率哪怕只有百分之二三十成本也能降不少。还有一点容易被忽略闲置资源回收。很多系统为了应对峰值常驻大量GPU但峰值一天可能就几小时其余时间资源闲置。用弹性伸缩峰值扩容低谷缩容能省不少钱。4.3 监控与可观测性出问题能快速定位AI系统的监控比传统系统复杂因为多了模型相关的指标。我一般监控三类指标系统指标、业务指标、模型指标。系统指标就是CPU、内存、GPU利用率、显存占用、网络IO这些用常规监控工具就行。业务指标是请求量、成功率、延迟分布、错误率这些反映系统健康度。模型指标是AI系统特有的比如推理延迟、批大小分布、缓存命中率、检索召回率、生成质量评分。日志要记全尤其是请求的输入输出。AI系统出问题往往和具体输入有关没有输入输出日志根本没法排查。但要注意隐私敏感信息要脱敏。链路追踪对AI系统特别有用因为一次请求经过多个环节哪个环节慢、哪个环节出错追踪图上一目了然。5. 常见问题与排查实录5.1 模型相关的高频问题问题一模型输出不稳定同样的问题答案不一样。这通常是采样参数导致的。温度参数控制随机性温度高输出多样但可能跑偏温度低输出稳定但可能死板。生产环境一般用较低温度。另外如果用了top-k或top-p采样也会引入随机性。要完全确定用贪心解码。问题二模型幻觉严重编造不存在的信息。幻觉是生成模型的固有特性只能缓解不能根除。缓解手段包括提示词明确要求基于给定资料回答、降低温度、检索增强、输出后校验。输出后校验可以用规则或者另一个模型检查但会增加延迟和成本。问题三长文本处理效果差。模型对长文本的处理能力有限中间部分容易被忽略。解决办法是分段处理再汇总或者用支持长上下文的模型。但长上下文模型成本高要权衡。5.2 工程相关的高频问题问题一服务启动慢。通常是模型加载慢。可以预热服务启动后先跑几个请求把模型加载到显存。也可以用模型缓存把加载好的模型状态保存下来启动时直接恢复。问题二并发一高就崩。检查是不是没有做限流和队列。AI服务处理能力有限超过就排队或者拒绝别硬扛。另外检查显存是不是爆了动态批处理没配好容易爆显存。问题三换模型后效果变差。换模型不是换个权重文件那么简单提示词、参数、后处理可能都要调。新模型的输入格式、输出格式、对提示词的敏感度都可能不同。换模型要重新测试整条链路。5.3 排查速查表现象可能原因排查方向推理特别慢模型在CPU上、没用量化、批处理没开检查设备、量化配置、批处理参数显存溢出批太大、序列太长、模型太大调小批和序列长度、换小模型、用量化检索结果不相关embedding模型不匹配、切块策略差换模型、调切块、加重排输出答非所问提示词不清、上下文拼装乱优化提示词、检查上下文格式服务频繁重启内存泄漏、OOM、健康检查太严查日志、调资源限制、放宽健康检查成本居高不下利用率低、缓存命中低、模型过大开批处理、优化缓存、换小模型提示排查AI系统问题第一步永远是看日志里的输入输出。很多问题看一眼实际输入就明白了比瞎猜快得多。6. 我踩过的几个印象深刻的坑第一个坑是切块重叠设太小。当时为了省存储块之间几乎不重叠结果关键信息正好落在两块边界上检索时两块都只包含半句话模型拿到残缺信息回答质量很差。后来把重叠调到块大小的百分之十到二十问题解决。这个参数看着小影响很大。第二个坑是缓存用精确匹配。上线后发现缓存命中率极低因为用户问法稍有不同就匹配不上。改成向量相似度匹配后命中率上来了但要注意设相似度阈值太低会返回不相关缓存。第三个坑是没做降级。有次模型服务挂了整个系统全挂用户什么都拿不到。后来加了降级策略模型不可用时返回检索到的原文至少用户能拿到相关信息。降级方案不一定要多好有比没有强太多。第四个坑是版本管理混乱。模型、提示词、切块策略都改过但没记录版本出问题回滚都不知道回滚到哪。后来把所有配置纳入版本控制每次变更记录清楚排查效率高了很多。7. 后续可以怎么扩展这套从零搭起来的框架往上可以长很多东西。比如加评测体系用标注数据定期评估检索和生成质量量化每次改动的效果。比如加反馈闭环收集用户对回答的评价用来优化检索和提示词。比如加多模型路由根据问题类型自动选合适的模型简单问题小模型复杂问题大模型。比如加Agent能力让系统能调用外部工具处理需要多步推理的任务。我个人在实际操作中的体会是AI工程最难的不是某个技术点而是把一堆不完美的组件拼成一个能用的系统并且在持续变化中保持稳定。模型会换框架会换但数据流设计、分层隔离、监控排查这些工程基本功不会过时。把基本功打扎实换什么新东西都能快速上手。
