从AI六小龙到工程化落地：大模型应用与本地RAG实战解析

从 2023 年到 2024 年，“AI 六小龙”几乎是国内大模型圈绕不开的热词。智谱、月之暗面、MiniMax、百川智能、零一万物、阶跃星辰等一批拿到巨额融资的明星创业公司，在短短两三年里完成了从“草台班子”到“百亿估值独角兽”的跃迁。但进入 2025 年之后，这个提法明显降温了。无论是一级市场的融资消息，还是大模型榜单的刷屏次数，都在显著减少。

这背后当然有资本周期和行业洗牌的原因，但对开发者来说，更有价值的是看懂一件事：当“造模型”的热度退潮，真正留下来的是“用模型”的工程能力。本文不打算做成产业评论，而是想结合过去几年 AI 工程化落地的真实变化，聊一聊大模型行业的技术重心转移，并用一个可以本地运行的 RAG 问答应用，演示当下企业最常用的 AI 落地方式。

1. 背景与核心概念

1.1 什么是“AI 六小龙”

“AI 六小龙”是媒体和投资圈对国内头部大模型创业公司的统称，通常指智谱AI、月之暗面、MiniMax、百川智能、零一万物、阶跃星辰这六家。它们的共同特征是：

• 创始团队大多来自清华、北大、微软亚洲研究院、谷歌等顶级机构和公司。
• 在 ChatGPT 掀起的浪潮中拿到了大额融资，估值快速突破独角兽门槛。
• 都选择自研基础大模型路线，而不是只做上层应用。
• 各自有侧重方向，有的主打长文本、有的主打多模态、有的侧重开源生态。

在那个阶段，市场对“基础大模型”四个字有极高的溢价预期，仿佛只要模型做得足够大，AGI 的入口就尽在掌握。这种热度也带动了整个 AI 行业的人才流动、算力采购和应用创业。

1.2 为什么“无人再议”

所谓“无人再议”，并不是说这些公司倒闭了，而是指市场叙事发生了切换。过去大家讨论的是“谁能训出更强的模型”，现在讨论的是“模型怎么变成可用的产品，怎么带来实际的业务收益”。

三个关键词可以概括这个转变：

• 收敛：基础大模型的能力差距在缩小，榜单上刷分的边际效应在递减。
• 落地：行业更关注私有化部署、RAG、AI Agent、智能客服、知识库问答等真实场景。
• 成本：价格战和开源模型让推理成本大幅下降，模型本身不再是稀缺资产，工程能力才是。

对开发者来说，这意味着过去“会调用大模型 API 就算懂 AI”的时代已经过去了。现在更需要掌握的是模型选型、提示词工程、检索增强生成、Agent 编排、评测反馈、成本控制这一整套工程化能力。

2. 大模型领域发生了什么：技术视角复盘

2.1 基础模型的能力趋同

一个很直观的现象是：2023 年各家大模型发布会还能靠某个榜单分数制造话题，到了 2024 年下半年，主流模型在通用对话、代码生成、数学推理等常规任务上的差距已经明显缩小。

这带来的直接后果是，用户已经很难通过“哪个模型更聪明”来决定选择。模型的回答风格、上下文长度、工具调用稳定性、部署成本、数据安全合规，这些非榜单因素反而成了决策重点。

以开源模型为例，DeepSeek、Qwen、Llama 等系列持续迭代，很多开源模型在特定场景下已经逼近闭源模型的效果。企业完全可以用更低的成本做私有化部署，避免把内部数据送到外部 API。

2.2 Scaling Law 进入边际递减阶段

过去几年，大模型行业高度依赖 Scaling Law（规模化法则），也就是“模型越大、数据越多、算力越强，能力就越高”。但这个逻辑在近期遇到了两个压力：

• 高质量文本数据接近枯竭，能用来预训练的数据增量有限。
• 算力和电力的消耗呈指数级上升，训练一次前沿模型的成本高昂到大多数公司无法承受。

这不是说 Scaling Law 失效了，而是说继续沿着“堆参数、堆数据、堆算力”这条路走，回报率在下降。行业开始把注意力放到推理优化、模型压缩、蒸馏、MoE 稀疏激活等技术上，尽量在有限算力下获得更好的效果。

2.3 从“模型竞赛”到“性价比竞争”

