从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落地最稳的方案RAGRetrieval-Augmented Generation检索增强生成是当前企业落地大模型最常用的方案。它的思路并不复杂把企业文档切分成片段用 Embedding 模型转成向量存进向量数据库。用户提问时先把问题转成向量在向量库中检索出最相关的文档片段。把“问题 相关文档片段”一起交给大模型让模型基于给定的资料回答。RAG 解决的核心痛点是“模型不知道企业私有数据”。比如一家公司的内部运维手册模型在预训练时肯定没见过。如果不做 RAG用户问“这个系统怎么重启”模型只能瞎编做了 RAG模型就能从手册里检索到相关内容再结合自己的表达能力给出答案。RAG 之所以比微调更受青睐原因也很现实不需要昂贵的训练算力用现成 Embedding 模型和 LLM API 就能搭起来。知识更新方便文档变了直接更新向量库不需要重新训练模型。可以追溯到答案来源哪些文档片段支撑了这个回答审计更容易。3.3 AI Agent从“问答”到“执行”如果说 RAG 解决的是“让模型知道”AI Agent 解决的是“让模型做到”。Agent 的本质是让大模型具备调用工具、拆解任务、多步推理、自我纠错的能力。比如用户说“帮我查一下这个月的服务器账单找出异常增长的项目”Agent 可能需要调用账单查询工具获取原始数据。调用代码解释器做异常检测。调用报表工具生成图表。汇总成结论用自然语言回复用户。这个过程中大模型充当的是“调度大脑”而不是单纯的“聊天机器人”。企业里常见的 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 均可Python3.10 及以上Ollama本地大模型运行工具需要先安装并能拉取模型关键 Python 库chromadb向量数据库sentence-transformersEmbedding 模型requests调用 Ollama 的 HTTP API如果你的机器没有 NVIDIA GPU用 CPU 跑一个小尺寸的 Embedding 模型和 7B 量级的本地模型也可以只是响应会慢一些。先安装 Ollama。安装完成后在终端执行ollama pull qwen2.5:7bqwen2.5:7b是国内通义千问的开源版本中文效果不错显存占用相对可控。如果机器配置较低可以换成更小的qwen2.5:3b。安装 Python 依赖pip install chromadb sentence-transformers requests4.2 项目结构rag_demo/ ├── documents/ │ └── company_intro.txt ├── rag_pipeline.py └── run_query.pydocuments目录用来放企业知识文档这里以一份公司介绍为例。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(encodingutf-8) docs.append({id: file_path.stem, text: text}) return docs def upsert_documents(): 将文档切块并写入向量库document 内容按整篇文本存储。 docs load_documents() collection client.get_or_create_collection(nameCOLLECTION_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(nameCOLLECTION_NAME) query_embedding embedder.encode(query).tolist() results collection.query( query_embeddings[query_embedding], n_resultstop_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, }, timeout120, ) 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_k3) 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_ENDPOINThttps://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 问答应用并掌握调优和排错的基本思路。如果你是刚开始接触大模型方向建议按下面的路径继续学习熟悉大模型 API 的基本调用理解 Token、上下文、温度等基础概念。系统学习提示词工程掌握角色设定、示例引导、结构化输出等技巧。手写一个 RAG 项目深入理解切分、向量化、检索、重排的完整链路。研究 Agent 的工作流设计学会把工具调用、多步推理、记忆管理结合起来。再往后可以接触微调、模型量化部署、推理优化补齐底层能力。AI 行业永远不缺乏新概念和新热词但真正能穿越周期的始终是那些能解决真实问题的工程能力。希望这篇文章能帮你在大模型落地的大方向上找到一个适合自己的切入点。