大模型接入业务系统：API、本地部署、RAG、智能体四种路线怎么选

前言

上个月有个做 ERP 的老客户找我，说老板拍板要"上大模型"，预算批了三十万，让我给个方案。我问了一句：你们到底想让模型干什么？对方愣了半天，说"就是......智能化一点"。

这场景我见得太多了。业务系统接大模型，最怕的不是技术难，是路线选错------钱花了，Demo 跑通了，一上生产全是坑。这篇文章就把我们团队这两年落地的四种路线掰开揉碎讲清楚：直接调 API、本地私有化部署、RAG 知识增强、智能体编排。适合正在做技术选型的后端和架构同学，看完你至少能判断自己项目该走哪条路，以及每条路上埋着什么雷。

先给结论：没有最好的路线，只有匹配业务约束的路线。约束是什么？数据能不能出内网、调用量多大、知识更新频率、要不要调外部工具。这四个问题答完，路线基本就定了。

问题背景

去年我们接了个政企项目，客户要求所有数据不出内网，结果方案里写了"调用公有云 API"，评审直接被毙。同一个季度，另一个做电商的客户，日调用量大概两万次，非要上本地部署，买了两张 A100，算下来一年折旧加电费比调 API 贵了快四倍，模型效果还没公有云的好。

说白了，很多团队把"接大模型"当成一个技术动作，其实它是个架构决策。决策错了，后面全是返工。

我们内部一般按这几个维度打分：数据敏感度、QPS 与并发、知识时效性、任务复杂度、预算。下面四种路线，我按这个框架逐个说。

原理：四条路线到底差在哪

先上一张我们内部用的对比图，横轴是数据可控性，纵轴是落地复杂度：

复制代码

落地复杂度
  高 │        智能体编排
     │              ●
     │   本地部署
     │      ●        RAG增强
     │                 ●
  低 │  API调用
     │    ●
     └──────────────────────→ 数据可控性
        低              高

API 调用：最轻。业务系统发 HTTP 请求到模型厂商，拿回结果。数据出网，但延迟低、免运维、模型能力强。

本地部署：把开源模型（DeepSeek、Qwen 这类）用 vLLM 或 Ollama 跑在自己机房。数据不出内网，但要自己扛 GPU、显存、推理优化。

RAG 知识增强：本质是"检索 + 生成"。用户问题先向量化，去知识库捞相关片段，拼进 Prompt 再让模型回答。解决的是模型不知道你企业内部文档的问题。

智能体编排：让模型自己决定调哪个工具、走几步。适合多步骤任务，比如"查订单→判断是否超期→生成催办话术→发消息"。复杂度最高，调试最痛苦。

实操：四种路线的落地代码

路线一：API 调用（最快出活）

我们一般封装一层统一网关，方便后面换厂商。核心就是别把厂商 SDK 散落在业务代码里。

java 复制代码

@Service
public class LlmGateway {
    @Value("${llm.api-key}")
    private String apiKey;

    private final RestTemplate restTemplate = new RestTemplate();

    public String chat(String prompt) {
        HttpHeaders headers = new HttpHeaders();
        headers.setBearerAuth(apiKey);
        headers.setContentType(MediaType.APPLICATION_JSON);

        Map<String, Object> body = Map.of(
            "model", "deepseek-chat",
            "messages", List.of(Map.of("role", "user", "content", prompt)),
            "temperature", 0.3
        );

        ResponseEntity<Map> resp = restTemplate.postForEntity(
            "https://api.deepseek.com/v1/chat/completions",
            new HttpEntity<>(body, headers), Map.class);

        List<Map> choices = (List<Map>) resp.getBody().get("choices");
        return (String) ((Map) choices.get(0).get("message")).get("content");
    }
}

注意 temperature 我给的是 0.3，业务系统里生成结构化内容别用默认值，不然同一句话每次输出格式都不一样，下游解析能把你逼疯。