当基础能力拉不开差距，价格就成了最直接的竞争手段。尤其是 DeepSeek 等开源模型把推理成本大幅拉低之后，大量闭源 API 被迫跟进降价。

对应用开发者来说，这是好事。过去觉得“大模型太贵，不敢集成到业务里”，现在一个中等级别的对话应用，单次调用成本已经降到可以承受的范围。但这也带来一个新问题：模型那么多，价格又都在降，到底选哪个？这就演化成了一个工程决策问题，需要结合效果、速度、成本、合规四个维度做评估，而不是简单看排名。

3. 行业重心转向 AI 工程化

3.1 AI 工程化要解决什么问题

如果把大模型比作发动机，AI 工程化就是把发动机装进汽车、做好变速箱和底盘调校的过程。基础模型能力再怎么强，如果不能稳定地接入业务系统，不能控制成本，不能保证输出的合规性，那它就只是一个昂贵的 Demo。

AI 工程化的核心任务可以拆成四块：

• 模型接入与统一网关：把多个大模型 API 统一封装，支持动态路由、限流、降级。
• 提示词与上下文工程：让模型的输出更可控，避免答非所问。
• 数据与知识接入：把企业私有数据、实时数据通过 RAG 等方式接入模型。
• 观测与评测：监控回答质量、Token 消耗、调用延迟，持续迭代。

这四块能力，正是当前企业招聘 AI 应用开发工程师时最看重的方向。

3.2 RAG：落地最稳的方案

RAG（Retrieval-Augmented Generation，检索增强生成）是当前企业落地大模型最常用的方案。它的思路并不复杂：

1. 把企业文档切分成片段，用 Embedding 模型转成向量，存进向量数据库。
2. 用户提问时，先把问题转成向量，在向量库中检索出最相关的文档片段。
3. 把“问题 + 相关文档片段”一起交给大模型，让模型基于给定的资料回答。

RAG 解决的核心痛点是“模型不知道企业私有数据”。比如一家公司的内部运维手册，模型在预训练时肯定没见过。如果不做 RAG，用户问“这个系统怎么重启”，模型只能瞎编；做了 RAG，模型就能从手册里检索到相关内容，再结合自己的表达能力给出答案。

RAG 之所以比微调更受青睐，原因也很现实：

• 不需要昂贵的训练算力，用现成 Embedding 模型和 LLM API 就能搭起来。
• 知识更新方便，文档变了直接更新向量库，不需要重新训练模型。
• 可以追溯到答案来源，哪些文档片段支撑了这个回答，审计更容易。

3.3 AI Agent：从“问答”到“执行”

如果说 RAG 解决的是“让模型知道”，AI Agent 解决的是“让模型做到”。

Agent 的本质是让大模型具备调用工具、拆解任务、多步推理、自我纠错的能力。比如用户说“帮我查一下这个月的服务器账单，找出异常增长的项目”，Agent 可能需要：

1. 调用账单查询工具，获取原始数据。
2. 调用代码解释器做异常检测。
3. 调用报表工具生成图表。
4. 汇总成结论，用自然语言回复用户。

这个过程中，大模型充当的是“调度大脑”，而不是单纯的“聊天机器人”。企业里常见的 Agent 应用场景包括：智能运维助手、自动化报表生成、工单分类与处理、代码审查助手、销售线索跟进等。

3.4 模型部署与推理优化

对于数据敏感行业或者大规模并发场景，模型部署是绕不开的环节。

一个完整的模型部署方案通常涉及：

• 推理框架：vLLM、TGI、Ollama、llama.cpp 等，负责把模型跑起来并对外提供接口。
• 量化压缩：用 INT8、INT4 等低精度格式减小模型体积，提升推理速度。
• 硬件选型：根据模型规模和并发量选择 GPU 型号，比如 A10、L20、A100、H800 等。
• 弹性伸缩：根据请求量自动扩缩容，避免高峰期打爆 GPU，低峰期空转浪费钱。

这些内容对只调用 API 的开发者来说可能用不上，但从业内整体趋势看，能私有化部署、能控制成本、能优化推理速度的工程师，在就业市场上的议价能力会越来越强。

4. 完整实战：搭建一个本地 RAG 问答应用

前面聊了不少趋势，接下来进入动手环节。这里用 Python 搭建一个完整的本地 RAG 问答应用，涵盖文档加载、向量化存储、检索召回、LLM 生成四个环节。

