从接口开发角度理解大模型：一次请求背后发生了什么？

做 Java 后端久了以后看一个新技术时我习惯先把它拆成一次请求。用户从哪里发起请求后端接收什么参数中间调用了哪些服务数据怎么流转异常怎么处理最后返回什么结果最近学习 AI 应用开发我也在尝试用这个方式理解大模型。因为如果一上来就看模型原理、参数规模、训练数据很容易看得很远但落到业务系统里还是不知道怎么接。所以这篇不从算法角度讲大模型而是站在后端接口开发的角度聊聊一次 AI 问答请求背后大概发生了什么。先看最简单的一次调用假设我们用 Spring Boot 写了一个简单问答接口PostMapping(/chat) public ChatResponse chat(RequestBody ChatRequest request) { String answer chatService.chat(request.getQuestion()); return new ChatResponse(answer); }用户传入一个问题{ question: 请解释一下 Redis 缓存穿透是什么 }后端收到以后并不是自己去“理解”这个问题而是把问题组装成大模型接口需要的格式然后调用模型服务。大概流程是用户提问 - Spring Boot 接口接收请求 - 参数校验 - 组装 Prompt 和消息体 - 调用大模型 API - 解析模型返回 - 返回给前端这样一看大模型应用的第一层并不神秘。它首先还是一个接口调用链路。只是这次我们调用的不是支付、短信、物流而是一个能生成文本的模型服务。后端真正传给模型的不只是用户问题刚开始我以为调用模型就是把用户问题原样传过去。后来发现真实场景里后端传给模型的内容通常会更多。比如用户只问了一句帮我总结一下这份文档但模型要想回答好至少需要知道当前用户是谁用户有没有权限访问这份文档文档内容是什么希望总结成什么格式回答要长一点还是短一点有没有不能输出的内容如果文档为空或解析失败怎么办这些信息不可能都让用户自己说清楚很多需要后端补进去。所以一次请求里后端往往会把用户输入、系统规则、业务数据、历史上下文一起组装成模型能理解的内容。比如一个简单 Prompt 可能是这样你是一个 Java 后端学习助手。 请用通俗方式回答用户问题不要编造不确定的信息。 用户问题 {question}如果是知识库问答可能还要加上检索到的资料请只根据下面的资料回答问题。 如果资料中没有答案请说明暂时无法确认。 资料 {context} 用户问题 {question}从接口开发角度看Prompt 其实就是请求参数的一部分只不过它不是一个普通字段而是一段经过后端加工后的文本。大模型接口返回的是什么传统接口一般返回固定结构。比如订单查询接口返回订单号、状态、金额、时间。字段基本确定前端按字段渲染就行。但大模型接口返回的核心内容通常是一段生成文本。如果用常见的聊天接口格式返回结构可能类似{ choices: [ { message: { role: assistant, content: Redis 缓存穿透指的是... } } ] }后端需要从这个结构里取出content再返回给前端。第一版可以直接返回文本{ answer: Redis 缓存穿透指的是... }但如果做得稍微正式一点我觉得后端最好还要记录一些额外信息比如本次调用使用的模型请求耗时输入和输出长度是否命中知识库调用是否成功失败原因是什么用户 ID 和会话 ID这些信息对后面排查问题很有用。因为 AI 应用上线后常见问题不只是“接口报错”还会有“回答不准”“回答太慢”“回答格式不对”“调用费用异常”这些情况。没有日志的话很难判断问题出在哪里。一次请求里确定性和不确定性同时存在这是我觉得 AI 应用和传统 CRUD 很不一样的地方。传统后端请求大多是确定性的。代码怎么写数据是什么返回结果基本就是什么。但 AI 请求里有一部分是不确定的。确定性的部分包括用户身份校验参数校验数据库查询Redis 缓存读取知识库权限判断接口调用记录异常处理不确定的部分主要在模型生成回答。同样一个问题模型可能用不同表达回答。Prompt 改一点结果也可能变化。上下文多一点少一点也会影响最终输出。所以后端在设计 AI 接口时不能把所有事情都交给模型。比如用户问我这个订单为什么还没发货订单是否存在、当前状态是什么、有没有付款、仓库是否出库这些应该由后端查数据库确定。模型可以负责把这些信息组织成用户容易理解的话但不能让模型凭空猜订单状态。我目前比较认同一个原则事实类数据以后端系统为准表达类内容可以交给模型。这样系统边界会清楚一些。接口耗时和用户体验也要重新考虑普通 CRUD 接口我们一般希望几十毫秒到几百毫秒返回。复杂一点的查询可能一两秒也能接受。但大模型接口经常会更慢尤其是回答比较长的时候。如果后端一直等模型完整生成后再返回用户可能会觉得页面卡住了。所以很多 AI 产品会使用流式输出也就是模型生成一点前端展示一点。从后端角度看这就不再是普通的 JSON 一次性返回而可能要用 SSE 或 WebSocket。比如用户提问 - 后端调用模型流式接口 - 模型边生成边返回 - 后端边接收边推给前端 - 前端逐字或逐段展示这对后端接口设计也有影响。第一版问答接口可以先用普通 HTTP 返回完整答案简单直接。等功能跑通后再考虑流式输出。否则一开始就把链路搞复杂反而容易卡住。失败处理不能忽略做普通第三方接口接入时我们都知道要处理异常。大模型接口也一样而且异常类型可能更多。比如API Key 配错模型服务超时请求内容太长余额不足触发内容安全限制返回结构和预期不一致网络波动导致调用失败这些都需要后端兜底。至少要做到几点不把底层异常直接抛给用户记录完整调用日志给前端一个友好的错误提示对超长输入做限制对频繁请求做限流必要时提供降级方案比如模型失败时可以返回当前智能服务暂时不可用请稍后再试。而不是把一堆异常堆栈暴露出去。这些看起来不是 AI 特有能力但是真正把 AI 接进业务系统时非常重要。怎么实践接下来我准备按后端熟悉的方式把一次 AI 请求慢慢拆开做。第一步先完成最简单的 Spring Boot 问答接口用户输入问题后端调用模型返回答案。第二步加上请求日志把用户问题、模型回答、耗时、调用状态保存到 MySQL方便后面排查。第三步加上会话 ID把多轮对话记录保存起来。短期上下文可以先放 Redis长期记录再落库。第四步再接入知识库。用户提问时先从文档内容里检索相关片段再把片段和问题一起交给模型。第五步尝试流式输出让回答体验更像常见 AI 聊天产品。这样每一步都不算特别大也比较符合后端开发的节奏先把主链路跑通再逐步补日志、缓存、上下文、知识库和体验优化。最后从接口开发角度看大模型并不是一个完全摸不着的东西。它可以先被理解成一个特殊的外部服务输入是用户问题和上下文输出是一段生成文本。后端要做的是把用户请求、业务数据、系统规则整理好交给模型再把模型结果稳定地返回给用户。真正的难点不只是“调用模型”而是怎么让这次调用在业务系统里可控、可追踪、可维护。对 Java 后端来说这个切入角度会更自然一点。我们不用一开始就把自己放到算法研究的位置而是先从一次请求开始把 AI 能力接进熟悉的工程体系里。下一篇我准备继续往下走聊聊后端想做 AI 知识库需要先搞懂哪些东西