创业：大模型RAG系统三个月的开发心得和思考

从零搭建一套RAG产品，这三个月到底踩了多少坑

今年1月底，我们从上一家公司出来后，就一头扎进了大模型RAG产品的开发里。春节也没怎么歇，前后差不多三个月时间，昼夜兼程。到3月底，产品总算有了一个基础雏形。

团队分工很明确：员外负责产品和市场、谈客户，我和阿包则扛起技术架构和从零到一的代码实现。1月26日，第一版上线，开始接受企业客户试用。这一试，我们才真正意识到产品在真实场景中的差距——用户的需求五花八门，而我们产品的竞争力也暴露了不少短板。

在TorchV AI初步成型之际，聊聊这段时间积累的一些心得和思考。

RAG是什么，为什么值得做

RAG（检索增强生成）这个概念最早可以追溯到2020年的那篇论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。它的核心思路很简单：给大模型装一个外设知识库，让它能基于这些外部信息来做回答，而不是全靠它"记"在参数里的东西。这样既能提升准确性，也能减少胡说八道的概率。

大模型有几个硬伤，行业里都清楚：

• 没有答案的时候容易编造，也就是所谓幻觉；
• 模型训练成本极高，更新周期也长；
• 企业核心数据的安全性很难保障。

而RAG恰好在这几个问题上给出了非常务实的解法：

• 成本可控、开箱即用
  ：配上检索和向量技术，就能让大模型"读"到它原本不知道的知识，而且来源可追溯，权威性更强；

• 有效降低幻觉
  ：虽然不可能100%消灭幻觉，但肉眼可见能减少很多；

• 数据安全
  ：私有化部署后，企业数据不用出墙，安全可控。

RAG的系统架构，到底该怎么搭

要把RAG做好，核心目标只有一个：

。这里有两个难点：

• 依赖现有知识库
  ：企业私有数据，大模型不可能知道，所以必须靠RAG把知识喂给它，而不是指望它自己"猜"；

• 精准命中
  ：上传了数据之后，怎么保证每条回答都能精准命中用户想问的内容，这里面涉及的技术环节非常多。

很早之前，参考大模型的技术架构，画过一张类似的结构图：

如果把做RAG系统比作种树，那LLM是土壤，上面长着三棵树——

。模型微调这块暂时还没放进主流程，等基础工程做到80分以上再考虑也不迟。

• 数据工程
  ：知识库的格式千奇百怪，PDF、Word、Excel、HTML……怎么切分、怎么建索引、怎么提取关键信息，全是坑；

• 检索生成
  ：数据处理好之后，配合大模型做检索和生成，这里面涉及提示工程、检索策略、中间件、查询改写等；

• 业务系统
  ：商业落地需要的东西，租户、计费、开放平台、运营后台，一个都不能少。

从这个角度看，做一套RAG产品，本质上和训练大模型一样，是个系统性工程。每一个环节优化10%，累积起来的竞争力就很可观了。

数据工程：第一道拦路虎

圈子里有句话叫"垃圾进，垃圾出"。数据质量直接决定最终效果。

实际面临的问题包括：

• 常见文件解析（PDF、Word、Excel、CSV、HTML、Markdown）各有各的脾气；
• 数据库（MySQL、Postgres等）的数据源对接，看起来不难，但适配种类一多就容易顾此失彼；
• 网络数据集就更复杂了，网页、视频、音频……爬虫、解析、提取，每个环节都容易出幺蛾子；
• 不同类型数据的提取方式差异巨大，光是表格在不同文件格式里的表现，就够头疼一阵的；
• 分割策略更是重中之重，切不好，语义就丢了，后续检索质量直接崩；
• Embedding索引构建也是个精细活，光是给每个chunk建向量还不够，元数据、概要、标题都得跟上。

在数据工程这棵树上，技术迭代非常快。大模型越火，ETL（数据提取、转换、加载）的发展也会被推着往前走，但这并不意味着哪一天能一劳永逸。

检索生成：不只是做搜索

数据处理好之后，剩下的就是搜索加生成了。这么说好像很简单，但实际做起来完全是另一回事。

目前主流的检索技术无非两种：

• 关键词检索
  （比如BM25）：基于词频倒排，缺点是没语义；

• 向量语义检索
  ：通过BERT这类模型把文本转成向量，再用KNN/ANN去找最相似的。