为了让示例对读者更友好，这里选择全程本地运行，不依赖外部 API key，只需要安装几个 Python 库，以及一个可以直接从 Ollama 拉取的本地大模型。

4.1 环境准备

• 操作系统：Windows / macOS / Linux 均可
• Python：3.10 及以上
• Ollama：本地大模型运行工具，需要先安装并能拉取模型
• 关键 Python 库：
  • chromadb：向量数据库
  • sentence-transformers：Embedding 模型
  • requests：调用 Ollama 的 HTTP API

如果你的机器没有 NVIDIA GPU，用 CPU 跑一个小尺寸的 Embedding 模型和 7B 量级的本地模型也可以，只是响应会慢一些。

先安装 Ollama。安装完成后，在终端执行：

ollama pull qwen2.5:7b

qwen2.5:7b是国内通义千问的开源版本，中文效果不错，显存占用相对可控。如果机器配置较低，可以换成更小的qwen2.5:3b。

安装 Python 依赖：

pip install chromadb sentence-transformers requests

4.2 项目结构

rag_demo/ ├── documents/ │ └── company_intro.txt ├── rag_pipeline.py └── run_query.py

documents目录用来放企业知识文档，这里以一份公司介绍为例。rag_pipeline.py负责文档向量化和检索，run_query.py提供命令行交互入口。

4.3 准备测试文档

在documents/company_intro.txt中写入下面这段内容，注意保持文本有自然段落，方便后面观察检索效果。

公司成立于 2019 年，总部位于上海，主要面向零售行业提供智能供应链管理系统。 系统支持多仓库存联动、智能补货推荐和运输路径优化，日均处理订单量超过 500 万单。 产品目前采用 SaaS 订阅和私有化部署两种交付方式。 私有化部署支持在客户机房独立运行，数据不出域，满足金融、医药等强监管行业要求。 售后服务团队提供 7x24 小时在线支持，重大故障响应时间不超过 30 分钟。

4.4 编写 RAG 主流程

下面是rag_pipeline.py的完整代码，核心流程分为三部分：构建向量库、检索、生成回答。

# 文件路径：rag_demo/rag_pipeline.py from pathlib import Path import chromadb import requests from sentence_transformers import SentenceTransformer DOC_DIR = Path("./documents") COLLECTION_NAME = "company_docs" EMBED_MODEL_NAME = "paraphrase-multilingual-MiniLM-L12-v2" OLLAMA_URL = "http://localhost:11434/api/generate" OLLAMA_MODEL = "qwen2.5:7b" # Embedding 模型会下载到本地缓存，首次运行会略慢 embedder = SentenceTransformer(EMBED_MODEL_NAME) client = chromadb.PersistentClient(path="./chroma_data") def load_documents(): """读取 documents 目录下的所有 txt 文件。""" docs = [] for file_path in DOC_DIR.glob("*.txt"): text = file_path.read_text(encoding="utf-8") docs.append({"id": file_path.stem, "text": text}) return docs def upsert_documents(): """将文档切块并写入向量库，document 内容按整篇文本存储。""" docs = load_documents() collection = client.get_or_create_collection(name=COLLECTION_NAME) for doc in docs: embedding = embedder.encode(doc["text"]).tolist() collection.upsert( ids=[doc["id"]], embeddings=[embedding], documents=[doc["text"]], ) print(f"已写入 {len(docs)} 篇文档到向量库。") def retrieve(query: str, top_k: int = 3): """根据用户问题检索最相关的文档片段。""" collection = client.get_or_create_collection(name=COLLECTION_NAME) query_embedding = embedder.encode(query).tolist() results = collection.query( query_embeddings=[query_embedding], n_results=top_k, ) return results["documents"][0] def generate_answer(query: str, context: str) -> str: """将检索到的上下文与问题一起交给本地大模型生成回答。""" prompt = f"""你是一个知识库问答助手。请只根据以下资料回答问题。 资料： {context} 问题：{query} 如果资料中没有相关内容，请直接回答“资料中未找到相关信息”，不要编造。""" resp = requests.post( OLLAMA_URL, json={ "model": OLLAMA_MODEL, "prompt": prompt, "stream": False, }, timeout=120, ) resp.raise_for_status() return resp.json()["response"]