路线二：本地部署（数据不出门）

参考我们之前给一个制造企业做的内网方案，用 vLLM 起服务：

bash 复制代码

python -m vllm.entrypoints.openai.api_server \
  --model /data/models/DeepSeek-R1-Distill-Qwen-14B \
  --served-model-name deepseek-14b \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --port 8000

起完之后接口协议和 OpenAI 兼容，业务侧代码几乎不用改，把 base_url 指到内网 IP 就行。这是本地部署最舒服的一点。

显存这块给个经验值：14B 模型 FP16 大概要 28G 显存，两张 24G 卡做张量并行够用；如果上 32B，至少四张 A100 80G，别信网上"单卡能跑"的说法，跑得起来和跑得动是两码事。

路线三：RAG（让模型懂你的业务）

RAG 的坑八成在检索质量上，不在生成。我们一般用 pgvector 存向量，检索时加个相似度阈值过滤：

python 复制代码

from langchain_community.vectorstores import PGVector
from langchain_openai import OpenAIEmbeddings

store = PGVector(
    connection_string="postgresql+psycopg://user:pwd@10.0.0.12:5432/kb",
    embedding_function=OpenAIEmbeddings(model="bge-m3"),
    collection_name="product_docs"
)

def retrieve(question, k=4, threshold=0.72):
    docs = store.similarity_search_with_score(question, k=k)
    # 分数越低越相似，过滤掉明显不相关的
    return [d.page_content for d, score in docs if score < threshold]

那个 threshold 是调出来的，不是拍脑袋。我们一开始设 0.8，结果召回太少，模型经常说"资料里没有"；放到 0.6 又混进一堆无关片段，答案开始胡编。最后在 0.72 附近稳住了。

路线四：智能体编排（多步骤任务）

这块我们踩坑最多。给个最小可用的工具调用示例：

python 复制代码

tools = [
    {"type": "function", "function": {
        "name": "query_order",
        "description": "根据订单号查询订单状态",
        "parameters": {"type": "object",
            "properties": {"order_no": {"type": "string"}},
            "required": ["order_no"]}
    }}
]

resp = client.chat.completions.create(
    model="deepseek-chat", messages=messages, tools=tools,
    tool_choice="auto"
)

关键在 description 要写清楚，模型靠它判断该不该调。我们有个工具描述写得太含糊，模型十次有三次调错，改成"仅在用户明确提供订单号时调用"之后才稳。

踩坑

坑一：试用版和正式版的差距。 这个跟 SaaS 试用一个道理。某厂商 API 试用时并发随便打，签完合同发现 QPS 限到 5，超了直接 429。上线前一定拿正式 key 压测一遍。

坑二：本地部署的"能跑"陷阱。 有个客户坚持用消费级显卡跑 32B，Demo 演示时一次只来一个请求，看着挺流畅；生产环境二十个人同时用，首 token 延迟飙到十几秒。并发和单请求是两回事。

坑三：RAG 的知识库没人维护。 文档三个月不更新，模型答的全是过期政策。我们后来加了个定时任务，文档变更自动重新向量化，不然知识库就是个摆设。

坑四：智能体死循环。 模型调工具失败会重试，没设最大步数能一直转下去，账单也跟着转。一定要设 max_iterations，我们设的 6。

坑五：合规。 AI 生成内容商用涉及版权和标识问题，政企客户尤其在意。这块法务得提前介入，别等上线了才补。

总结

回到开头那个 ERP 客户，最后我们给的方案是：核心业务数据走本地部署的小模型做分类和抽取，非敏感的客服问答走 API，知识库用 RAG，暂时不上智能体。三十万预算花了一半，留了余量。

选路线就一句话：数据敏感看部署，知识时效看 RAG，任务复杂看编排，预算紧张看 API。四个约束排个优先级，答案自己就浮出来了。你们项目卡在哪一步，评论区聊聊，我看看能不能给点参考。