创业：大模型 RAG 系统三个月的开发心得和思考
1. 前言
自从和员外上家公司离职后，我们就自己搞公司投入到了 RAG 大模型的 AI 产品应用的开发中，这中间有一个春节，前后的总时间大概是三个月左右，在这三个月期间，基本是昼夜兼程啊，到今天 3 月底结束，产品目前看是有了一个基础的雏形。
在这期间，员外负责整个产品的营销、商业客户的洽谈等方面的内容，我和阿包负责整体的技术架构搭建，代码从 0-1 的编写，我们是在 24 年 1 月 26，产品初步上线了一个版本，开始接受企业客户的试用，这让我们接受到了大量的需求，以及我们产品在目前的市场环境中还存在哪些竞争力不足需要改进的地方。
三个月时间过去了，在我们的 TorchV AI 产品初步成型之际，和大家分享一下开发 RAG、LLM 系统以来的一些心得和经验。
2. RAG 简介
RAG(检索增强生成)名词一开始来源于 2020 年的一片论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，旨在为大语言模型（LLM）提供额外的、来自外部知识源的信息。这样，LLM 在生成更精确、更贴合上下文的答案的同时，也能有效减少产生误导性信息的可能。
可以说在目前大模型井喷的今天，RAG 作为一项为密集型知识 NLP 任务的处理指明了方向，配合 AI 大模型，让世界发生了翻天覆地的变化，数以万计的开发者都涌入这个赛道，同时竞争。
我们知道 LLM 目前存在的一些问题和挑战：
我自己理解 LLM 大模型本质就是一个二进制文件，所有的知识都通过压缩技术全部压缩在一个/多个 GB 的二进制文件中，最终在获取数据的时候，通过 LLM 的模型架构，推理能力，将所有的知识信息又生成出来。
在没有答案的情况下提供虚假信息(胡说八道、幻觉)。
模型知识的更新成本、周期、及大模型的通用能力问题（大公司才玩的转）
数据安全和隐私等问题
而 RAG 技术的出现，正好能有效的缓解目前大模型存在的一些问题，主要表现方面如下：
经济高效的处理知识 &开箱即用：只需要借助信息检索 &向量技术，将用户的问题和知识库进行相关性搜索结合，就能高效的提供大模型不知道的知识，同时具有权威性
有效避免幻觉问题：虽然无法 100%解决大模型的幻觉问题，但通过 RAG 技术能够有效的降低幻觉，在软件系统中结合大模型提供幂等的 API 接口就可以发挥大模型的重大作用
数据安全：企业的数据可以得到有效的保护,通过私有化部署基于 RAG 系统开发的 AI 产品，能够在体验 AI 带来的便利性的同时，又能避免企业隐私数据的泄漏。
3. RAG 技术 &架构思考
既然我们知道，RAG 作为密集型知识库的处理和大模型配合起来有着天然优势，那么如何做好 RAG 的开发？
RAG 应用的基础技术核心是：让大模型依靠现有的数据(PDF/WORD/Excel/HTML 等等)精准的回答用户的问题
这是最基础的功能，同时也是最低要求，任何做 RAG 领域的 AI 应用产品，技术层面都需要去突破解决的技术难题。
注意两个核心点：
📁 依赖现有的知识库：依赖客户本身的数据是为了给大模型提供强有力的数据支撑,避免大模型胡说八道,企业私有的数据大模型并没有将数据纳入模型进行训练,所以大模型对于企业私有的数据及相关问题,大模型不可能知道，即使大模型能回答你这个领域的问题，那也是因为你这个问题在大模型训练的数据集中早就存在了，而且是公开的数据集和问题，而企业私有的数据(财务报告、隐私数据等)大模型是不可能拥有的
🏹 精准命中回答：一旦客户将自己的私有数据上传了之后,我们要做的就是依靠此数据精准回答用户的问题，而要做到精准回答命中,技术人员需要做多方面的努力💪。
技术人对于 RAG 应用考虑的最核心的就是这两点，而技术测为了要实现这一个目标，其覆盖的知识面以及技术难度都是非常大的。
我很早之前参考大模型的技术架构发展，为 RAG 画了一张类似的图，如下：
这里面我为做 RAG 系统的总结为三颗树，LLM 大模型是土壤，主要为：数据工程、检索生成、业务系统
这里面并没有把对模型的微调放入进来，当我们把基础工程做到 80 分后，也许对 Embedding 模型、Chat 模型等微调工作会加入进来，针对特定的业务场景做优化。
数据工程: 知识库的形式丰富多彩,这其中配合 RAG 我们要做的事情非常多，包括文件类型、格式、分割策略、知识类型、索引方式等等
检索生成:当我们处理完成数据后，配合大模型需要进行检索生成，而在这个过程中，包括：Prompt 工程、算法策略、检索方式、中间件、大模型、查询处理等内容
业务系统: 这是配合商业行为所衍生的业务系统 &上层产品应用，包括租户、计费、开放平台、洞察、运营等业务系统，这些业务系统在 TorchV AI 的产品体系都一一体现
通过上面的图，我们大概就能知道，RAG+LLM 大模型系统的产品开发，是一个综合性非常强的工作内容，这就和大模型的训练一样，整个工程庞大繁杂，是一个系统性工程。
如果我们把三颗树中的每一项都作为一个技术因子，不同的步骤处理优化，都会影响着最终外部的商业的影响力，这就会产生量变到质变的转变。
假设：我们把数据工程和检索工程所有的步骤在技术层面提升了 10%，那么我们在和同类竞品去竞争时，我们的优势是多大呢？
3.1 数据工程
在大模型圈子里，经典名言：Garbage in and garbage out，意思显而易见，你给大模型送的数据质量越高，那么大模型的响应回答效果就越好，反之，如果你丢垃圾给大模型，那么大模型也会给你返回垃圾～
所以从这点来看，上层的应用开发者，要做好知识库类型的产品，数据工程绝对是第一道拦路虎，从数据集的不同领域进行分类,目前存在非常多的数据格式
这里面包含的多种不同的挑战
常见文件解析：基于文件类型的数据集是最常见的,也是使用最广的,例如(PDF/WORD/Excel/CSV/Html/Markdown)等格式
关系型/NoSQL 数据库: 用户的数据全部存储在数据库中间件中，例如 MySQL/Postgres 等，NoSQL 数据库中，这种数据源的提取到是不难，开发者只需要根据不同的数据库标准协议进行对接抽取即可，要做的是适配不同的数据库类型
网络数据集：对于网络数据集的处理，那么就需要开发者精通爬虫之道,而网络上的数据集种类也是非常广的，普通的 W3C 网页(格式种类复杂繁多)，视频、音频等等信息
不同类型的数据提取：包括文本、图片、表格、视频等，单单一个表格数据的在不同的文件格式的处理，就需要花费大量的精力去优化
提取方式的类别：传统的软件工程、OCR、大模型等等
分割策略：分割策略在 RAG 的技术体系中有着举足轻重的地位,分割的不好，会在信息检索(IR)的过程中丢失语义，包括：语义分割、大模型分割、按固定 Token 分割、文档结构分割等等
Embedding 索引构建：除了给每一个 chunk 块构建向量索引，元数据、标题、概要总结等等也会对系统准不准有不同的要求，同时还要和上层的业务进行结合。
More…
在数据工程这棵树上，所有的技术发展都不是停滞不前的，这里仅仅只是列了一些基础的树枝，我相信在大模型 AI 井喷爆发的今天，会更快推进数据工程(ETL)的发展。
3.2 检索生成
当我们把所有的知识数据处理完毕，借助大模型来构建一个 Chat 系统时，信息检索技术则是必然要用到的
从这里我们好像发现，做 RAG，无非就是做搜索?
在目前的 RAG 检索的技术体系中，最普遍的无非两种：关键词和向量语义检索
关键词检索：基于类似 BM25 这类词频倒排技术，通过统计关键词的方式来执行搜索，缺点是无语义信息
向量语义检索：通过将所有知识片段通过 BERT 等预训练语言模型进行表征提取，表示为多维的向量数据，通过 KNN/ANN 算法搜索获取结果。
当然，在目前的很多向量数据库中间件中，这两类检索引擎都得到了支持，或者是混合检索也是一种重要的技术手段。
在整个检索生成的过程中，这棵树同样关注的技术细节也非常的多，如下：
Prompt 工程：和大模型对话，技术人员必须掌握的 Prompt 工程，通过 FewShot、CoT、ZeroShot 等技术，针对不同的业务场景能发挥重大的作用，开发人员需要根据具体的业务场景来调试，同时也是和大模型对接，解决幂等性的重要手段
LLM 大模型：glm3/4、百川、千问、月之暗面、gpt3.5、gpt4 等等大模型，在不同的场景、能力各有侧重，进行深度的业务调试/适配同样重要。
检索召回过程处理：多轮对话、查询重写、多跳、多路召回、子查询等等，伴随业务场景的深入，每一个 Chain 的环节保证稳定可靠，不是轻松的事
中间件：系统稳定高可用、可扩展离不开中间件的支持，如缓存、消息队列、向量数据库、图数据库等等都是必不可少的
More:….
在检索生成的这棵树上，和数据工程密切配合不可分割，都是在降低大模型幻觉的道路上深挖技术细节。
4. 技术 &产品领导驱动商业的发展
做 RAG 这类 AI 应用开发以来，感受最深的是和之前做产品/项目并不相同，一方面是技术栈发展较新，新技术带来的技术变革存在非常大的挑战，有了大模型之后，需求 &想法也是五花八门，另外，目前的 AI 应用，我觉得更多的是技术 &产品来领导驱动商业的发展，这和普通软件企业的开发流程或许有所不同。
这里我觉得几点非常重要：
新 AI 技术的迅速发展必然革新之前的软件流程和开发过程，在思想层面是必须转变。
大模型幻觉很严重，通过 RAG 技术解决幻觉做 60 分很容易，但是把底层的能力提升到 80 分甚至 90 分，是非常难的事情，这需要一个长期累积迭代的过程。
企业客户不会为了一个只有 60-70 分的技术产品买单付费，对待软件编码、技术架构、产品交互等方面，产研人员需要对自己要求更高，追求完美
我们团队内部经过这段时间的迭代，也碰了很多客户的需求，团队的方向也是在发展中不断的进行调整。
我们在成立 TorchV AI 时，整体架构如下：
我们以 RAG 技术为核心，在上层做我们的中间件层，这里面最核心的三个：
主要核心问题聚焦在降低大模型幻觉、不同数据源连接上面
TorchV IC(幂等分类器):让既定的事实数据发挥更大比重，引入尽可能多的幂等，对抗和降低 LLM 的幻觉;
TorchV Actuator(执行器):优化 TorchV 特有风格的输出格式，包括交互界面的组装，对应用更友好;
TorchV Connector(连接器):连接本地数据，有序解决本地化场景下数据多样性和复杂性问题.
通过 RAG 技术+中间件的方式，开发出了我们的第一个产品基线 TorchV Bot。通过持续的产品迭代和不同客户需求碰撞，我们的 TorchV Bot 基线产品的架构也初步成型。如下图：
主要组件拆分如下：
RAG 和 Agent：RAG（检索增强生成）和 Agent 是目前大语言模型落地到企业应用的事实标准，也是 TorchV AI 的核心中间件之一；
Tenant：租户系统，这是我们支起多租户 PaaS/SaaS 平台的基础；
OSS：在线文件存储，包括客户上传的文件，以及从 URL 中导入的数据等；
ChatBot：TorchV AI 会提供一个默认的 Web 版问答系统，客户可以在上面对知识进行测试，对于内部使用场景，也可以直接使用；
数据 &洞察分析：对数据进行分析，包括客户预先设定的一些洞察条件，一旦触发条件，就会进行指定动作，如产品和服务的推荐，咨询分流等。客户在这里也可以对数据进行同步，导入到自己的系统，作为数据分析的数据基础；
知识库管理：创建知识库，为每个知识库上传和导入文件，一旦上传，文件立即被系统处理，变成 chunk（小块文本）和 embedding 之后的向量数据等；
运营后台：包括计费系统、各类参数配置、对话记录查看和标注、用户权限设置和反馈处理等功能；
应用中心：一个客户即可创建多个应用，然后通过 API 对接自己的原有系统，或者根据 API 创建新应用。除了 API 之外，我们还提供一键嵌入的对接方式，只需引入几行 js 代码，即可在客户的 Web 应用上开启悬浮 icon，提供 TorchV AI 的对话能力。
以上则是目前 TorchV 的产品雏形，更多细节可以访问官网:https://www.torchv.com
5. 架构 &编程语言的选择
随着大模型 LLM 的爆火，包括LangChain、LlamaIndex等以 LLM 为基础的数据 Python 框架的出现，很多开发者在选择开发 RAG 系统应用时，会可能无法着手。
起初在开发 RAG 应用的时候，也纠结过编程语言的选择，在这期间走了很多的弯路，也得到了一些教训。
先说结论，TorchV.AI 的产品选 Java+Python 作为服务端的开发语言。
这里面有以下几个原因：
员外和我都是多年的 Java 语言开发出生，从编码、生态等方面的了解程度，那自然是不可能抛弃 Java
Python 语言是无可避免的，但是在整个工程里面，职责是有分工的，无状态的一些逻辑操作都通过 Python 来实现
企业级开发语言以及技术组件生态
中间件丰富程度、开发社区的健康发展
下图是我画的一个Java VS Python这两个编程语言在不同领域的一些特性对比。
目前市面上开发 RAG 大模型应用最火的当属LangChain、LlamaIndex这两个框架，都是Python语言进行开发，提供了开箱即用的功能，可能在不超过 10 行代码的情况下，就能轻松完成一个 RAG 大模型应用的 demo。
我们起初也是在纠结在这期间如何更好的做取舍，后来团队内部经过讨论，还是将部分的业务逻辑放在 Java 语言中，重写 RAG 过程中的一些核心逻辑和组件。
这里面的思考：
RAG 架构涉及到的东西多且杂，开箱即用的 LLM 数据处理框架可能无法满足企业的业务诉求(需求变化多端)
RAG 目前并没有发展成为 HTTP 规范一样的协议约定，所以不同的 RAG 过程、LLM 模型等都会导致 RAG 的效果差异
国内 LLM 百花齐放，无法开箱即用，国内的不同需求也需要满足(本地化适配)
结合在开发 RAG 应用中涉及到的数据工程等部分逻辑，我们结合两大语言的特性，也能很轻松的勾画出一张便语言级别的架构图，涵盖了在企业开发、业务场景落地时，如何快速的适配上层应用的需求。如下图所示：
在这种图中，我们可以清晰的看到，不同的任务 &需求，职责分工是比较明确的。
Java：使用 Java 生态时，针对业务系统的数据一致性，分布式、鉴权、限流等企业应用接口的特性开发，目前都有非常成熟的解决方案
Python：涉及到无状态的服务时，支撑上层应用的处理，包括数据工程、Chat 模型、数据处理、微调等系统工程，那么用 Python 是毫无疑问
在这里，当我们使用应用开发时，挑选编程语言来开发应用服务，优先考虑的是生态和稳定性。
当然，这里面并没有唯一的标准，根据自己的实际情况出发来选择是最优的，以上仅仅只是分享一下我的看法。
6. 总结
好了，全文完，做一个总结：
RAG、LLM 等 AI 产品的开发是日新月异的，技术栈体系会飞速发展,对于公司而言，小步快跑，快速试错可能是非常重要的
应用场景目前仅仅只是聚焦在知识密集型任务，未来随着技术的发展，会扩展到更多的行业中。
TorchV.AI 目前是刚起步阶段，也欢迎更多的企业客户试用，合作！！！
如果您有商务合作需求：
请扫码添加以下微信（员外🔥TorchV），并请您告知您的称呼 和 企业名称 。
我们的官网地址：https://www.torchv.com
7. References
版权声明: 本文为 InfoQ 作者【Knife4j】的原创文章。
原文链接:【http://xie.infoq.cn/article/fd7d3118f49dd443ee397786c】。文章转载请联系作者。
关注Knife4j社区 2019-04-05 加入
Knife4j是一个集Swagger2 和 OpenAPI3为一体的增强解决方案，帮助开发者快速聚合使用OpenAPI规范. 微信公众号：Knife4j 官网地址：https://doc.xiaominfo.com
评论