AI工程从零到落地：从提示词到RAG系统的完整实践路线

1. 整体设计思路拆解如果你搜过“AI工程”这个词大概率会看到一堆乱七八糟的结果有讲机器学习的有讲提示词的有讲大模型API调用的还有卖课的。标题里这个“from scratch”很有意思它不是让你从零学线性代数也不是让你从零训练一个GPT而是让你从零建立一套能落地、能交付、能迭代的AI应用开发能力。我用半年时间把这个过程完整走了一遍期间踩了无数坑也总结出了一套相对清晰的路径。这篇文章就是把我走过的路线、踩过的坑、以及最终沉淀下来的方法论完整梳理一遍。适合正在转型的开发者、刚入行的AI工程师以及那些已经被各种AI工具搞得焦虑不已的传统软件工程师。先说结论AI工程和传统软件工程最大的区别不是语言和框架变了而是问题的性质变了。传统开发面对的是确定性系统——你写一个函数输入固定输出就固定。AI工程面对的是概率系统——同一个提示词同一个模型每次输出都可能不同。这个根本差异决定了你的整个技术栈、架构设计、测试策略、部署方式全部要跟着变。很多从传统开发转过来的人第一个误区就是拿写业务代码的思路去写AI应用。比如把提示词硬编码在代码里比如不设计任何降级方案比如把模型返回的JSON直接信任。这些习惯不改做出来的东西就只能停留在demo水平上不了生产。那“从零开始”到底是从哪里开始我的答案是从搞清楚AI应用的技术栈分层开始。我画过一张很粗的分层图分享出来大家参考第一层是基础设施层GPU、推理服务、模型部署框架比如vLLM、TGI、ollama这些第二层是模型层基础大模型、微调后的模型、量化后的模型第三层是编排层LangChain、LlamaIndex这类框架或者你自己写的编排代码第四层是应用层业务逻辑、提示词管理、用户交互第五层是评估层数据集、评测指标、回归测试大多数教程一上来就教你用LangChain搭个聊天机器人这其实是从第三层开始的。基础不牢后面每走一步都会漏风。我在实际学习过程中把大部分时间花在了三层上一是模型本身的调用方式和能力边界二是编排层的工作流设计三是评估层的构建。这三件事搞通了大部分AI应用的需求你都能接得住。另一个重要思路转折是我从“追新技术”转向“吃透稳定技术”。2024年到2025年这波AI发展几乎每周都有新框架、新模型、新术语冒出来。如果跟着浪花走你会发现自己永远在学入门教程永远没有沉淀。我自己做了个决定只深入掌握一套对我最核心的技术栈其余技术保持了解即可。我的这套核心栈是这样的Python做胶水语言FastAPI做服务层OpenAI兼容协议做模型接入层自研一套轻量Agent框架做编排再用PrometheusGrafana做监控用pytest做回归测试。这套栈不是最新的但每一层都是稳定的出了任何问题社区都有大量解决方案。所以这篇文章的标题虽然是“from scratch”但不是从数学公式开始而是从工程实践开始。接下来我按真实的学习路径把这个工程体系从头到尾拆一遍。2. 核心细节解析与实操要点2.1 提示词工程AI时代的基本功很多人觉得提示词工程就是“把需求写清楚让AI干活”这个理解太浅了。真正的提示词工程是在大模型的能力边界内把不确定性降到最低。我做过的第一个生产级提示词是一个客服工单分类器。刚开始我写的提示词是这样的请将以下工单分类为故障报修、咨询、投诉、建议。这个提示词看着没问题实际一跑就露馅了。它有三个致命问题第一没给模型定义输出格式有时候它输出“故障报修”有时候输出“这是一条故障报修类型的工单”第二没有给示例遇到边界case比如“你们的服务态度让我想投诉另外顺便问一下发票怎么开”就乱分第三没有处理无法分类的情况模型会硬给它塞一个标签。后来我把这个提示词迭代到了第7版结构变成了这样角色定义你是一个客服工单分类助手任务目标对用户提交的工单进行意图分类分类标准明确列出每个类别的定义和边界条件输出格式严格限定为JSON格式包含category和confidence两个字段少样本示例每个类别提供2-3个真实案例边界处理无法分类时输出unknown改完之后准确率从76%提升到了92%。这个提升不是模型变聪明了而是提示词把信息熵降低了。我总结了一套提示词模板的写法适用于大部分结构化任务第一步定义角色和目标让模型知道“你是谁、你要做什么、给谁做”。这一步看似简单但很多人会漏掉目标对象。比如“写一封给客户的道歉邮件”和“写一封给技术负责人的故障说明邮件”同样是写邮件措辞风格完全不同。第二步提供上下文和约束条件把业务背景、限制条件、必须遵守的规则都写清楚。比如“本次对话中不能编造数据”、“回复控制在200字以内”、“不能使用专业术语”等。约束条件越多输出越可控。第三步明确输出格式如果希望机器解析一定要给JSON Schema或示例输出。如果是给人看要给结构和排版要求。这一步是最容易被忽略的也是后期解析报错的最大来源。第四步提供示例少样本提示few-shot是目前提升准确率最有效的手段。不需要多每个类型2-3个即可但要覆盖典型场景和边界情况。第五步定义失败行为告诉模型“如果无法完成输出什么”。很多团队不做这一步导致生产环境出现了大量无法解析的错误输出。提示词工程的核心本质其实是在跟概率模型做沟通。你写清楚一层不确定性就减少一分。你写模糊一句它就在某个你不知道的维度上随机发挥。所以我每次写提示词都会自问三个问题角色清楚吗任务边界清楚吗输出格式可解析吗三个都回答“是”这条提示词基本就合格了。2.2 工作流设计别急着上Agent2025年最热的词绝对是Agent但我作为一路踩坑过来的人要给各位泼一盆冷水80%的AI应用场景不需要Agent一个设计良好的工作流就够了。工作流和Agent的区别我打个比方。工作流就像流水线每个工位干的活是固定的工位之间的流转顺序也是固定的。Agent更像一个自由职业者你给它一个目标它自己决定怎么做、分成几步、用什么工具。流水线的优势是稳定、可控、好排查问题Agent的优势是灵活、能处理意外情况但代价是不可解释、不可预测、调试困难。我自己接手过的项目里凡是工作流能解决的绝不上Agent。比如内容审核系统它就是一个典型的工作流先做敏感词过滤再做模型分类然后人工抽检。每一步的输入输出都是确定的模型只是其中一个环节而且还有降级方案——模型挂了就只走敏感词过滤。我把工作流设计总结成几个步骤第一把任务拆成串行或并行的步骤。每个步骤必须是单一的、明确的、可验证的。比如“写一篇文章”可以拆成定选题、列提纲、写初稿、审核修改、定稿。每一步的产物是明确的。第二定义好步骤间的数据契约。上一步的输出是下一步的输入这个格式必须提前定死。我在实际项目中定义了一个统一的“步骤上下文”结构所有步骤读入和产出的都包含原始输入、中间结果、置信度、状态标记。第三给每个步骤设计降级策略。理想情况下每个环节都成功但现实是模型会超时、会返回垃圾内容。降级策略可以是重试、用规则替代、或者直接标记为人工处理。没有降级策略的工作流上线就是给自己找麻烦。第四全程加日志和追踪。每个步骤的输入输出都要留痕。一旦下游发现问题能快速定位到是哪个环节出的问题。我用的是自研的步骤追踪器本质就是一个带上下文的日志系统。什么情况下才需要上Agent我的判断标准是任务步骤不固定、需要动态决策、工具选择不可预判。比如“帮我调研一下新能源车市场的竞争格局产出一份报告”这种任务需要模型自主决定查哪些资料、读哪些网页、最后怎么组织这时候Agent才有意义。但哪怕上Agent我也建议你把它的能力边界圈起来限定它能用的工具、限定它的行动步数上限、给它配置好护栏提示词。我见过太多Agent失控的例子最后变成死循环、胡言乱语、甚至乱调工具。Agent不是魔法它依然是一个概率模型只是在更大的空间里游走而已。2.3 模型选型本地部署和API调用的权衡每个做AI应用的人都会面临这个问题用云端API还是本地部署模型我的答案是取决于你的数据敏感度、流量规模、成本预算以及延时要求。刚开始我做demo的时候无脑用云端API因为快、便宜、效果还好。但一旦涉及到企业内部数据问题就来了。有一次客户要求在纯内网环境跑一个文档问答系统云端API直接出局只能本地部署。当时我选的是Qwen系列的中尺寸模型量化后部署在一张消费级显卡上效果虽然比不上云端旗舰模型但够用。这些年我把模型选型的逻辑梳理成了一张决策表核心看四个维度维度优先API优先本地部署数据敏感度非敏感、通用数据业务数据、隐私相关调用量低频、弹性流量高频、稳定流量延迟要求宽松严格毫秒级响应成本结构按量付费可接受一次性投入、长期成本更低本地部署的坑比很多人想象中多。首先是显存不够的问题7B模型FP16推理大约需要14GB显存加上KV cache和运行时开销实际需要16GB以上。量化到4bit可以降到6GB左右但量化后的效果下降能不能接受需要实际测试。其次是并发问题本地部署的推理服务并发能力远低于云API你需要压测、调参、加排队机制。我目前最常用的本地推理框架是vLLM和ollama。vLLM适合生产环境吞吐量高支持OpenAI兼容接口ollama适合开发调试傻瓜式安装一条命令就能跑起来。简单场景用ollama生产服务用vLLM这个组合帮我搞定过很多项目。还有一个常见误区本地部署的目的不是为了跟云端比效果而是为了保住数据的私域性和控制成本结构。如果你没有这两个诉求坦白说直接用云API是更理性的选择。别为了“本地部署”而本地部署那是技术自嗨。3. 实操过程与核心环节实现3.1 从零搭建一个完整的AI问答系统前面讲的都是方法论这节我来完整走一遍实操流程。目标很明确从零搭建一个基于本地知识库的问答系统本地上跑模型能上传文档能自动切分能做检索增强最后输出一个可以直接用的服务。先说整体架构它是典型的三段式接入层FastAPI提供HTTP接口接收用户问题处理层先做知识库索引再通过向量检索召回相关内容生成层把问题召回内容打包成提示词丢给大模型生成回答这里面有个不可跳过的前置步骤先把模型跑通再写业务代码。很多新手一上来就装LangChain、装向量数据库结果最后发现模型起不来前面全白做了。第一步本地跑起一个大模型我用的是ollama原因无他安装简单、跨平台、模型管理方便。在Windows和Linux上都能跑。# 安装ollamaLinux/macOS curl -fsSL https://ollama.com/install.sh | sh # 拉取一个中尺寸模型 ollama pull qwen2.5:7b # 启动模型并测试 ollama run qwen2.5:7b 你好介绍一下你自己第一次跑模型的时候我遇到的最大问题是内存不足。7B模型默认加载进内存我的开发机32GB内存跑起来占了将近9GB。后来加了OLLAMA_MAX_LOADED_MODELS配置限制同时加载的模型数量情况好了很多。第二步校准模型服务接口ollama从某个版本开始自带OpenAI兼容接口这意味着我可以直接用OpenAI的SDK去连它。这一步非常关键因为后续不管换成哪家云API代码都不用大改。from openai import OpenAI # 直接指向本地 ollama 服务 client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地不需要鉴权随便填 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是一个知识库问答助手。}, {role: user, content: 什么是RAG} ] ) print(resp.choices[0].message.content)这一步做通的标志是你能够通过统一的代码接口切换不同的模型提供方。我为后续做了一层抽象统一成get_model_client()工厂方法配置项里写local就走ollama写dashscope就走阿里云API写openai就走OpenAI。一套代码多端切换。第三步实现知识库索引知识库的核心问题是如何把文档切成合适的块、然后向量化存储。切分看起来很简单实际很讲究。切太粗一块包含多个主题检索精度下降切太细一句话一个块上下文信息不足。我目前的经验值是普通文本按500-800字切分带重叠窗口50-100字。这是一个平衡了效率和效果的区间。切分后每块需要带上来源引用这样以后可以追溯答案到具体文档位置。向量化我用的是sentence-transformers库本地跑一个embedding模型。这步需要注意版本问题不同embedding模型的向量维度不同后面你切换向量库或者模型时候会遇到维度不匹配的坑所以要把embedding模型和向量的维度固化下来。from sentence_transformers import SentenceTransformer # 加载本地 embedding 模型 model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 对切块文本做向量化 chunk 人工智能是计算机科学的一个分支。 vector model.encode(chunk).tolist() # 打印向量维度记住它后续建表要用 print(len(vector)) # bge-large-zh-v1.5 输出 1024 维这里的embedding模型选择有个反直觉的细节不是参数越大越好。全局向量化用的是bge-large-zh-v1.51024维在中文场景下效果不错。一开始我贪图省事用了multilingual-e5-small只有384维跑出来的检索结果明显不如bge系列。维度越高不代表检索越准但模型本身的训练语料和领域适配性更加关键。第四步向量存储与检索我刚开始用的是chromadb因为它轻量、不需要单独起服务、方便本地开发。后面迁移到生产环境才换成了milvus或者pgvector。import chromadb client chromadb.Client() collection client.get_or_create_collection( nameknowledge_base, metadata{hnsw:space: cosine} ) # 添加文档向量 collection.add( ids[doc-001, doc-002], embeddings[vec1, vec2], documents[第一篇文档内容, 第二篇文档内容], metadatas[{source: 2024-annual-report.pdf}, {source: product-manual.pdf}] ) # 检索相似内容 results collection.query( query_embeddings[query_vector], n_results5 )这里要重点说明检索的参数选择。距离度量我选了余弦相似度而不是欧氏距离。原因是向量的绝对位置没有意义方向才有意义。embedding模型输出的向量往往模长不一致余弦相似度能更好地刻画语义相近程度。另外n_results的选择也有讲究太少召回不够太多噪音多。我用5作为默认值后续根据测试结果调整。检索环节还有一个大多数人忽略的关键点先做粗召回再做精排序。粗召回靠向量相似度拉出20条精排序用一个重排序模型reranker从这20条里挑最相关的5条。这比直接向量检索5条效果要好得多。我自己用的是bge-reranker-base中英文都支持实测下来准确率提升明显。第五步组装RAG提示词并生成回答这是整个系统最关键的一步把检索到的内容组织成提示词上下文。def build_prompt(question, contexts): system_prompt 你是一个严谨的AI助手。请基于给定的参考资料回答用户问题。 context_block \n\n.join( f[资料{i1}] {ctx[document]}\n来源: {ctx[source]} for i, ctx in enumerate(contexts) ) user_content ( f参考资料如下\n{context_block}\n\n f请基于以上资料回答问题{question}\n f如果资料中没有相关内容请明确回答资料中未找到相关信息。 ) messages [ {role: system, content: system_prompt}, {role: user, content: user_content} ] return messages # 生成回答 messages build_prompt(我们产品支持哪些退货方式, retrieved_contexts) resp client.chat.completions.create( modelqwen2.5:7b, messagesmessages, temperature0.3, max_tokens1024 )这段代码里有两个值得品味的细节。第一temperature0.3不是默认的1.0。因为做知识问答我们希望模型偏向保守、忠实于参考资料而不是自由发挥。温度越低输出越确定。这个行为在测试中对比过温度从1.0降到0.3编造率明显下降。第二我在提示词里加了一句“如果资料中没有相关内容请明确回答”。这个看似不起眼的约束实际上把模型幻觉的概率降低了一大截。很多RAG系统回答不准确不是因为检索差而是因为模型在找不到答案的时候硬答。你给它一条退路它会更谨慎。3.2 服务化部署与性能调优系统跑通之后下一步就是把它变成正式服务。我用FastAPI做了一层包装核心代码量不大但涉及几个关键问题并发控制、超时处理、流式输出。并发控制本地模型的并发能力有限盲目开高并发只会让每个请求都变慢。我在服务层做了一个简单的信号量控制限制同时处理的请求数import asyncio from fastapi import FastAPI app FastAPI() semaphore asyncio.Semaphore(4) # 最多4个并发请求 app.post(/chat) async def chat(request: ChatRequest): async with semaphore: messages build_prompt(request.question, contexts) resp client.chat.completions.create(...) return resp这个Semaphore(4)是我压测出来的经验值。并发太高显卡上的排队延迟会吃掉所有增益。4在当前硬件条件下是个折中。超时处理模型推理是慢操作必须设置超时。FastAPI里用asyncio.wait_for包住整个调用超时后返回一个降级响应比如“系统繁忙请稍后重试”。实测LLM的响应时间波动很大有时2秒有时30秒所以超时得设得宽容一点我通常设为60秒。流式输出这是体验层面的决定性优化。同样一个长回答一次性返回要等十几秒流式输出首字1秒内就能看到体感差异巨大。FastAPI配合StreamingResponse实现流式输出非常简单前端用fetch或者EventSource接流就行。from fastapi.responses import StreamingResponse app.post(/chat/stream) async def chat_stream(request: ChatRequest): async def generate(): stream client.chat.completions.create( modelqwen2.5:7b, messages..., streamTrue ) for chunk in stream: delta chunk.choices[0].delta.content if delta: yield delta return StreamingResponse(generate(), media_typetext/plain)这一段的工程价值非常大。很多团队的RAG系统demo效果好上线体验差就差在流式输出这一环——用户面对一个转圈十几秒的页面第一反应就是“系统太慢了”。流式输出至少把等待焦虑化解了。3.3 评估与测试别让模型裸奔上线说实话大多数个人开发者和中小团队做AI应用最缺乏的就是评估环节。大家把系统跑通了、demo演示美美的就直接上生产。然后real用户一提问效果原形毕露。我做AI工程最深的体会是没有评估体系就没有迭代基础。你连现在这个版本好坏都不知道怎么优化怎么回归怎么对齐业务指标我搭了一套非常轻量的评估框架跑了半年收益巨大。第一层构造测试集。从真实历史对话里挑100条有代表性的问题覆盖各种意图类型和难度级别。然后人工标注标准答案。这100条就成为回归基线。第二层跑自动化评测。每次改提示词、换模型、调参数都跑一遍这100条算一个准确率指标。如果新改的提示词导致准确率下降说明是负优化回滚。# 我通常用pytest组织评估用例 pytest tests/test_rag_eval.py -v --tbshort第三层评估维度拆开看。单独看回答准确率不够我还会拆出三个维度单独看检索结果相关性、幻觉程度、完整度。这三个维度问题根源完全不同检索相关性问题出在embedding和切分策略幻觉出在提示词和温度参数完整度出在上下文长度和模型能力。拆开看才能精准定位。评测环节还有一个心得让AI当裁判不是不靠谱但要给裁判定规则。我会用另一个模型对回答打分打分标准是明确的、结构化的。比如“对比标准答案判断模型回答是否包含核心要点1-5分”。用模型裁判做初筛人工只复核低分样本这个组合的效率极高。4. 常见问题与排查技巧实录4.1 模型输出总是“答非所问”怎么办这个问题的原因通常是提示词里的角色和任务描述不够清晰或者检索到的上下文质量太差。排查步骤我建议按顺序走第一步检查提示词本身。把messages完整打印出来放回模型单独对话里试一下。如果单独试也答非所问说明是提示词的问题不是检索的问题。最常见的情况是角色定义和任务目标写得模棱两可比如“你是助手”这种毫无区分度的角色。第二步检查检索结果。把检索返回的前5条内容打出来看是不是真的和问题相关。很多情况下问题是检索到的内容压根不相关模型只能硬答。这时候去调embedding模型、切分策略、或者召回数量。第三步检查上下文拼接。有些时候检索结果相关但拼进提示词后格式混乱模型无法理解“哪段是资料哪段是问题”。我用[资料1] [资料2]这种显式标注后效果改善非常明显。格式本身就是一种信息模型很吃这一套。第四步降低温度参数。如果上面三步都排查过了还不满意试试把temperature降到0.1甚至0。有些问题领域就是不需要创造力稳定比出彩更重要。4.2 向量检索不准召回结果乱七八糟这个问题的排查方向同样是多角度的。至少有三个变量会影响召回效果。Embedding模型中文场景下bge-large-zh-v1.5和bge-m3都是不错的选择。如果发现英文效果好、中文效果差大概率是embedding模型的中文语料覆盖不足。换成专门的中文模型试一下。切分粒度切得太细单块信息量不够检索时匹配不到切得太粗一块混了多个主题检索出来噪音太大。我做过一组对照实验发现500-800字的块在大多数场景下效果最好。但也分场景如果文档是FAQ形式按“一问一答”为单位切分效果会好得多如果是法律合同这种长段落文本可能需要更长的块单位。检索策略直接向量检索不是唯一的召回方式。某些场景下关键词检索BM25和向量检索的混合召回效果反而更好。这不算高深的东西就是把两种检索的结果合并去重然后一起进重排模型。我在处理“包含专业术语的查询”时混合召回的效果明显优于纯向量检索因为向量检索对精确术语的匹配能力不强。如果试完这三个方向还是不行那就要检查一下你的测试集本身是不是有问题。有的问题本身语义模糊、或者需要多跳推理这些case即使模型再强也难搞对。把“困难case”和“正常case”分开统计准确率能帮助你更清楚地定位到底是系统问题还是问题本身太难。4.3 本地推理速度太慢响应时间不可接受本地部署最让人头疼的就是性能问题。我拥有一台消费级显卡的机器跑7B量化模型第一次上线时单次请求耗时15秒以上完全不可用。优化后降到了3秒左右勉强能接受。核心优化手段有四招第一招模型量化。从FP16量化到INT8或者INT4推理速度能提升一倍以上显存占用也大幅下降。代价是效果略微下降但多数场景下可接受。我用过GGUF的Q4_K_M量化格式效果和速度比较均衡。第二招换推理框架。ollama适合开发和低并发场景但生产环境我换成了vLLM。vLLM的Continuous Batching技术能显著提升吞吐量特别是在并发场景下。实测同样的模型vLLM的吞吐量是ollama的3-5倍。第三招控制上下文长度。这个点很容易忽略。LLM的推理耗时和输入token数强相关你把几千字的上下文全部丢进去每次推理都会变慢。如果的业务不需要那么长的上下文就在API调用时用max_tokens限制输出同时控制输入长度。我在RAG系统里会默认只塞回5条相关资料总token控制在1500以内。第四招加缓存层。语义缓存很多人没听说过原理是把高频问题去重后的答案缓存起来。先用新的问题去和缓存中的问题做一次向量相似度检索匹配度超过阈值就直接返回缓存答案。这一招在客服、售前这类高频重复问答场景下能把有效负载降低60%以上。但要小心里面的风险相似问题和完全相同的问题不是一回事缓存误命中会导致答非所问。4.4 一些问题排查速查表我把常用的问题排查整理成一张速查表方便大家直接对照表现第一排查点第二排查点第三排查点模型答非所问角色任务描述不清晰上下文拼接格式temperature过高检索结果不相关embedding模型选型切分粒度过大过小召回策略单一响应时间过长推理框架未优化上下文token过多并发争抢显存输出JSON解析失败输出格式未严格约束模型知识不足截断触发导致JSON断裂事实编造严重无“拒绝回答”兜底检索上下文缺失温度过高模型输出含敏感词缺少内容过滤器提示词未定义边界需要一个审核模块兜底4.5 避坑清单那些看文档学不到的教训最后分享几条我个人付出真金白银换来的避坑经验。第一条AI应用的测试集一定要从真实数据里挖不要自己编。自己编的测试集永远觉得自己系统没问题真实用户的提问方式千奇百怪示意图里根本没有覆盖。我后来做了个数据回流机制把线上评分低的case定期拉回测试集效果提升非常快。第二条提示词要版本化管理。我把提示词写进配置文件而不是硬编码在代码里。每个改动记录用途和效果方便回滚。这么做的直接原因是吃过一次亏改了一个提示词全线上效果暴跌但因为没留版本回去找都找不到上一版是什么。第三条设计降级方案是必须的。模型服务是不可靠的网络抖动、显存溢出、API限流各种情况都会发生。我的所有AI服务都有三层降级先用规则匹配规则不行用小模型小模型不行返回人工兜底话术。降级方案不是锦上添花是生存刚需。第四条别盲目相信Agent的自主能力。我见过很多团队用Agent处理需要高准确率的业务结果输出稳定性差得离谱。Agent适合做“探索型任务”不适合做“精度型任务”。如果你要做精度型任务请用确定性工作流把模型的使用范围严格限定在某个环节里。第五条本地部署和云API最好双轨跑。我的生产环境一直保留两套模型接入能力本地主机和云API。平时用本地跑重要时刻或者本地负载高了切云端。这个切换只需要改配置不需要改代码。双轨部署的额外成本不高但关键时刻能救命——比如GPU服务器宕机你可以半小时内把流量切到云端保住业务连续性。5. 后续还能怎么往前拓展当你把这套AI工程体系跑通了会发现它还有很大的扩展空间。我提出几个方向都是我走过或者正在走的路第一个方向从单模型走向多模型协同。现在的场景大多是单一模型完成全部任务当任务足够复杂时可以尝试不同模型分工一个模型做理解一个模型做检索重排一个模型做生成。每个模型各司其职整体可靠性会提升。这种架构需要额外设计模型间的通信协议和数据格式。第二个方向把系统数据闭环跑起来。目前大多数团队的AI系统是“使用-结束”没有数据回流的闭环。如果能把用户的每一次提问、每一次反馈、每一次评分都记录下来沉淀成一个持续迭代的数据飞轮系统的价值会指数级增长。这个方向不涉及前沿AI技术更多是数据工程和产品设计能力。第三个方向从单机走到分布式推理。当单卡显存装不下模型或者单机并发扛不住流量时就需要考虑多机分布式的推理部署。比如用vLLM配合Ray把推理扩展到多台机器或者用推理网关做路由。这套体系做出来后AI应用才算真正具备了“工程化”的完整拼图。每次回顾这段从零起步的折腾过程我最大的感受是AI工程不是说会调API就完了也不一定要学会训练模型。真正核心的能力是把这些概率系统变成可控、可测、可持续迭代的软件产品。这条路没有捷径只能按工程的逻辑一步一步走把每个环节都打磨扎实。希望这篇记录能给正在这条路上的你一些参考。