当然，现在很多向量数据库都支持混合检索，能取两者的长处。

在检索生成环节，要注意的细节也相当多：

• 提示工程
  ：FewShot、CoT、ZeroShot……针对不同场景，提示词的写法差别很大；

• 大模型的选择
  ：GLM、百川、千问、GPT系列……每一家的能力图谱都不一样，必须深度适配；

• 检索过程处理
  ：多轮对话、查询重写、多跳检索、多路召回，每一步都得确保稳定；

• 中间件
  ：缓存、消息队列、向量数据库、图数据库……高可用和扩展性全要靠它们撑起来。

检索生成和数据工程是深度绑定的，根本目的是一个——降低幻觉。

技术驱动商业，比以往更明显

做RAG这类AI应用，和以前做传统产品项目的感受完全不同。一方面是技术栈更新太快，另一方面，有了大模型之后，用户的需求和想法也变得特别天马行空。

在这段时间里，有几点体会特别深：

• 新技术的出现必然倒逼软件流程和开发方式的变革，思维方式得跟着转；
• 用RAG解决幻觉，做到60分很容易，但想做到80分甚至90分，非常难。这不是一锤子买卖，需要长期迭代；
• 企业客户不会为一个60-70分的技术产品买单。产研人员必须对自己要求更高，追求极致。

团队内部也一直在调整方向。成立TorchV AI时，我们定了三层架构：

• TorchV IC（幂等分类器）
  ：尽量让既定事实数据发挥更大比重，引入更多幂等机制来对抗大模型的幻觉；

• TorchV Actuator（执行器）
  ：优化输出格式，让交互界面更友好；

• TorchV Connector（连接器）
  ：连接本地数据，解决本地化场景下的数据多样性和复杂性问题。

通过这套中间件，我们首先产出了第一个产品基线——TorchV Bot，其架构目前是这样的：

核心组件包括：

• RAG和Agent
  ：大模型落地的标配；

• Tenant（租户系统）
  ：支撑多租户PaaS/SaaS的基础；

• OSS（在线文件存储）
  ：存储客户上传的文件和从URL导入的数据；

• ChatBot
  ：默认的Web问答界面，客户可以直接用；

• 数据与洞察分析
  ：预设洞察条件，触发后执行指定动作；

• 知识库管理
  ：上传文件后自动切分、建索引；

• 运营后台
  ：计费、参数配置、对话记录、用户权限管理；

• 应用中心
  ：一个客户可以创建多个应用，通过API或嵌入JS代码来集成。

架构与语言选择：Ja va和Python怎么分工

刚开始选编程语言的时候也纠结了很久，走了不少弯路。

最后TorchV AI选择了Ja va + Python的组合。原因很直接：

• 团队核心成员都是Ja va出身，生态更熟悉；
• Python绕不开，但只负责无状态的逻辑操作；
• Ja va在企业级开发上的组件生态更成熟；
• 中间件的丰富程度和社区健康度也很关键。

这张图能比较清晰地看到两种语言在不同领域的特性对比：

目前市面上最火的LLM框架，LangChain和LlamaIndex，都是Python的。它们提供了开箱即用的能力，10行代码就能搭一个RAG demo出来。但经过团队内部讨论，我们还是决定把部分核心逻辑用Ja va重写，原因包括：

• 开箱即用的框架很难满足企业多变的需求；
• RAG目前没有像HTTP那样形成统一规范，不同模型、不同流程，效果差异很大；
• 国内大模型百花齐放，本土化适配的需求也很多样。

在具体的职责分工上，思路也很清晰：

• Ja va
  ：负责业务系统的数据一致性、分布式事务、鉴权、限流等企业级特性；

• Python
  ：负责所有无状态的服务，比如数据工程、Chat模型、数据处理、微调等。

选语言，最终还是看生态和稳定性。没有标准答案，适合自己的才是最好的。

总结

最后简单总结三句话：

• RAG和LLM产品的技术栈正在快速迭代，小步快跑、快速试错，可能是当前最务实的打法；
• 应用场景目前更集中在知识密集型任务上，但随着技术成熟，必然向更多行业渗透；
• 降低幻觉这件事，60分容易，80分极难，但这是所有RAG产品的立身之本，值得持续投入。

TorchV AI才刚刚起步，后续还有很长的路要走。