把大模型应用从“能跑通”推到“敢上线”中间隔着一条挺深的河。我最近完整经历了一个从零搭建AI服务到生产环境稳定运行的落地过程期间踩过模型幻觉、Token超限、接口超时、内存泄漏这些坑也沉淀了一套相对清晰的打法。这篇文章就把我认为最有复用价值的经验整理出来从技术选型、架构设计、核心编码到部署验收、故障排查一次性讲透。文章更适合两类人看一是已经用LangChain或相关框架写过Demo准备往生产环境推的开发者二是团队刚立项需要在技术选型和架构层面做决策的技术负责人。文章不会讲太多基础概念重点放在“生产环境里真正要命的问题”上。1. 先把生产落地的核心逻辑想清楚1.1 为什么AI应用开发和传统后端开发不一样很多人第一次把AI应用往生产推的时候会下意识沿用传统后端那套方法论定义好接口、写好业务逻辑、压测、上线、监控。这套流程没错但AI应用有几个传统后端很少面对的特殊变量。第一个变量是输出的不确定性。传统接口的返回值是确定的参数一样结果必然一样。大模型接口不一样同样的Prompt、同样的参数两次返回的内容可能有细微差别甚至偶尔会给出完全偏离预期的结果。这个特性直接影响接口设计、缓存策略和错误处理方式不能简单套用传统Web开发的经验。第二个变量是成本模型完全不同。传统接口的成本主要在服务器资源和带宽边际成本低且好预估。大模型接口的成本和Token数量强相关用户多问一句话、上下文里多塞一份文档成本就上去了。如果不在架构层面做控制月底账单会让人措手不及。第三个变量是性能瓶颈从“应用服务器处理不过来”变成了“外部模型接口响应太慢”。一次请求动辄几秒到十几秒远远超过传统接口的几百毫秒标准。前端交互、超时设置、用户体验设计都得围绕这个现实重新考虑。第四个变量是评测方式不一样。后端功能对不对写测试用例断言就行。AI应用怎么判断“回答得好不好”语义准确、格式规范、不胡说八道这些指标很难用传统自动化测试覆盖。理解了这四个差异再看后续的技术方案很多设计决策就顺理成章了。1.2 生产级AI应用的五大技术选型思路选型是项目最先遇到的关卡。我的经验是把决策拆成五个层面逐层定每一层都有明确的原则。第一层是模型的选择。现在主流路线无非三种调用云端大模型API、部署开源模型、用云端模型加私有化部署混合。我的建议很直接业务刚起步、对数据敏感度没有极高要求直接选国内成熟的云端API或海外厂商的稳定版API别自己折腾部署。只有当延迟、成本或数据合规要求达到一个临界值再考虑私有化。选模型还有个细节容易被忽略——模型版本一定要锁定不要默认用“latest”之类的不固定别名否则模型厂商升级版本后你的业务输出可能悄悄变化线上问题排查起来非常被动。第二层是开发框架。目前主流选择包括LangChain、LlamaIndex以及在Java生态里用得越来越多的Spring AI。框架的作用是屏蔽不同模型厂商的API差异提供Prompt模板、工具调用、RAG这些通用能力。我的建议是不要贪多求全选择自己团队技术栈最匹配的。比如团队是Java后端背景Spring AI的学习曲线明显更平缓和Spring Boot配置体系的融合也更自然。第三层是外部环境的准备。模型要接进来至少需要一套Key管理体系密钥不能裸奔在前端代码里后端要有统一的转发层。如果业务涉及多个模型来源还要有降级切换的机制。这层投入不大但直接影响系统稳定性和安全性。第四层是数据层。AI应用和数据库的结合方式比传统应用丰富得多。最常用的是向量数据库用于语义检索和知识库问答但关系型数据库依然不可或缺用来记录用户的对话历史、存储业务数据、维护状态。选型时一定要把这两类数据库的分工想清楚否则很容易在数据一致性上栽跟头。第五层是可观测性。传统应用看QPS、错误率、响应时间就够了AI应用还得多看一层模型调用耗时、Token消耗量、上下文窗口占用率、幻觉发生频率。没有这一层数据后面做优化全凭感觉。2. 架构设计与细节参数决定上线后能不能睡安稳觉2.1 请求链路上的四个关键环节一个典型的AI应用生产请求链路我习惯拆成四个环节每个环节都有需要重点把控的设计点。第一个环节是接入层。用户请求进来后先做身份认证、限流、参数校验这些和传统网关没什么区别。但AI应用在接入层还要做一层内容安全检查无论是用户输入还是模型输出都要过一遍敏感信息过滤器防止用户提出恶意指令或模型生成不合规的内容。这一层往往被重视得不够等出了事再补就晚了。第二个环节是上下文装配。这步是AI应用和后端业务逻辑结合最紧密的地方。在请求发给模型之前系统需要从数据库中取出用户的对话历史、检索出相关的知识库片段把它们和系统Prompt、用户当前问题一起组装成完整的上下文。这个环节决定了一个AI应用回答得好不好远不止“把Prompt写漂亮”那么简单还要考虑上下文窗口限制、Token预算分配、历史记录截断策略等一系列工程细节。第三个环节是模型调用。这里重点是流式输出和非流式输出的选择、超时控制、重试机制、多模型降级策略。生产环境下绝对不能把请求调成“死等”必须有严格的超时熔断机制。第四个环节是结果后处理。模型返回的原始内容通常不能直接给用户要经过格式清洗、结构化解析如果请求的是JSON格式还得处理模型偶尔输出不合法JSON的情况。该落库的落库、该触发后续流程的触发后续流程这才算一个完整的闭环。这四个环节环环相扣每一环出问题都会影响最终效果。后面我会针对每个环节给出更具体的实现方案。2.2 提示词工程与上下文管理的实操细节提示词在Demo阶段怎么玩都行一旦上生产就必须把管理规范立起来。我的做法是全公司统一维护一个提示词版本库每条提示词都对应一个版本号需要调整时走更新流程并记录变更原因。这样做的好处太多了线上效果不佳时能够快速回滚到旧版本模型厂商升级后行为变化能够定位是不是提示词过时了。而不会出现“明明没人动过代码效果怎么变了”这种诡异问题。提示词本身要遵循几个基本原则。一是职责单一一条提示词只干一件事别把角色设定、知识库指令、输出格式要求混在一起。二是明确约束边界最好用“必须”和“禁止”做正反两个方向的约束而不是一味描述“你应该是什么”。三是给模型留出足够的推理空间复杂问题可以要求“先分析再回答”比直接要求“直接给出答案”效果更好。上下文管理是AI应用生产落地里最容易忽视的细节。大模型的上下文窗口有限而且输入Token数量直接影响响应速度和成本。很多公司的知识库文档一多就想全塞进上下文里结果要么超出窗口报错要么响应极慢、成本飙升。正确的思路是做分层明确的用户意图和最新消息放前排历史消息做摘要压缩知识库内容只放和当前问题最相关的片段。这个“最相关”怎么算就是向量检索要解决的问题后面在RAG部分详细讲。2.3 Agent、RAG、模型微调怎么选做AI应用迟早会面对这个问题我的场景需要Agent、RAG还是微调我的答案是三者的定位完全不同很多场景还可能需要组合使用。RAG主要解决“模型不知道的事”也就是知识时效性和私有知识的问题。模型训练数据有截止时间企业内部文档、实时数据它根本不知道。RAG的做法是在回答前先从外部知识库检索相关内容塞进上下文里让模型参考。它不改变模型本身适合知识库问答、企业文档助手、政策法规查询这类场景。RAG是绝大多数业务场景最优先考虑的方案因为见效快、可解释性强、知识更新成本低。微调主要解决“模型做不好的事”也就是希望模型模仿某种特定的语气风格、输出结构或遵循特定的专业术语。微调需要准备高质量的数据集需要训练和评估成本而且效果具有不可逆性——模型一旦被微调它在其他通用能力上可能有一定程度的衰减。适用于任务非常稳定的场景比如代码生成、特定行业的文本分类、企业内部的意图识别。Agent的执行能力更突出解决“模型光说不动”的问题。它让模型能调用外部工具、查询数据库、操作API把一个复杂的任务拆解成多步执行。典型场景包括智能客服需要查订单、AI编程助手需要读写代码、数据分析助手需要操作数据库。但Agent也是三个方案里最难控制稳定性的多步推理中的任何一步出错都会被放大生产环境必须有严格的审核机制。我的建议是不要一上来就上Agent用最简单的方式把核心链路跑通。比如RAG能解决80%的问题就从RAG开始等积累足够多的真实用户反馈明确知道哪些场景需要多步工具调用再逐步引入Agent。生产环境最怕的是架构过度复杂问题排查起来像大海捞针。2.4 成本、延迟与并发上线前的三个量化指标传统后端上线主要关心服务器规格够不够AI应用要复杂的多。我建议在写第一行业务代码前先把三个量化指标估算清楚。第一个是单次请求的平均Token消耗。用开发环境的真实对话数据做样本计算平均每轮对话消耗的输入Token和输出Token。注意输入Token不止是用户那句话还包括系统Prompt、历史记录、检索出来的知识片段这部分的体量往往比用户输入更大。有了这个数据再乘以预计日活就能估算出当月的模型调用成本。很多公司上线后才拍脑袋发现预算不够就是因为漏算了上下文中的隐形成本。第二个是端到端延迟。要分别测三段时间模型首字返回时间、整个流式响应完成时间、以及包括检索和上下文装配在内的整体耗时。用户能感知到的主要是前两段。如果发现首字返回太慢优先检查是不是上下文太长、模型规格太大或者网络链路有没有绕路。第三个是并发上限。这里要同时算两层一层是应用服务的并发能力这取决于你的服务配置和负载均衡策略另一层更重要——模型API的配额限制几乎所有云端模型API都有TPM每分钟Token和RPM每分钟请求数限制。如果不提前做限流和排队一旦流量上来最先崩的反而是外部API调用报错信息往往还不太明显。我用一个具体场景来算一笔账。假设一个智能客服应用系统Prompt约500Token每轮历史记录平均1000Token问题平均50Token回答平均300Token。单次请求的总Token大约是1850Token。如果每天1万次请求一个月的消耗就是1850乘以10000乘以30等于5.55亿Token。按主流模型的定价估算这已经不是一笔小数目。但如果做好历史消息摘要、把系统Prompt控制在300Token以内、知识库只检索最相关的几百Token单次消耗降到800Token以下成本能直接压缩一半以上。这就是为什么我一直强调成本不是上线后才控制的而是在架构设计阶段就要考虑的。3. 一次完整的生产落地实操记录3.1 工程初始化与依赖配置理论说得再多不如上手走一遍。这一节我用一个企业知识库问答助手作为示例项目完整演示从工程初始化到部署上线的过程。技术栈选型上后端用Java 17加Spring Boot 3加Spring AI前端用简单的Web页面做演示数据库用PostgreSQL加pgvector实现向量检索部署用Docker Compose编排这种组合在Java团队里落地成本最低。先创建Spring Boot工程。如果你用的是Spring Initializr版本选3.2以上Boot版本太低的话Spring AI的兼容性会有问题。依赖上需要引入Spring Web、PostgreSQL驱动和Spring AI相关的模块。dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0-M6/version /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-pgvector-store-spring-boot-starter/artifactId version1.0.0-M6/version /dependency dependency groupIdorg.postgresql/groupId artifactIdpostgresql/artifactId scoperuntime/scope /dependency需要注意Spring AI目前的版本迭代很快API层面有一些微调一定要锁定一个版本并在项目里固定下来。我把版本写在Maven的版本属性里统一管理尽量避免不同模块依赖版本不一致导致的诡异错误。配置文件方面核心配置就是模型API地址、密钥和向量库的连接信息。我习惯把这些配置放到环境变量或者配置中心里代码仓库只保留模板文件避免密钥泄露。spring: ai: openai: base-url: ${AI_BASE_URL} api-key: ${AI_API_KEY} chat: options: model: ${AI_MODEL_NAME:gpt-4o-mini} temperature: 0.3 max-tokens: 1024 datasource: url: jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME} username: ${DB_USER} password: ${DB_PASSWORD}这里特别强调temperature参数生产环境的对话问答场景建议设置在0到0.3之间越低输出越稳定。有些团队默认用API的默认值那往往偏高生成结果发散的状况会让人抓狂。3.2 构建流式对话接口AI应用的对话接口强烈建议用流式输出。原因很简单大模型生成完整回答需要几秒甚至十几秒如果等全部生成完再一次性返回前端长时间白屏用户的体验会非常糟糕。流式输出让用户第一时间看到第一个字配合打字机效果心理等待时间大大缩短。Spring AI的流式接口实现比较简洁。我写一个Controller接收用户消息和会话ID通过ChatClient的stream方法把模型输出以SSE格式推送给前端。RestController RequestMapping(/api/chat) public class ChatController { private final ChatClient chatClient; private final ConversationService conversationService; public ChatController(ChatClient.Builder chatClientBuilder, ConversationService conversationService) { this.chatClient chatClientBuilder.build(); this.conversationService conversationService; } PostMapping(value /stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString streamChat(RequestBody ChatRequest request) { // 1. 从数据库加载历史会话 ListMessage history conversationService.loadHistory(request.sessionId()); // 2. 组装包含历史记录的Prompt Prompt prompt conversationService.buildPrompt(request.message(), history); // 3. 流式调用模型 return this.chatClient.prompt(prompt) .stream() .content(); } }这看起来不复杂但数据库的会话记录缓存和历史截断策略很关键系统Prompt与用户输入之间的平衡也需要在前置服务层做好。我见过不少团队流式接口很快接出来了但把系统提示、历史、知识库片段一股脑全塞给模型导致Token消耗和响应延迟双双失控。3.3 给AI接入企业知识库搭建RAG流程接下来是知识库问答系统的核心——RAG流程。整个流程分两步第一步是文档的离线索引阶段把企业文档切块、向量化、写入向量数据库第二步是在线问答阶段用户提问后先检索相关文档片段再把片段塞入上下文让模型回答。很多教程只演示了第二步但生产环境真正麻烦的是文档更新和索引的维护。文档切块是非常影响检索质量的一步。切得太碎语义被切断检索精度下降切得太大每个块包含太多冗余信息塞进上下文浪费Token。我的经验是一般文档按500到800字切块块与块之间保留50到100字的重叠确保跨块语义不断裂。代码文档可以按照类或方法进行结构化切分效果更好。在线问答的流程里我一般会在标准的“检索-增强-生成”上加一个“改写”环节先让模型判断用户的意图、提取关键词再去做向量检索。这个改写的成本很低但能显著提高检索命中率尤其当用户的提问用语比较口语化、和文档里的书面表达差距较大的时候效果尤为明显。下面是向量检索和回答生成的核心代码。Service public class RagService { private final VectorStore vectorStore; private final ChatClient chatClient; public String answer(String question) { // 1. 构造查询向量执行相似度检索 ListDocument documents vectorStore.similaritySearch( SearchRequest.builder() .query(question) .topK(4) .similarityThreshold(0.5) .build() ); // 2. 将检索结果组装成上下文 String context documents.stream() .map(Document::getContent) .reduce(, (a, b) - a \n\n b); // 3. 构造系统提示词要求模型基于上下文回答 String systemPrompt 你是企业知识库助手。请根据提供的资料回答问题。 如果资料中没有相关内容请明确告知用户“资料库中暂无相关信息”不要编造。 回答时引用资料中的关键信息保持简洁准确。 参考资料 %s .formatted(context); // 4. 调用模型生成回答 return chatClient.prompt() .system(systemPrompt) .user(question) .call() .content(); } }注意几个生产级细节。similarityThreshold设的是相似度过滤阈值避免检索到完全不相关的内容还硬塞给模型。topK的数量不要贪多4到5个片段已经足够回答大多数问题塞太多反而稀释重点、推高成本。系统提示词里那句“资料中没有就直说不知道”是控制幻觉最直接有效的手段我强烈建议所有知识库场景都加上。3.4 Docker化部署与启动参数调优工程开发完成后部署环节有几个很容易栽跟头的点。直接上Dockerfile和Compose配置逐行说明关键细节。FROM eclipse-temurin:17-jre WORKDIR /app COPY target/*.jar app.jar EXPOSE 8080 ENV JAVA_OPTS-Xms512m -Xmx1024m -Dfile.encodingUTF-8 ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar app.jar]JVM参数别照抄默认值要根据实际压测结果调。AI应用的内存大头通常在向量计算和请求并发上。JVM堆内存设太大浪费资源设太小容易频繁GC导致接口延迟抖动。建议先设置Xms和Xmx相同值减少运行期堆扩容带来的性能波动再根据压测数据二次调整。Docker Compose把应用服务和PostgreSQL编排到一起。version: 3.8 services: postgres: image: pgvector/pgvector:pg16 environment: POSTGRES_DB: ai_app POSTGRES_USER: ai_user POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pgdata:/var/lib/postgresql/data ports: - 5432:5432 healthcheck: test: [CMD-SHELL, pg_isready -U ai_user -d ai_app] interval: 5s timeout: 3s retries: 5 app: build: . ports: - 8080:8080 environment: AI_BASE_URL: ${AI_BASE_URL} AI_API_KEY: ${AI_API_KEY} DB_HOST: postgres DB_PORT: 5432 DB_NAME: ai_app DB_USER: ai_user DB_PASSWORD: ${DB_PASSWORD} depends_on: postgres: condition: service_healthy volumes: pgdata:这里我用的是pgvector官方的PostgreSQL镜像它内置了向量类型和索引支持起一个容器就把关系型数据库和向量数据库都解决了省去额外维护一套向量数据库的运维成本。3.5 上线前的验收清单真正上线前我建议团队按照下面的清单逐项过一遍每一项我都实际踩过坑流式响应是否在弱网环境下稳定不断线前端断线重连逻辑是否已处理。用户输入超长时是否会被优雅地截断或提示而不是直接报错。多个用户同时提问时接口响应时间是否在可接受范围内是否触发过模型API限流。模型偶尔生成不合法内容时内容安全过滤是否正常工作。回答内容是否会被记录到日志里日志系统是否会因为对话内容产生合规风险。模型服务不可用时系统是否具备降级能力比如返回提示文案或切换到备用模型。整个链路的监控指标是否齐全包括Token消耗、模型延迟、检索命中率、用户满意度。这份清单覆盖了功能正确性以外的运维、成本、安全、体验多个维度。千万别觉得功能能跑就等于生产可用了AI应用的项目管理和传统软件有本质区别不确定性因素太多没有验收机制就上线后面要付出的代价是巨大的。4. 常见故障与排查技巧实录4.1 服务不稳定超时、幻觉、上下文泄漏生产环境跑起来之后各种问题才开始真正暴露。这里挑几个最典型、最让人头疼的故障场景说说我的排查思路。第一个是模型接口超时。表现是用户等了好久没反应或者前端直接报错。排查时不要一上来就怀疑网络先看是不是上下文太大把模型的处理时间撑爆了。我遇到过最夸张的一次系统里塞了几万字的文档还要求模型做总结接口直接超时。解决思路是限制上下文长度超长内容先做摘要再用摘要去提问。第二个是幻觉问题。模型一本正经地编造知识库中不存在的信息这种情况在知识库问答场景里最常见。我排查的时候会先看检索环节有没有问题经常是检索出来的片段和问题完全不相关模型只能硬着头皮自己编。把相似度阈值调高、优化文档切块逻辑基本能解决大部分问题。还有一层兜底方案就是在结果返回前加一个“内容校验”环节用规则或小模型做一次相关性打分低于阈值的回答统一提示“资料不足无法回答”。第三个是上下文泄漏。这个问题的隐蔽性特别强。当多个用户会话共用一个上下文缓存或者检索模块把文档内容错配到其他业务的上下文中就容易把A用户的信息暴露给B用户。排查时重点检查对象缓存的生命周期管理会话维度的数据必须严格按sessionId隔离任何涉及用户数据的模块都要默认隔离而不是默认共享。4.2 成本失控与限流怎么定位异常消耗AI应用上线后成本突然翻倍是另一个常见的“惊喜”。我建议先看监控面板的Token消耗趋势如果某个时间点开始爬升基本可以锁定是代码改动或用户行为变化引起的。有一种隐蔽的成本坑是循环调用。比如你在Agent里设计了工具调用模型为了完成一个任务连续循环调用某个工具几十次每次都消耗Token成本会在不知不觉中飙升。解决方法是给Agent设定最大迭代次数超过阈值自动终止。还有一种是“用户灌长文”攻击。用户故意输入超长文本系统不加限制地把全文塞进上下文成本随之暴涨。防御手段是在接入层做输入长度限制超过预设阈值就拦截或提示。这个限制不仅是为了保护模型更是为了保护你的钱包。限流策略方面我的经验是要在应用层做双层限流一层针对用户维度限制单用户每分钟的请求数防止个别用户滥用另一层针对全局API配额设置整体的调用频率上限防止突发流量打爆模型API。一旦触发限流要返回明确的错误码和提示文案让前端可以友好地向用户解释“当前人多稍后再试”。4.3 一个完整的排查过程实录举个真实发生的例子我们的服务某天突然接到大量用户投诉说是回答质量明显下降。查监控发现模型接口的正常率没有异常但平均响应耗时上升了很多Token消耗也明显增加。进一步查日志发现从当天早上开始上下文系统日志里出现了大量长文本记录原因是产品侧为了提升回答质量悄悄把“返回最近20条聊天记录”改成了“返回最近两小时的全部聊天记录”。结果就是上下文越来越长每次请求的Token不断上涨响应变慢、质量反而下降因为太古老的对话内容对当前问题反而是干扰。定位很快修复也简单把上下文策略改回“限制条数加摘要压缩”响应速度立刻恢复。但这个问题给我们的教训很深AI应用的任何参数调整哪怕是产品侧觉得“无伤大雅”的改动都可能引起蝴蝶效应。所以我们后面上线了一个配置管理规范所有影响上下文、Token、模型参数的变更必须走技术评审和灰度流程。4.4 常用排查工具与指标速查表最后把常用的排查指标和工具整理成一份速查表。我每次排查问题都会先过一遍这张表大多数问题都能快速定位到方向。问题现象优先查看指标常用排查手段响应超时模型调用耗时、上下文Token数检查上下文是否超长是否有检索阶段耗时过高回答内容错误检索命中文档相关性、提示词版本检查向量检索结果得分比对提示词最近变更成本突增Token消耗趋势、单请求平均Token查看是否有循环调用、长文本注入、上下文膨胀接口被限流模型API配额用量、错误码429检查全局并发策略必要时申请提升配额幻觉明显检索阈值、文档切块边界调高相似度阈值优化切块策略用户数据串线会话隔离逻辑、缓存Key设计代码审查会话维度变量检查缓存生命周期排查AI应用的问题核心原则是先看数据再看代码。监控面板上的Token消耗趋势、模型调用耗时、检索得分分布这些数据往往比日志更能快速告诉你问题出在哪个环节。没有数据支撑的排查无异于盲目试错。我个人在实际操作中最深的体会是AI应用的生产落地难点不在模型而在模型之外的工程体系。把提示词当代码一样管理、把Token当服务器资源一样监控、把AI应用当做有“不确定性”的系统来设计才能真正把大模型的能力转化为稳定的业务价值。这一路踩过的坑很多希望这篇文章能帮你少走一些弯路。后面我再单独写写多模态场景和复杂Agent系统的落地经验到时候再来聊。