做AI应用最反直觉的一件事是真正拦住你的往往不是模型而是模型周围那一圈“工程”。模型参数、推理能力这些API一调就有可一旦你想把一个AI功能稳稳当当跑在生产环境里文档分块、检索链路、提示词迭代、成本控制……每一项都能让人连着加班好几周。我这两年带队做了几个不同规模的AI项目从给业务部门做内部知识库问答到面向外部用户的智能体服务深刻体会到一件事所谓“ai-engineering-from-scratch”真正难的不是“AI”而是那个“from scratch”——在没有成熟基建的情况下把所有环节从零搭起来。这篇文章不会给你一套抽象的理论框架而是把我自己在实操中反复验证过的完整路径摊开讲从最开始的方案选型到数据准备、编排层设计、效果评测再到上线部署和成本管控每一步都说清楚“我为什么这么选”和“当时踩了什么坑”。适合想独立把小规模AI应用跑通的人不管是个人开发者还是小团队的技术负责人照着这条路走至少能少走一半弯路。1. 从“我想做个AI”到“我知道要做什么”需求澄清与方案选型1.1 先分清这是个模型问题还是工程问题很多人上来就纠结“要不要微调模型”其实大部分场景根本走不到那一步。我接过的项目里至少七成需求靠“大模型的上下文能力 外部知识检索”就能解决剩下两成需要设计复杂的Agent工作流真正需要微调模型的凤毛麟角。判断方法很简单把你的需求抽象成一句话。“我有一堆内部文档想让人通过自然语言提问就能找到答案”——这是检索增强生成RAG模型本身不需要学习你的文档。“我想让AI根据库存数据自动生成采购建议并且能调用多个系统核对信息”——这是Agent工具调用。“我想让模型学会我们公司特有的术语和写作风格回答质量必须达到专家水平”——这才是微调的候选。这三种路径的工程投入差距是数量级的。RAG项目我试过一个人一到两周出可用原型Agent项目需要至少一个后端加一个算法配合三到四周微调则意味着你要攒训练集、做评估集、跑训练实验基础设施和人力成本都高不少。1.2 为什么基础场景优先选RAG而不是微调这里我给个非常直观的对比表是我在给客户做方案评审时最常甩出来的对比维度RAG检索增强微调Fine-tuning知识更新改文档、刷索引分钟级生效重新训练或增量训练几小时到几天数据要求文档质量尚可即可无需标注需要大量高质量“问题-答案”对幻觉控制可引用来源相对容易溯源依赖模型内部记忆溯源困难成本主要是检索和API调用费用训练算力 多次实验成本启动速度一周内可出原型至少两到四周我见过一个很典型的反面案例一家公司花两个月微调了一个垂直领域大模型结果上线后业务文档一更新模型回答还是老版本的。最后实在受不了又回头做RAG把文档接进来。早知如此当初直接用RAG至少能省一个半月。1.3 先冻结需求边界再谈架构现在很多从零开始的项目死在“需求没冻结”上。老板今天说做个智能问答明天说加个流程编排后天又说要和现有系统对接团队在原型期就被反复重构拖垮。我在项目起步时一定会做一件事写一份“项目边界确认单”。内容包括——第一版要支持哪三类问题、固定使用哪些数据源、AI回答错误时用户怎么反馈、系统的吞吐量预期是多少。这份确认单不求完美但必须有而且是开发前就要和需求方达成书面共识。因为没有边界的AI项目就像没有锚点的船风一来就跑偏。边界定下来之后才进入技术选型。这时候我不会一上来就搬全家桶框架而是反问自己团队有几个人、有没有专门做部署运维的人、上线后每天的调用量级大不大。想清楚这三个问题选型自然就清晰了。2. 知识准备把文档切成模型能“消化”的颗粒度2.1 文档解析和清洗检索效果的地基RAG项目里有一句至理名言垃圾进垃圾出。检索效果不好的时候八成问题出在文档解析阶段而不在向量检索本身。我从实际项目中总结出的文档清洗流程是这样几条按优先级排序把PDF、Word、PPT统一转成结构化文本表格尽量转成Markdown或键值对形式因为大模型读表格原始文本经常读错。删除页眉页脚、重复水印、目录页码、无关附注。这些噪音进向量库后会被检索出来直接影响回答质量。对同一份文档的多处重复段落做去重避免检索结果被同一段文字刷屏。尽量保留小标题层级信息用特殊符号标记后面切分时可以辅助判断语义边界。有一家客户让我印象很深他们把几百份技术手册直接切片进了向量库结果用户问什么答案都带上“公司版权所有翻印必究”这句话。就是因为页脚水印没清洗检索出来相关内容里全是这条噪音。2.2 切分策略既有科学的活也有手艺的活文档切分是RAG项目里最容易被低估的环节。切太大细节丢失上下文里塞一堆无关内容切太小语义被截断检索对不上。目前业界主流的方案还是按固定长度切分叠加重叠区再配合标记感知做微调。我常用的切分参数供你参考普通说明文档chunk_size 500~600字符overlap 50~100字符这个体量对多数嵌入模型比较友好。代码相关文档按代码逻辑块切而不是硬按字符切一个函数或一个类尽量放同一个chunk。商务合同法律文书按条款编号切分一条条款一个chunk效果远好于“第X页”这种页面维度。这里说一个关键点为什么必须设重叠因为句子在语义上是跨界的。比如“本协议未尽事宜按照XX条例执行”这句话如果正好被切成两半前半段检索到后根本不知道在说什么。加了overlap后至少有一份chunk保住了完整语义。切完之后别急着往下走先抽十个典型问题做一次手动检索测试。看看检索回来的Top 5片段是不是真的有货。如果这一步就不行后面接入大模型只会更糟。2.3 向量化与混合检索别再迷信纯向量现在有股风气是“一切皆向量”但我实测下来纯向量检索在中文场景下经常翻车。原因在于中文同义词、简称、指代特别多——文档里写“甲方”用户问题里可能说的是“委托方”向量模型未必能对齐。所以我做检索基本都上混合方案BM25传统关键词匹配 向量召回结果融合后过一遍重排序模型。BM25负责抓精确术语向量负责抓语义相关两者互补之后召回准确性明显提升。融合分数的简化公式是final_score 0.4 * bm25_score 0.6 * vector_score权重可以按业务调。偏术语型的场景比如医疗诊断、专利检索BM25权重往上调偏开放语义的场景比如创意文案、客户意见分析向量权重往上调。这个参数没有标准答案靠评测调。向量库这块我的建议曲线是原型期用轻量的比如FAISS或单机向量数据库等数据量上来、并发需求明确了再上分布式或云托管服务。别一开始就给自己上重武器徒增运维负担。3. 编排层设计从单轮问答到会“干活”的智能体3.1 先跑通单轮RAG链路再加复杂度我见过不少团队一上来就冲击“Agent”结果被工具调用的不稳定性和安全边界折磨到崩溃。我的规矩很简单连单轮问答都还没做稳不要碰编排。单轮问答链路的流程极简核心就三步——拿到问题检索知识库把检索结果和问题一起丢给大模型生成答案。这一步先跑通一方面验证检索效果另一方面把延迟基线和成本基线摸出来后面做任何复杂化都有参照。等单轮表现稳定才开始往“多轮对话 工具调用”演进。比如用户问“最近三个月销售趋势怎么样”系统后台先判断这个查询需要调用什么工具、读什么数据。这就是Agent的第一层能力——路由。3.2 工具调用的设计原则让模型的路好走做Agent的编排层我觉得最核心的不是提示词写得多炫而是你把工具暴露给模型的方式。这里有几个容易踩的坑工具名要直白。“sales_data_query”比“query_v3”好用得多模型的语义理解能力再强也没法从无意义的名字里猜出用途。参数说明要写清楚。比如日期参数规定“YYYY-MM-DD格式”模型一旦理解错格式整个工具调用就白搭。工具返回结果要尽量简洁。返回一堆原始JSON让大模型去“阅读理解”既浪费token又容易出错。提前做一层汇总让大模型拿到的已经是处理好的信息。我做过一个真实案例需求是让AI根据库存水位自动生成补货建议。当时工具里有个“get_inventory”接口返回的是几十个仓库的明细数据。第一版Agent每次都把完整JSON塞进上下文Prompt超长、回答还很飘。后来我在工具层先做了一层统计聚合只返回“低于安全库存的20个SKU及其缺口数”Agent的决策质量立刻上了一个台阶。3.3 工作流编排固定流程配动态节点关于Agent和Workflow的取舍我的原则是确定性的业务流程用Workflow硬编码不确定的判断和生成用Agent的LLM节点来处理。全部交给“智能体自由发挥”在现阶段的生产环境里是灾难。举个例子做一个“智能客服售后工单系统”工单分类——可以用固定流程图意图识别结果命中后走对应分支。退款金额计算——必须按业务规则写成确定性代码绝不能让模型自由发挥。情绪安抚措辞——交给大模型生成属于动态节点。这种“流程骨架固定关键内容动态生成”的模式是目前生产环境里最稳的Agent落地方式。所谓多AI协作在我理解里就是把不同的模型塞进工作流的不同环节各干各擅长的活而不是让一个Agent把所有事全包了。4. 提示词工程 评测闭环效果是“磨”出来的4.1 提示词工程第一课别急着写花活很多人对Prompt Engineering的第一反应是“我要写一个复杂的思维链”。但实际上我在生产项目里的Prompt大多是“朴素而结构清晰”的核心就三部分角色约束、任务说明、输出格式。角色约束用两三句话告诉模型它是什么角色以及对答案风格的要求。比如“你是资深供应链分析师回答要给出数据支撑和风险提示”。任务说明把完成回答所需的条件写清楚比如“你必须依据提供的参考材料进行回答参考材料中不存在的信息明确说明你不知道”。输出格式规定返回结构。结构化输出不仅方便解析也能避免模型自由发挥。最关键的其实是“系统提示词里不要塞过多历史案例”。我见过有人把一整套Prompt写得像小说占了好几千token结果效果反而不如一个清晰版的。对当前主流模型来说提示词里的信息密度比信息量本身更重要。4.2 评测集是你的产品验收标准不做评测就迭代提示词相当于闭着眼睛调参。我统计过自己的迭代周期有评测集的时候一天能稳定迭代3到5轮没有评测集的时候改一版要纠结半天还经常越改越回去。评测集怎么建我建议先小后大第一批先收集50条真实用户问题其中20条负责测答案准确性20条测检索召回10条测边界场景比如问法模糊、包含错别字、涉及不在知识库范围的内容。用这批“种子评测集”先把链路调稳。等系统雏形跑通后再从用户日志里持续补充真实问题进评测集。我目前手上的生产项目评测集已经攒到三四百条每次改提示词或换模型都拿全量回归一遍看整体指标是升还是降。4.3 把模糊感受化为可判定指标AI效果评测很麻烦因为“答得好不好”是个主观判断。我的做法是把答案判定拆成三个独立维度分别打分准确性关键事实是否和参考材料一致有没有编造数据。完整性用户问题里的每个子问题是否都被回答了。可操作性回答能不能直接拿来用是否给出明确结论而非罗列信息。三档打分好/中/差人工评一遍50条大概半小时。这个成本值得付出因为评测结果会直接告诉你问题出在检索、提示词还是模型能力上。我有个深刻的教训曾经连续调了一周的提示词才发现真正的问题是检索召回率太低提示词再怎么调也是白费。评测闭环的意义就在这里——它帮你不懈地把力气花在正确的地方。5. 部署上线与成本控制小团队最该盯紧的两件事5.1 从原型到生产多了哪些事很多从零开始的项目倒在上线前的“最后一公里”。原型阶段跑通是一回事生产环境稳定是另一回事。我自己过程里整理出的上线检查清单包括上下文窗口的token消耗要压测。高峰期并发数乘上平均请求token数得出的才是真实的成本预期。接口要限流。大模型服务的调用是花钱的不对用户侧做限流一个爬虫脚本就能把预算烧光。需要引入缓存层。对于重复性问题比如“退货政策是什么”命中缓存后可以不调用模型接口成本直降。业务侧要有兜底开关。模型服务挂掉时是返回降级文案还是有备用逻辑必须提前定好。我在一个项目里就吃过亏上线第二天某个合作方写了个定时脚本每条数据都来“咨询”一次一个晚上调用费用跑出了平常一个月的量。从那以后“限流 缓存 告警”成了我的上线标配三件套。5.2 模型选型别只看效果还要看账用商用大模型API的时候我一般按成本和效果分成三档来选场景推荐档位理由高价值复杂推理旗舰级大模型准确率优先成本可接受常规知识问答标准级大模型效果够用价格适中分类提取等简单任务轻量级模型或微调专属模型成本极低延迟低实测下来不少简单任务用轻量级模型效果跟旗舰版没太大差别但成本可能差出一个数量级。比如里面很常见的“意图识别”任务早期我用旗舰模型做后来换小模型准确率只掉了不到一个点每月账单却省了一大截。关于开源模型和闭源API的取舍我的建议是团队没有稳定的模型部署能力时用API是性价比最高选择别为了“技术掌控感”强行上自部署。自部署意味着要管GPU资源、推理框架、并发排队、监控告警这些隐形工作量经常被低估。5.3 成本不好算先把token估算玩明白控制成本的第一步是搞清楚钱花在哪。大模型项目的成本大头包括输入token、输出token、嵌入模型的调用量、向量数据库存储费。我给自己用过一个简易估算公式单次请求成本 输入token数 × 输入单价 输出token数 × 输出单价 月成本 日均请求数 × 平均单次请求成本 × 30比如一个内部知识库日均2000次请求平均每次输入2000 token、输出500 token按标准级模型算下来月成本大概在几百元到一千多元的量级。这个数字对多数内部系统来说完全可控。难控的是那些输入超大、动辄塞几万token的项目——比如文档总结类应用input一多成本直接翻好几倍。成本优化还有一个不起眼的点控制参考材料的长度。检索回来的内容越多token消耗越大回答还可能因为信息过杂而变差。我在实操里会在重排序后把Top 5压缩成Top 3既能控成本多余信息少了对质量也有帮助。6. 踩坑实录检索不准、幻觉失控和那些“骗人”的指标6.1 检索不准的第一嫌疑Embedding模型和领域不匹配通用Embedding模型在专业领域的表现经常让人失望。我们做医疗项目时通用向量模型对药品别名、诊断术语的匹配效果很差——“扑热息痛”和“对乙酰氨基酚”在通用模型眼里可能毫无关联。后来换了领域适配的Embedding模型检索精度提升非常明显。所以我不再“一个模型走天下”而是针对领域特点选择向量模型甚至做少量语料微调。这一步是检索质量的基础基础不对后面的重排、提示词都是白搭。6.2 幻觉问题治标和治本一起上大模型幻觉是RAG项目里最头疼的问题我的经验是要多管齐下提示词层面明确要求“只能根据提供的资料回答”。系统层面对关键事实做二次校验比如抽取答案中的数据点回原文检索核对。用户侧给出来源引用让用户看到答案的出处降低对AI盲信的程度。对模型确实无法回答的问题主动说“不知道”比硬编一个答案好得多。治本的方向是让检索结果本身更准、更贴近用户问题因为幻觉很多时候源于“模型没找到对的资料就开始联想”。这也是为什么我坚持投入时间做文档清洗和切分调优检索侧的每一点进步都会直接减少幻觉的发生。6.3 别把“答得流畅”当成“答得正确”我还想提醒一个非常容易骗人的指标用户的直观感受。AI回答读起来通顺、自信用户就会觉得“好用”哪怕里面的关键数字是错的。这导致很多项目在演示阶段效果惊艳实测一较真就露馅。我的做法是在评测表里单列“数据准确性”项人工评测只认这条。宁可让AI回答显得“笨”一点比如多了几句“此项未能确认”也不能让它在关键事实上编谎话。这个尺度是一定要坚守的。6.4 关于“换个大模型”解决一切的错觉最后说个很多团队会有的执念效果不行换个更强的模型试试。升级模型确实是方案之一但往往是最贵的那个。我经历过一个实际项目花大价钱从标准模型升到旗舰模型结果评测分数只涨了2、3个百分点后来发现其实是检索召回阶段丢了关键文档。把召回问题修好后标准模型的成绩反而超过了之前旗舰模型的成绩。所以排查效果问题我的固定顺序是先查检索再查知识数据质量再看提示词最后才怀疑模型能力。Model Power是最后一张牌不要一开始就把它打出来。从零开始做AI工程说到底不是拼谁的模型参数大、谁的框架新而是拼谁能把文档清洗、检索调优、评测迭代、成本核算这些“脏活累活”一件件踏踏实实做完。我个人的体会是这行当没有捷径但有很多弯路——把上面的经验吃透你至少能避开我当年踩过的大半坑。下次再接到“帮我做个AI”的需求时先别急着调大模型从需求边界和文档清洗开始你会感谢这个决定的。