这里有几个实现细节需要解释。

PersistentClient(path="./chroma_data")会把向量数据持久化到本地目录，下次启动不需要重新计算所有文档的 Embedding。

SentenceTransformer用的是多语言 MiniLM 模型，对中文支持尚可，体积也小，适合入门案例。生产环境可以换成BAAI/bge-m3等中文效果更好的模型。

generate_answer通过 Ollama 的 HTTP API 调用本地模型。如果你没有安装 Ollama，也可以改成调用 OpenAI 兼容的远端接口，只需替换base_url和api_key。

4.5 编写交互入口

接下来写run_query.py，负责从命令行接收用户输入并调用 RAG 流程。

# 文件路径：rag_demo/run_query.py from rag_pipeline import generate_answer, retrieve, upsert_documents def main(): print("正在初始化向量库...") upsert_documents() print("知识库构建完成。输入问题开始问答，输入 exit 退出。") while True: query = input("\n问题：").strip() if query.lower() in ("exit", "quit"): break context_list = retrieve(query, top_k=3) context = "\n".join(context_list) answer = generate_answer(query, context) print("\n--- 检索到的相关资料 ---") for ctx in context_list: print(ctx[:120].replace("\n", " ")) print("\n--- 回答 ---") print(answer) if __name__ == "__main__": main()

4.6 运行与验证

在rag_demo目录下执行：

python run_query.py

运行后，输入一个问题测试。比如：

问题：公司支持哪些交付方式？ --- 检索到的相关资料 --- 公司成立于 2019 年，总部位于上海，主要面向零售行业提供智能供应链管理系统。系统支持多仓库存联动、智能补货推荐和运输路径优化，日均处理订单量超过 500 万单。产品目前采用 SaaS 订阅和私有化部署两种交付方式。私有化部署支持在客户机房独立运行，数据不出域，满足金融、医药等强监管行业要求。售后服务团队提供 7x24 小时在线支持，重大故障响应时间不超过 30 分钟。 --- 回答 --- 根据资料，公司支持两种交付方式：SaaS 订阅和私有化部署。

第一次运行会下载 Embedding 模型，耗时取决于网络。之后再启动，向量库已经有持久化数据，速度会快很多。

4.7 代码优化方向

入门版跑通之后，可以沿着下面几个方向优化：

• 文档切分：目前是一整篇文本直接入库，如果文档很长，检索效果会变差。可以按段落或固定块大小切分，比如 500 字一个块，块与块之间保留少量重叠。
• 元数据过滤：给文档加上来源、部门、时间等标签，检索时可以按条件过滤。
• 重排序：第一轮向量检索的 TopK 可以多召回一些，再用重排模型精排，提升准确率。
• 流式输出：Ollama 支持stream: true，可以做成打字机效果，用户体验更好。

5. 常见问题与排查思路

本地 RAG 应用虽然链路不长，但每一步都可能出问题。下面把最常见的坑整理成清单。

问题现象	常见原因	解决思路
首次运行下载 Embedding 模型很慢	sentence-transformers从 HuggingFace 下载模型，国内网络不稳定	设置镜像源HF_ENDPOINT=https://hf-mirror.com后重新运行
调用 Ollama 报连接失败	Ollama 服务未启动，或端口不是 11434	在终端执行ollama serve启动服务，确认ollama list能输出模型列表
回答内容完全不在资料里	检索模块没召回相关文档，或提示词中没限制模型	打印检索到的上下文，确认是否包含相关信息；在提示词中明确“只根据资料回答”
中文效果差	默认 Embedding 模型对中文支持不够	换成BAAI/bge-m3或shibing624/text2vec-base-chinese等中文专用模型
向量库重复写入导致回答混乱	没有清理旧的 Collection	删除./chroma_data目录重建向量库
文档过长导致检索不准确	整篇文档直接入库，语义被稀释	先切块再入库，每块 300-800 字为宜
7B 模型在 CPU 上推理太慢	CPU 推理吞吐量有限	使用qwen2.5:3b或qwen2.5:1.5b小模型；有 GPU 时检查 CUDA 是否可用

排查时记住一个顺序原则：先确认数据有没有进入向量库，再确认检索能不能召回，最后才排查模型生成的问题。很多“回答得不对”的问题，根子都在检索环节。

