先分享一个最近的感受。过去一年里团队做技术选型时大家还会为了“用哪家大模型”争论很久。到了今年这种争论明显变少了开源模型越来越多云厂商的 API 价格一路下降甚至本地部署一个可用的大模型也变成了几十分钟就能完成的事。模型本身好像真的不再稀缺了。但与此同时真正把大模型用起来的项目并没有变得更容易。反而越来越多的团队发现模型选好了部署跑通了demo 也验证过了一到生产环境却处处卡壳。要么回答质量不稳定要么知识库里拿不到准确内容要么并发一上来推理服务就扛不住要么数据安全这一关根本过不去。这篇文章想聊一个更现实的问题当大模型不再稀缺AI 产业到底在拼什么我会从开发者和技术落地的视角把“拼部署、拼数据、拼工程、拼安全合规”这几层逐一拆开并结合本地大模型部署、RAG 数据加工、Spring AI 集成等实操案例给出可以直接参考的落地路径。无论是刚入门大模型应用开发的新手还是正在做企业级 AI 落地的后端工程师这篇文章都值得收藏备用。1. 当模型不再稀缺稀缺性转移到了哪里1.1 大模型稀缺时代已经过去过去两年大模型领域最明显的特征是“模型能力快速迭代、玩家不断增多”。一方面Llama、Qwen、DeepSeek、Mistral 等开源模型持续更新很多模型的能力已经非常接近商业闭源模型另一方面国内外云厂商都在以极低的价格提供大模型 API部分场景下甚至出现了“API 比自建推理更便宜”的情况。这个变化带来的直接结果是模型本身不再是竞争壁垒。你很难通过“我接入了某个更强的模型”来建立长期优势因为竞争对手下一周就能接入同一个模型。很多技术团队也发现两个不同的模型在通用问答上的表现差距并不大真正的差距往往出现在与具体业务结合之后。1.2 开发者的真实困境模型不再稀缺之后开发者反而陷入了新的选择困难用商业 API 还是本地部署两者的成本、数据安全、响应速度差异很大。直接让模型回答还是先做 RAG 知识库业务数据怎么变成模型能理解的内容单次调用效果不错但生产环境的稳定性、并发能力、错误处理怎么做模型输出幻觉怎么处理敏感数据怎么隔离如何满足安全合规要求这些问题没有标准答案但都指向同一个方向大模型落地真正比拼的是工程化能力。模型能力是底座但决定项目成败的往往是底座之上那层复杂繁琐的工程体系。1.3 核心竞争力转移落地能力如果把 AI 应用比作一栋楼大模型就像一个功能很强的基础建材。楼能不能盖起来、能不能抗震、能不能住得舒服取决于设计图纸、施工工艺和后期维护。对于 AI 产业来说落地的核心竞争力已经转移到四个层面部署层能不能把模型稳定、低成本地跑起来。数据层能不能把业务数据加工成大模型真正能用的知识。应用层能不能把模型能力封装成稳定可控的业务服务。安全合规层能不能保证数据安全、内容合规、权限可控。下面我们逐层展开。2. AI 产业竞争的四层战场在进入技术实操之前先用一张总览表梳理 AI 应用落地的四层战场。这张表也方便后续按图索骥。层级核心问题关键技术点常见工作部署层模型如何跑起来、跑得稳推理框架、量化、显存管理、并发优化Ollama 本地部署、vLLM 推理服务、GPU 调度数据层业务数据如何变成模型知识RAG、Embedding、知识抽取、微调数据数据库数据加工、切片向量化、知识库构建应用层如何把模型能力封装成业务服务Prompt 工程、Agent、API 集成、可观测性Spring AI 集成、工具调用、异常处理安全合规层怎么保证安全可控数据脱敏、权限隔离、内容审核、审计敏感信息过滤、模型输出审核、操作日志这四层不是先后顺序而是并行展开的。一个真正能上线的 AI 应用每一层都需要有明确设计和兜底方案。3. 拼部署从“能跑”到“跑得起、跑得稳”3.1 部署方式选择先看部署方式。目前主流的大模型接入方式有三种第一种调用公有云 API。优点是接入快、不需要 GPU 投入、按量付费缺点是数据要出域、单次调用有网络延迟、长期调用成本不确定。第二种私有化部署开源模型。优点是数据不出内网、可定制性强、长线成本可控缺点是需要 GPU 资源需要运维推理服务模型效果可能略低于闭源模型。第三种混合模式。普通问答走云 API涉及敏感数据的场景走私有化部署或者用云上专属实例。这也是很多中型企业正在采用的方案。选型建议先明确数据合规边界。如果业务数据完全不能出内网那只能私有化如果只是通用辅助场景优先用云 API 快速验证。3.2 用 Ollama 快速体验本地部署对开发者来说想要快速感受“本地跑大模型”这件事Ollama 是最省心的工具之一。它把模型下载、量化、运行封装成了几个简单命令。以 Linux 环境为例安装 Ollama 的常规命令如下curl -fsSL https://ollama.com/install.sh | sh需要注意的是直接把远程脚本通过管道交给sh执行存在一定安全风险。更稳妥的做法是先从官网下载安装脚本检查内容再手动执行。生产环境建议使用官方仓库或包管理器安装。安装完成后拉取并运行一个开源模型# 拉取 Qwen 系列模型以 7B 为例 ollama pull qwen2.5:7b # 进入交互式对话 ollama run qwen2.5:7b交互模式体验一下即可。真正开发时我们会用 HTTP API 调用curl http://localhost:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, prompt: 用一句话解释什么是 RAG, stream: false }返回结果中包含response、total_duration等字段。这里要留意本地部署 7B 级别的模型通常需要至少 8GB 显存量化版本可以低一些但速度和效果会受影响。Ollama 适合开发调试和轻量生产但如果要面对高并发通常还需要更专业的推理框架。3.3 生产环境的推理框架当模型真正面向业务流量时Ollama 往往不够用。生产环境常见的推理框架包括vLLM通过 PagedAttention 优化显存利用吞吐量高是目前开源社区使用最广的推理框架之一。TensorRT-LLMNVIDIA 生态下的推理优化方案适合对延迟要求极高的场景。SGLang在多轮对话和结构化输出场景做了优化最近社区关注度很高。以 vLLM 为例启动一个 OpenAI 兼容接口的推理服务命令大致如下python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动后客户端可以通过 OpenAI 兼容接口调用from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好请做一下自我介绍}], temperature0.7, ) print(resp.choices[0].message.content)需要提醒的是max-model-len和gpu-memory-utilization要根据实际显卡显存调整。示例中的参数不代表所有环境通用务必按自己的 GPU 配置实测。3.4 部署层真正的成本点部署层常常被低估的不是“模型能不能跑”而是“跑得是否划算”。关注以下指标首 Token 延迟用户发出请求到收到第一个字的时间影响交互体验。吞吐量每秒钟能处理多少请求或多少 Token决定服务容量。并发稳定性高并发下会不会 OOM、超时、排队堆积。显存开销包括模型权重、KV Cache、推理中间态需要整体评估。实际项目中建议先做压测再上生产不要只凭“能跑通 demo”就认为部署工作完成。4. 拼数据把业务数据变成大模型能用的知识4.1 数据工程才是大模型落地的重心模型能力同质化之后拉开差距的往往是“谁的数据加工能力更强”。同一个模型接入了企业知识库和没接知识库回答质量可能是天壤之别。这里要区分两个概念RAG检索增强生成先从知识库中检索相关内容再把检索结果拼进提示词让模型基于给定资料回答。适合知识频繁更新、要求可溯源的场景。微调Fine-tuning用业务数据继续训练模型改变模型自身的行为和知识。适合任务格式固定、要求模型风格稳定的场景。生产环境中最常见的策略是优先做 RAG微调作为补充。因为 RAG 不改变模型权重实施成本低且每次回答都能对应到具体知识来源更容易排查问题。4.2 从关系数据库到模型可读的知识文档很多企业的核心业务数据都存在关系数据库中。要让大模型理解这些数据中间需要一条完整的数据加工链路数据库数据 → 字段映射与清洗 → 生成自然语言文档 → 文档切片 → 向量化 → 存入向量数据库。下面给出一段核心加工代码的示例思路。假设我们从 MySQL 中读取一张商品表需要把每行记录转换为可检索的文本片段。import pymysql import json # 1. 从 MySQL 读取数据 conn pymysql.connect( hostlocalhost, userapp_user, passwordyour_password, databaseshop, charsetutf8mb4, ) try: with conn.cursor() as cursor: cursor.execute(SELECT id, name, category, price, description FROM products LIMIT 100) rows cursor.fetchall() columns [id, name, category, price, description] finally: conn.close() # 2. 将每一行转换为自然语言文档片段 documents [] for row in rows: item dict(zip(columns, row)) doc ( f商品ID{item[id]} f名称{item[name]} f分类{item[category]} f价格{item[price]}元 f描述{item[description]} ) documents.append({id: item[id], text: doc}) # 3. 保存为 JSON Lines方便后续向量化 with open(product_docs.jsonl, w, encodingutf-8) as f: for doc in documents: f.write(json.dumps(doc, ensure_asciiFalse) \n) print(f共生成 {len(documents)} 条文档)这段代码的核心思想是不要把原始表结构直接丢给模型而是把关系型数据“翻译”成模型更容易理解的叙述型文本。字段命名、单位、上下文关系都在这一步补全。4.3 文本切片与向量化上一步生成的文档可能很长需要先切片再向量化。切片策略直接影响检索效果。def chunk_text(text, chunk_size500, overlap50): 按固定长度切片并保留 overlap 上下文重叠。 实际项目中还需考虑按段落、标题、语义边界等切分。 if len(text) chunk_size: return [text] chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] chunks.append(chunk) if end len(text): break start end - overlap return chunks sample 这是一段较长的商品描述…… # 替换为实际文档 print(chunk_text(sample, chunk_size200, overlap20))切片之后调用 Embedding 模型将每个切片转为向量再写入向量数据库。常见选择包括 Chroma、Milvus、Qdrant、Weaviate以及 Elasticsearch 的向量检索能力。向量库选型要考虑数据规模、检索性能、部署成本和团队维护能力。4.4 知识抽取与微调数据准备除了 RAG知识抽取也是数据加工的重要方向。像 OneKE 这类知识抽取框架可以从非结构化文本中提取实体、关系、事件帮助企业构建知识图谱或结构化知识库。这类工具特别适合“文档中有大量隐性知识需要先结构化才能使用”的场景。做微调时数据质量远比数据数量重要。一般建议准备数千条高质量“指令-回答”对即可启动第一轮微调。每条样本要确保指令清晰任务边界明确。回答正确、格式统一。不包含敏感信息或错误知识。覆盖业务的典型边界场景。5. 拼工程从单个模型到稳定系统5.1 大模型应用的分层架构一个可上线的 AI 应用不会只有一个模型调用接口。它是分层协作的系统接入层负责请求鉴权、限流、参数校验。业务编排层负责调用模型、检索知识库、处理工具调用、组装 Prompt。模型层负责实际的推理可能是本地部署也可能是云 API。数据层包括向量数据库、业务数据库、缓存。可观测层负责日志、监控、链路追踪、质量评估。这就像我们写传统后端时不会把所有逻辑塞进 Controller 一样AI 应用也需要清晰分层否则后期维护会非常痛苦。5.2 用 Spring AI 集成大模型对于 Java 后端团队Spring AI 是一个非常值得关注的集成方案。它把“模型调用、Prompt 管理、结构化输出、工具调用”等封装成了 Spring 风格的模式对熟悉 Spring Boot 的开发者非常友好。在pom.xml中添加依赖版本按项目实际情况选择dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId version${spring-ai.version}/version /dependency在application.yml中配置模型地址和密钥密钥通过环境变量注入不要写死在代码里spring: ai: openai: api-key: ${OPENAI_API_KEY} base-url: ${OPENAI_BASE_URL} chat: options: model: gpt-4o-mini temperature: 0.7编写一个简单的 Chat 接口// 文件路径src/main/java/com/example/aidemo/controller/ChatController.java package com.example.aidemo.controller; import org.springframework.ai.chat.client.ChatClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController RequestMapping(/ai) public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String message) { return chatClient.prompt() .user(message) .call() .content(); } }这段代码实现了一个最简单的模型调用接口。Controller 层不包含任何业务逻辑只负责参数接收和结果返回。后续如果要加知识库检索、会话记忆、工具调用都放在 Service 层完成。5.3 Prompt 工程与结构化输出Prompt 是应用层最容易被忽视的“代码”。同一个模型Prompt 写得不同效果可能天差地别。实际工程中Prompt 应该像代码一样被管理起来。建议将 Prompt 模板与代码分离存放在独立配置或数据库中。定义输入变量、输出格式、边界条件。为重要 Prompt 建立版本记录。用测试集评估 Prompt 调整前后的效果变化。下面是一个带结构化输出的示例思路prompt 你是一个商品推荐助手。请根据用户描述推荐商品。 用户描述{user_input} 请按 JSON 格式回复包含以下字段 - name: 推荐商品名称 - reason: 推荐理由不超过50字 只输出 JSON不要输出其他内容。 结构化输出非常重要因为生产系统需要稳定地解析模型返回值。很多推理框架已经支持 JSON Mode、函数调用等机制建议优先使用。5.4 Agent 与工具调用当模型需要完成“查询天气、查数据库、调用业务接口”等复合任务时就需要引入 Agent 机制。核心思路是模型自己决定调用哪个工具、传什么参数再根据工具返回结果继续推理。Agent 工程化的关键在于工具描述要清晰模型才能准确选择。工具参数要有严格校验不能信任模型生成的参数。每次工具调用都要记录日志便于追溯。设置最大调用轮数避免死循环。考虑工具调用失败时的重试与降级策略。5.5 可观测性与稳定性上线之后必须回答几个问题每次请求调用了哪个模型消耗了多少 TokenPrompt 最终是什么内容模型返回了什么哪些请求超时哪些请求被限流模型回答的质量如何如何评估建议至少做到全链路日志记录请求参数、Prompt 最终内容、模型返回值、耗时、Token 消耗量。监控指标请求量、成功率、平均延迟、Token 消耗量、成本估算。限流与降级模型服务异常时返回兜底文案而不是直接报错。灰度发布Prompt 修改、模型切换、参数调整都先灰度再全量。6. 常见问题与排查思路6.1 问题排查速查表以下是大模型应用开发中最常遇到的一批问题整理成表格方便快速定位。问题现象常见原因解决思路模型回答不稳定同一问题结果波动大温度参数过高降低 temperature如从 1.0 降到 0.3回答内容与知识库不符RAG 检索到了错误片段检查切片质量、向量相似度阈值、TopK 参数上下文一长就报错超过模型最大上下文长度控制提示词长度增加摘要压缩改用长上下文模型本地部署时显存不足模型参数量大或 KV Cache 占用高换量化版本、减少并发、调低 max-model-len、换更大显存API 调用频繁超时网络延迟或服务端排队增加超时时间、接入重试机制、降低并发知识库回答“一本正经胡说八道”模型幻觉强制“基于给定资料回答”检索不到就明确拒绝回答Prompt 越长费用越高Token 消耗过大精简 Prompt、做相关片段动态装载、只传必要的上下文6.2 一个典型问题的复现与修复以“RAG 回答不准确”为例细看一下排查思路。第一步确认模型是否真的看到了正确资料。把最终发送给模型的完整 Prompt 打印出来人工检查检索到的资料片段与问题是否相关。很多时候问题出在检索阶段而不是生成阶段。第二步检查切片策略。如果切片过短一段完整知识被切碎语义不完整如果切片过长混入大量无关内容干扰模型判断。可以尝试按章节、段落、句群等语义边界切分。第三步检查检索参数。向量检索通常有 TopK、相似度阈值等参数。TopK 过大容易混入噪声TopK 过小可能漏掉关键信息。第四步优化 Prompt 约束。在 Prompt 中明确要求“只基于以下资料回答不要使用资料之外的知识如果资料中没有答案直接回答不知道”。这个排查顺序基本遵循“从输入侧到生成侧”的思路能覆盖绝大多数 RAG 效果不佳的问题。7. 最佳实践与工程建议7.1 模型选型模型选型不要盲目追求“最强”而是根据场景匹配简单文本分类、信息抽取小模型即可成本低、延迟低。复杂推理、长文档分析需要用强模型。涉及敏感数据优先私有化部署。对延迟敏感本地部署或选择响应快的云 API。同时建立一个模型效果评估集用真实的业务问题去评估候选模型而不是凭网上评测选型。7.2 先从 RAG 开始谨慎微调RAG 实施成本低、可回滚、可溯源是所有知识密集场景的首选。微调适合以下场景需要模型稳定输出特定风格或格式。模型已经组织好了知识但回答格式始终不符合要求。有大量高质量的“输入-输出”样本。不要在微调之前先用脏数据或小样本硬试。微调是一场“高成本、难回滚”的操作必须重视数据质量和评估流程。7.3 数据安全与权限隔离大模型应用涉及的数据安全问题必须在架构设计阶段就考虑敏感数据在传输和存储时加密。数据库账号遵循最小权限原则AI 服务只读必要的表。用户上传的文档要有访问权限控制不能让用户 A 通过知识库检索到用户 B 的隐私数据。模型输出要做内容安全过滤防止生成违法违规内容。所有推理调用记录操作日志便于审计追溯。涉及生产环境数据变更时必须先备份、先在测试环境验证再执行变更。7.4 建立评估体系没有评估体系的大模型应用都是在“盲调”。建议从第一天就建立准备 100~200 条真实业务问题作为测试集。每个问题标注期望答案或关键要点。每次修改 Prompt、换模型、调整切片策略都跑一遍测试集。记录通过率变化用数据说话而不是凭感觉判断效果好坏。评估体系积累起来后你会发现大模型调试开始变得“可预期”了。7.5 成本控制大模型应用的成本不止是 API 调用费还包括 GPU 资源、数据加工、人工调试成本。控制成本的手段包括用轻量模型做简单任务强模型只处理复杂任务。缓存相似问题的回答减少重复计算。控制上下文长度避免无意义地引入大量历史信息。本地部署时通过量化、批量推理、任务调度提升 GPU 利用率。8. 总结与后续学习路线回到文章标题的问题当大模型不再稀缺AI 产业在拼什么答案是拼更底层、更细碎的工程能力——把模型稳定地部署起来把业务数据加工成模型可用的知识把单次模型调用封装成可靠的生产服务把数据安全与合规落实到每一个环节。模型能力只是起点真正的竞争从模型选完之后才刚开始。对于刚接触大模型开发的同学建议按下面的路线继续深入先用 Ollama 本地跑通一个小模型感受推理过程。掌握 Prompt 工程基础学会用结构化输出。动手实现一个最小 RAG 流程理解切片、向量化、检索、生成。学习 Spring AI、LangChain4j 等框架了解工程化集成方式。研究 vLLM 等推理框架理解部署层的性能与成本。建立效果评估体系让调试变得可量化。如果你也在做类似的大模型落地评估我的建议是不要一上来就追求“最强模型”或“全面微调”而是从一个具体的小场景开始把“数据加载 → 知识检索 → 模型生成 → 效果评估”这条链路完整跑通。这个过程中踩到的每一个坑积累下来的每一份经验才是 AI 产业真正稀缺的东西。如果这篇文章对你有帮助欢迎收藏备用。你也可以在评论区聊聊你在落地大模型时遇到的最棘手的问题大家一起讨论。 大模型不再稀缺，AI产业在拼什么？落地四层战场全解析
先分享一个最近的感受。过去一年里团队做技术选型时大家还会为了“用哪家大模型”争论很久。到了今年这种争论明显变少了开源模型越来越多云厂商的 API 价格一路下降甚至本地部署一个可用的大模型也变成了几十分钟就能完成的事。模型本身好像真的不再稀缺了。但与此同时真正把大模型用起来的项目并没有变得更容易。反而越来越多的团队发现模型选好了部署跑通了demo 也验证过了一到生产环境却处处卡壳。要么回答质量不稳定要么知识库里拿不到准确内容要么并发一上来推理服务就扛不住要么数据安全这一关根本过不去。这篇文章想聊一个更现实的问题当大模型不再稀缺AI 产业到底在拼什么我会从开发者和技术落地的视角把“拼部署、拼数据、拼工程、拼安全合规”这几层逐一拆开并结合本地大模型部署、RAG 数据加工、Spring AI 集成等实操案例给出可以直接参考的落地路径。无论是刚入门大模型应用开发的新手还是正在做企业级 AI 落地的后端工程师这篇文章都值得收藏备用。1. 当模型不再稀缺稀缺性转移到了哪里1.1 大模型稀缺时代已经过去过去两年大模型领域最明显的特征是“模型能力快速迭代、玩家不断增多”。一方面Llama、Qwen、DeepSeek、Mistral 等开源模型持续更新很多模型的能力已经非常接近商业闭源模型另一方面国内外云厂商都在以极低的价格提供大模型 API部分场景下甚至出现了“API 比自建推理更便宜”的情况。这个变化带来的直接结果是模型本身不再是竞争壁垒。你很难通过“我接入了某个更强的模型”来建立长期优势因为竞争对手下一周就能接入同一个模型。很多技术团队也发现两个不同的模型在通用问答上的表现差距并不大真正的差距往往出现在与具体业务结合之后。1.2 开发者的真实困境模型不再稀缺之后开发者反而陷入了新的选择困难用商业 API 还是本地部署两者的成本、数据安全、响应速度差异很大。直接让模型回答还是先做 RAG 知识库业务数据怎么变成模型能理解的内容单次调用效果不错但生产环境的稳定性、并发能力、错误处理怎么做模型输出幻觉怎么处理敏感数据怎么隔离如何满足安全合规要求这些问题没有标准答案但都指向同一个方向大模型落地真正比拼的是工程化能力。模型能力是底座但决定项目成败的往往是底座之上那层复杂繁琐的工程体系。1.3 核心竞争力转移落地能力如果把 AI 应用比作一栋楼大模型就像一个功能很强的基础建材。楼能不能盖起来、能不能抗震、能不能住得舒服取决于设计图纸、施工工艺和后期维护。对于 AI 产业来说落地的核心竞争力已经转移到四个层面部署层能不能把模型稳定、低成本地跑起来。数据层能不能把业务数据加工成大模型真正能用的知识。应用层能不能把模型能力封装成稳定可控的业务服务。安全合规层能不能保证数据安全、内容合规、权限可控。下面我们逐层展开。2. AI 产业竞争的四层战场在进入技术实操之前先用一张总览表梳理 AI 应用落地的四层战场。这张表也方便后续按图索骥。层级核心问题关键技术点常见工作部署层模型如何跑起来、跑得稳推理框架、量化、显存管理、并发优化Ollama 本地部署、vLLM 推理服务、GPU 调度数据层业务数据如何变成模型知识RAG、Embedding、知识抽取、微调数据数据库数据加工、切片向量化、知识库构建应用层如何把模型能力封装成业务服务Prompt 工程、Agent、API 集成、可观测性Spring AI 集成、工具调用、异常处理安全合规层怎么保证安全可控数据脱敏、权限隔离、内容审核、审计敏感信息过滤、模型输出审核、操作日志这四层不是先后顺序而是并行展开的。一个真正能上线的 AI 应用每一层都需要有明确设计和兜底方案。3. 拼部署从“能跑”到“跑得起、跑得稳”3.1 部署方式选择先看部署方式。目前主流的大模型接入方式有三种第一种调用公有云 API。优点是接入快、不需要 GPU 投入、按量付费缺点是数据要出域、单次调用有网络延迟、长期调用成本不确定。第二种私有化部署开源模型。优点是数据不出内网、可定制性强、长线成本可控缺点是需要 GPU 资源需要运维推理服务模型效果可能略低于闭源模型。第三种混合模式。普通问答走云 API涉及敏感数据的场景走私有化部署或者用云上专属实例。这也是很多中型企业正在采用的方案。选型建议先明确数据合规边界。如果业务数据完全不能出内网那只能私有化如果只是通用辅助场景优先用云 API 快速验证。3.2 用 Ollama 快速体验本地部署对开发者来说想要快速感受“本地跑大模型”这件事Ollama 是最省心的工具之一。它把模型下载、量化、运行封装成了几个简单命令。以 Linux 环境为例安装 Ollama 的常规命令如下curl -fsSL https://ollama.com/install.sh | sh需要注意的是直接把远程脚本通过管道交给sh执行存在一定安全风险。更稳妥的做法是先从官网下载安装脚本检查内容再手动执行。生产环境建议使用官方仓库或包管理器安装。安装完成后拉取并运行一个开源模型# 拉取 Qwen 系列模型以 7B 为例 ollama pull qwen2.5:7b # 进入交互式对话 ollama run qwen2.5:7b交互模式体验一下即可。真正开发时我们会用 HTTP API 调用curl http://localhost:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, prompt: 用一句话解释什么是 RAG, stream: false }返回结果中包含response、total_duration等字段。这里要留意本地部署 7B 级别的模型通常需要至少 8GB 显存量化版本可以低一些但速度和效果会受影响。Ollama 适合开发调试和轻量生产但如果要面对高并发通常还需要更专业的推理框架。3.3 生产环境的推理框架当模型真正面向业务流量时Ollama 往往不够用。生产环境常见的推理框架包括vLLM通过 PagedAttention 优化显存利用吞吐量高是目前开源社区使用最广的推理框架之一。TensorRT-LLMNVIDIA 生态下的推理优化方案适合对延迟要求极高的场景。SGLang在多轮对话和结构化输出场景做了优化最近社区关注度很高。以 vLLM 为例启动一个 OpenAI 兼容接口的推理服务命令大致如下python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动后客户端可以通过 OpenAI 兼容接口调用from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好请做一下自我介绍}], temperature0.7, ) print(resp.choices[0].message.content)需要提醒的是max-model-len和gpu-memory-utilization要根据实际显卡显存调整。示例中的参数不代表所有环境通用务必按自己的 GPU 配置实测。3.4 部署层真正的成本点部署层常常被低估的不是“模型能不能跑”而是“跑得是否划算”。关注以下指标首 Token 延迟用户发出请求到收到第一个字的时间影响交互体验。吞吐量每秒钟能处理多少请求或多少 Token决定服务容量。并发稳定性高并发下会不会 OOM、超时、排队堆积。显存开销包括模型权重、KV Cache、推理中间态需要整体评估。实际项目中建议先做压测再上生产不要只凭“能跑通 demo”就认为部署工作完成。4. 拼数据把业务数据变成大模型能用的知识4.1 数据工程才是大模型落地的重心模型能力同质化之后拉开差距的往往是“谁的数据加工能力更强”。同一个模型接入了企业知识库和没接知识库回答质量可能是天壤之别。这里要区分两个概念RAG检索增强生成先从知识库中检索相关内容再把检索结果拼进提示词让模型基于给定资料回答。适合知识频繁更新、要求可溯源的场景。微调Fine-tuning用业务数据继续训练模型改变模型自身的行为和知识。适合任务格式固定、要求模型风格稳定的场景。生产环境中最常见的策略是优先做 RAG微调作为补充。因为 RAG 不改变模型权重实施成本低且每次回答都能对应到具体知识来源更容易排查问题。4.2 从关系数据库到模型可读的知识文档很多企业的核心业务数据都存在关系数据库中。要让大模型理解这些数据中间需要一条完整的数据加工链路数据库数据 → 字段映射与清洗 → 生成自然语言文档 → 文档切片 → 向量化 → 存入向量数据库。下面给出一段核心加工代码的示例思路。假设我们从 MySQL 中读取一张商品表需要把每行记录转换为可检索的文本片段。import pymysql import json # 1. 从 MySQL 读取数据 conn pymysql.connect( hostlocalhost, userapp_user, passwordyour_password, databaseshop, charsetutf8mb4, ) try: with conn.cursor() as cursor: cursor.execute(SELECT id, name, category, price, description FROM products LIMIT 100) rows cursor.fetchall() columns [id, name, category, price, description] finally: conn.close() # 2. 将每一行转换为自然语言文档片段 documents [] for row in rows: item dict(zip(columns, row)) doc ( f商品ID{item[id]} f名称{item[name]} f分类{item[category]} f价格{item[price]}元 f描述{item[description]} ) documents.append({id: item[id], text: doc}) # 3. 保存为 JSON Lines方便后续向量化 with open(product_docs.jsonl, w, encodingutf-8) as f: for doc in documents: f.write(json.dumps(doc, ensure_asciiFalse) \n) print(f共生成 {len(documents)} 条文档)这段代码的核心思想是不要把原始表结构直接丢给模型而是把关系型数据“翻译”成模型更容易理解的叙述型文本。字段命名、单位、上下文关系都在这一步补全。4.3 文本切片与向量化上一步生成的文档可能很长需要先切片再向量化。切片策略直接影响检索效果。def chunk_text(text, chunk_size500, overlap50): 按固定长度切片并保留 overlap 上下文重叠。 实际项目中还需考虑按段落、标题、语义边界等切分。 if len(text) chunk_size: return [text] chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] chunks.append(chunk) if end len(text): break start end - overlap return chunks sample 这是一段较长的商品描述…… # 替换为实际文档 print(chunk_text(sample, chunk_size200, overlap20))切片之后调用 Embedding 模型将每个切片转为向量再写入向量数据库。常见选择包括 Chroma、Milvus、Qdrant、Weaviate以及 Elasticsearch 的向量检索能力。向量库选型要考虑数据规模、检索性能、部署成本和团队维护能力。4.4 知识抽取与微调数据准备除了 RAG知识抽取也是数据加工的重要方向。像 OneKE 这类知识抽取框架可以从非结构化文本中提取实体、关系、事件帮助企业构建知识图谱或结构化知识库。这类工具特别适合“文档中有大量隐性知识需要先结构化才能使用”的场景。做微调时数据质量远比数据数量重要。一般建议准备数千条高质量“指令-回答”对即可启动第一轮微调。每条样本要确保指令清晰任务边界明确。回答正确、格式统一。不包含敏感信息或错误知识。覆盖业务的典型边界场景。5. 拼工程从单个模型到稳定系统5.1 大模型应用的分层架构一个可上线的 AI 应用不会只有一个模型调用接口。它是分层协作的系统接入层负责请求鉴权、限流、参数校验。业务编排层负责调用模型、检索知识库、处理工具调用、组装 Prompt。模型层负责实际的推理可能是本地部署也可能是云 API。数据层包括向量数据库、业务数据库、缓存。可观测层负责日志、监控、链路追踪、质量评估。这就像我们写传统后端时不会把所有逻辑塞进 Controller 一样AI 应用也需要清晰分层否则后期维护会非常痛苦。5.2 用 Spring AI 集成大模型对于 Java 后端团队Spring AI 是一个非常值得关注的集成方案。它把“模型调用、Prompt 管理、结构化输出、工具调用”等封装成了 Spring 风格的模式对熟悉 Spring Boot 的开发者非常友好。在pom.xml中添加依赖版本按项目实际情况选择dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId version${spring-ai.version}/version /dependency在application.yml中配置模型地址和密钥密钥通过环境变量注入不要写死在代码里spring: ai: openai: api-key: ${OPENAI_API_KEY} base-url: ${OPENAI_BASE_URL} chat: options: model: gpt-4o-mini temperature: 0.7编写一个简单的 Chat 接口// 文件路径src/main/java/com/example/aidemo/controller/ChatController.java package com.example.aidemo.controller; import org.springframework.ai.chat.client.ChatClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController RequestMapping(/ai) public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String message) { return chatClient.prompt() .user(message) .call() .content(); } }这段代码实现了一个最简单的模型调用接口。Controller 层不包含任何业务逻辑只负责参数接收和结果返回。后续如果要加知识库检索、会话记忆、工具调用都放在 Service 层完成。5.3 Prompt 工程与结构化输出Prompt 是应用层最容易被忽视的“代码”。同一个模型Prompt 写得不同效果可能天差地别。实际工程中Prompt 应该像代码一样被管理起来。建议将 Prompt 模板与代码分离存放在独立配置或数据库中。定义输入变量、输出格式、边界条件。为重要 Prompt 建立版本记录。用测试集评估 Prompt 调整前后的效果变化。下面是一个带结构化输出的示例思路prompt 你是一个商品推荐助手。请根据用户描述推荐商品。 用户描述{user_input} 请按 JSON 格式回复包含以下字段 - name: 推荐商品名称 - reason: 推荐理由不超过50字 只输出 JSON不要输出其他内容。 结构化输出非常重要因为生产系统需要稳定地解析模型返回值。很多推理框架已经支持 JSON Mode、函数调用等机制建议优先使用。5.4 Agent 与工具调用当模型需要完成“查询天气、查数据库、调用业务接口”等复合任务时就需要引入 Agent 机制。核心思路是模型自己决定调用哪个工具、传什么参数再根据工具返回结果继续推理。Agent 工程化的关键在于工具描述要清晰模型才能准确选择。工具参数要有严格校验不能信任模型生成的参数。每次工具调用都要记录日志便于追溯。设置最大调用轮数避免死循环。考虑工具调用失败时的重试与降级策略。5.5 可观测性与稳定性上线之后必须回答几个问题每次请求调用了哪个模型消耗了多少 TokenPrompt 最终是什么内容模型返回了什么哪些请求超时哪些请求被限流模型回答的质量如何如何评估建议至少做到全链路日志记录请求参数、Prompt 最终内容、模型返回值、耗时、Token 消耗量。监控指标请求量、成功率、平均延迟、Token 消耗量、成本估算。限流与降级模型服务异常时返回兜底文案而不是直接报错。灰度发布Prompt 修改、模型切换、参数调整都先灰度再全量。6. 常见问题与排查思路6.1 问题排查速查表以下是大模型应用开发中最常遇到的一批问题整理成表格方便快速定位。问题现象常见原因解决思路模型回答不稳定同一问题结果波动大温度参数过高降低 temperature如从 1.0 降到 0.3回答内容与知识库不符RAG 检索到了错误片段检查切片质量、向量相似度阈值、TopK 参数上下文一长就报错超过模型最大上下文长度控制提示词长度增加摘要压缩改用长上下文模型本地部署时显存不足模型参数量大或 KV Cache 占用高换量化版本、减少并发、调低 max-model-len、换更大显存API 调用频繁超时网络延迟或服务端排队增加超时时间、接入重试机制、降低并发知识库回答“一本正经胡说八道”模型幻觉强制“基于给定资料回答”检索不到就明确拒绝回答Prompt 越长费用越高Token 消耗过大精简 Prompt、做相关片段动态装载、只传必要的上下文6.2 一个典型问题的复现与修复以“RAG 回答不准确”为例细看一下排查思路。第一步确认模型是否真的看到了正确资料。把最终发送给模型的完整 Prompt 打印出来人工检查检索到的资料片段与问题是否相关。很多时候问题出在检索阶段而不是生成阶段。第二步检查切片策略。如果切片过短一段完整知识被切碎语义不完整如果切片过长混入大量无关内容干扰模型判断。可以尝试按章节、段落、句群等语义边界切分。第三步检查检索参数。向量检索通常有 TopK、相似度阈值等参数。TopK 过大容易混入噪声TopK 过小可能漏掉关键信息。第四步优化 Prompt 约束。在 Prompt 中明确要求“只基于以下资料回答不要使用资料之外的知识如果资料中没有答案直接回答不知道”。这个排查顺序基本遵循“从输入侧到生成侧”的思路能覆盖绝大多数 RAG 效果不佳的问题。7. 最佳实践与工程建议7.1 模型选型模型选型不要盲目追求“最强”而是根据场景匹配简单文本分类、信息抽取小模型即可成本低、延迟低。复杂推理、长文档分析需要用强模型。涉及敏感数据优先私有化部署。对延迟敏感本地部署或选择响应快的云 API。同时建立一个模型效果评估集用真实的业务问题去评估候选模型而不是凭网上评测选型。7.2 先从 RAG 开始谨慎微调RAG 实施成本低、可回滚、可溯源是所有知识密集场景的首选。微调适合以下场景需要模型稳定输出特定风格或格式。模型已经组织好了知识但回答格式始终不符合要求。有大量高质量的“输入-输出”样本。不要在微调之前先用脏数据或小样本硬试。微调是一场“高成本、难回滚”的操作必须重视数据质量和评估流程。7.3 数据安全与权限隔离大模型应用涉及的数据安全问题必须在架构设计阶段就考虑敏感数据在传输和存储时加密。数据库账号遵循最小权限原则AI 服务只读必要的表。用户上传的文档要有访问权限控制不能让用户 A 通过知识库检索到用户 B 的隐私数据。模型输出要做内容安全过滤防止生成违法违规内容。所有推理调用记录操作日志便于审计追溯。涉及生产环境数据变更时必须先备份、先在测试环境验证再执行变更。7.4 建立评估体系没有评估体系的大模型应用都是在“盲调”。建议从第一天就建立准备 100~200 条真实业务问题作为测试集。每个问题标注期望答案或关键要点。每次修改 Prompt、换模型、调整切片策略都跑一遍测试集。记录通过率变化用数据说话而不是凭感觉判断效果好坏。评估体系积累起来后你会发现大模型调试开始变得“可预期”了。7.5 成本控制大模型应用的成本不止是 API 调用费还包括 GPU 资源、数据加工、人工调试成本。控制成本的手段包括用轻量模型做简单任务强模型只处理复杂任务。缓存相似问题的回答减少重复计算。控制上下文长度避免无意义地引入大量历史信息。本地部署时通过量化、批量推理、任务调度提升 GPU 利用率。8. 总结与后续学习路线回到文章标题的问题当大模型不再稀缺AI 产业在拼什么答案是拼更底层、更细碎的工程能力——把模型稳定地部署起来把业务数据加工成模型可用的知识把单次模型调用封装成可靠的生产服务把数据安全与合规落实到每一个环节。模型能力只是起点真正的竞争从模型选完之后才刚开始。对于刚接触大模型开发的同学建议按下面的路线继续深入先用 Ollama 本地跑通一个小模型感受推理过程。掌握 Prompt 工程基础学会用结构化输出。动手实现一个最小 RAG 流程理解切片、向量化、检索、生成。学习 Spring AI、LangChain4j 等框架了解工程化集成方式。研究 vLLM 等推理框架理解部署层的性能与成本。建立效果评估体系让调试变得可量化。如果你也在做类似的大模型落地评估我的建议是不要一上来就追求“最强模型”或“全面微调”而是从一个具体的小场景开始把“数据加载 → 知识检索 → 模型生成 → 效果评估”这条链路完整跑通。这个过程中踩到的每一个坑积累下来的每一份经验才是 AI 产业真正稀缺的东西。如果这篇文章对你有帮助欢迎收藏备用。你也可以在评论区聊聊你在落地大模型时遇到的最棘手的问题大家一起讨论。