6. 最佳实践与工程建议

6.1 模型选型要看场景，不追参数

很多团队选模型时喜欢盯着主流榜单，但实际上不同场景对模型的要求差异很大：

• 简单客服问答：7B 量级的开源模型已经够用，CPU 也能跑，成本极低。
• 复杂逻辑推理、代码生成：需要更大参数模型，或者在开源模型基础上做针对性微调。
• 数据敏感场景：优先私有化部署，选可商用的开源模型。
• 实时性要求高的场景：同时关注模型体积和推理框架的优化，必要时做量化加速。

一个务实的做法是：准备一组固定测试集，让几个候选模型分别跑一遍，再结合成本、延迟、稳定性综合打分，而不是只看谁“更聪明”。

6.2 RAG 不是万能的，但要先把基础打牢

RAG 项目的成败，很大程度取决于文档切分和 embedding 质量。这里给几条实战建议：

• 文档切分之前先做清洗，去掉页眉页脚、水印、表格噪声。
• 切片大小依文档类型调整。政策文件、合同条款更适合小切片，长篇小说、技术手册可以适当放大。
• 给每个切片保留来源字段，方便后续做引用溯源。
• 先跑通最小闭环，再逐步调优。不要一上来就上很复杂的切分方案。

6.3 重视评测和质量回归

大模型应用发布最怕的是“这次改好了，下次改坏了”。没有评测体系的 AI 应用，基本等于盲人摸象。

建议搭建一个简单的回归测试集，包含：

• 知识库内问题：验证是否能正确回答。
• 知识库外问题：验证是否会乱答。
• 边界问题：空输入、超长输入、重复提问。
• 对抗问题：诱导模型脱离上下文回答。

每次更换模型、修改提示词、调整切分策略之后，都跑一遍测试集，记录通过率。

6.4 安全与合规是底线

企业级 AI 应用必须把安全和合规放在前面：

• 私有化部署时，向量库和模型服务的访问都要做权限控制，不能暴露到公网。
• 外部 API 调用要关注数据出境风险，敏感数据不要发给第三方模型。
• 提示词注入是常见攻击方式。用户可能在问题里写“忽略上述指令”，需要在提示词和输入过滤两个层面做防御。
• 生成内容要有审计手段，保留提问、检索、回答的完整日志。

6.5 成本控制要算总账

最后谈一个容易被忽略的问题：成本。很多团队只看单次 API 调用的价格，却忘了算三笔账：

• 向量库存储和索引成本，文档多了以后同样不可忽视。
• 重试和降级的成本，上游模型偶发超时会触发重试，Token 消耗翻倍。
• 人工维护成本，知识库更新、评测集维护、提示词调优都需要持续投入。

一个推荐的做法是为每个业务场景设定 Token 预算和 P99 延迟指标，做定期复盘，把成本可视化。

7. 总结与学习路线

回到标题，“无人再议 AI 六小龙”并不是说大模型技术不行了，而是说明行业正在经历一次从“造模型”到“用模型”的换挡。对普通开发者来说，这个阶段反而是入场的好时机：基础模型的能力已经足够强，开源生态和工程工具也相当成熟，真正稀缺的是能把模型用到业务里的工程能力。

本文重点讨论了三个话题：

• 为什么基础大模型的热度在降温，背后的技术原因和成本逻辑是什么。
• 为什么 RAG、AI Agent、模型部署这些工程方向才是当前企业的落地重点。
• 如何从零搭建一个本地 RAG 问答应用，并掌握调优和排错的基本思路。

如果你是刚开始接触大模型方向，建议按下面的路径继续学习：

1. 熟悉大模型 API 的基本调用，理解 Token、上下文、温度等基础概念。
2. 系统学习提示词工程，掌握角色设定、示例引导、结构化输出等技巧。
3. 手写一个 RAG 项目，深入理解切分、向量化、检索、重排的完整链路。
4. 研究 Agent 的工作流设计，学会把工具调用、多步推理、记忆管理结合起来。
5. 再往后可以接触微调、模型量化部署、推理优化，补齐底层能力。

AI 行业永远不缺乏新概念和新热词，但真正能穿越周期的，始终是那些能解决真实问题的工程能力。希望这篇文章能帮你在大模型落地的大方向上，找到一个适合自己的切入点。