创业：大模型RAG系统三个月的开发心得和思考
前言和员外一起从上家公司离职后我们便携手创办了属于自己的公司全身心投入到 RAG 大模型 AI 产品应用的研发之中。这段历程里我们恰好经历了一个春节前后算下来总耗时大概三个月左右。这三个月里我们几乎全程昼夜兼程、全力以赴直到三月底我们的产品终于有了基础雏形也算不负这段时间的奔波与付出。研发期间我们分工明确、各司其职员外主要负责整个产品的营销推广以及商业客户的对接与洽谈工作而我和阿包则承担起了整体技术架构的搭建从零开始编写每一行代码一步步推进产品落地。在 2024 年 1 月 26 日我们的产品成功上线了第一个初步版本正式面向企业客户开放试用。也正是通过这次试用我们收集到了大量真实的客户需求同时也清晰地认识到在当前的市场环境下我们的产品还存在一些竞争力不足的地方还有很多需要优化改进的方向。如今三个月的紧张研发已告一段落我们的 TorchV AI 产品也初步成型。今天就想和大家好好分享一下这段时间以来我们在开发 RAG、LLM 系统过程中的一些心得与经验。RAG简介RAG检索增强生成这一概念最早源于2020年的一篇论文——《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。它的核心目的很简单为大语言模型LLM补充来自外部知识源的额外信息让LLM在生成答案时既能更精准、更贴合上下文也能有效减少误导性信息也就是我们常说的“胡说八道”的产生。放到当下大模型井喷的时代来看RAG无疑为知识密集型NLP任务的处理指明了清晰的方向。当RAG与AI大模型深度结合不仅深刻改变着我们的生活与工作也吸引了数以万计的开发者涌入这个赛道开启了激烈的行业竞争。聊到RAG就不得不先说说当前LLM面临的那些现实问题与挑战——结合我的理解跟大家通俗拆解一下其实LLM大模型的本质就是一个二进制文件。它所有的知识都通过压缩技术被整合进一个或多个GB级的二进制文件中等到我们需要获取数据时它再通过自身的模型架构和推理能力将这些压缩的知识信息重新生成、输出。而这样的特性也让LLM存在不少短板比如在没有相关答案时容易生成虚假信息也就是大模型“幻觉”其次模型知识的更新不仅成本高、周期长而且大模型的通用能力门槛极高基本只有大公司才能玩转除此之外数据安全和隐私保护也是很多企业使用LLM时最担心的问题。而RAG技术的出现恰好成为了这些痛点的“缓解剂”它的核心优势主要体现在这几个方面第一经济高效处理知识还能开箱即用。无需复杂操作只要借助信息检索和向量技术将用户的问题与知识库进行相关性匹配、搜索结合就能高效为大模型补充它不知道的知识而且这些知识还具备权威性。第二有效规避大模型幻觉。虽然它没法100%彻底解决幻觉问题但通过RAG技术能大幅降低幻觉出现的概率只要在软件系统中结合大模型提供幂等的API接口就能充分发挥大模型的价值。第三保障数据安全。对于企业而言这一点尤为重要——通过私有化部署基于RAG系统开发的AI产品企业既能享受AI带来的便捷又能有效保护自身隐私数据避免数据泄露的风险。RAG技术架构思考既然我们已经明确RAG在处理知识密集型知识库、与大模型配合使用上有着天然的优势那么核心问题来了——如何做好RAG的开发工作其实RAG应用的基础技术核心很简单一句话就能说透让大模型依托客户现有的各类数据比如PDF、WORD、Excel、HTML等格式精准地回答用户提出的问题。这看似是最基础的功能却是对RAG领域所有AI应用产品的最低要求更是每个涉足RAG领域的团队都必须在技术层面突破解决的核心难题。这里要重点强调两个核心要点也是我们做RAG开发时始终放在首位的考量第一个核心点是依赖现有的知识库。我们之所以要依托客户自身的数据核心目的就是为大模型提供强有力的精准数据支撑从根源上减少大模型“胡说八道”的可能。要知道企业的私有数据比如财务报告、内部隐私数据等是不会被纳入大模型的训练数据集的——也就是说大模型根本不可能知晓这些私有数据及相关问题。即便大模型能回答你所在领域的某些问题也只是因为这个问题早已存在于它的公开训练数据集中而非它掌握了企业的私有信息。第二个核心点是精准命中回答。一旦客户将自己的私有数据上传到系统我们的核心目标就是依托这些数据精准回应用户的每一个相关问题。而要实现“精准命中”这一目标背后需要技术人员在多个层面付出大量努力绝非易事。对技术人来说做RAG应用开发最核心的考量就是这两点。而要实现这个核心目标需要覆盖的知识面非常广对应的技术难度也远超很多人的预期。其实早在很久之前我就参考大模型的技术架构发展历程为RAG画了一张类似的架构图如下在做RAG系统的过程中我把核心逻辑总结为“三颗树”而LLM大模型就是支撑这三颗树生长的“土壤”。这三颗树分别是数据工程、检索生成、业务系统。这里要说明一下目前我们并没有把模型微调纳入其中。我的想法是当我们把基础工程的能力做到80分的水准后再考虑加入对Embedding模型、Chat模型等的微调工作针对具体的业务场景做进一步优化让产品更贴合实际需求。先和大家拆解第一颗树——数据工程。知识库的形式多种多样对应的我们要做的工作也十分繁杂比如文件的类型、格式适配文本分割策略的设计知识类型的分类梳理以及索引方式的选择等等每一项都直接影响后续RAG系统的运行效果。接着是第二颗树——检索生成。当我们完成数据的预处理工作后就需要配合大模型开展检索生成相关操作。这个过程涉及的环节也不少包括Prompt工程的优化、算法策略的设计、检索方式的选择、中间件的适配、大模型的调用以及查询请求的处理等每一步都需要精心打磨。最后是第三颗树——业务系统。这是围绕商业落地衍生的上层系统和产品应用比如租户管理、计费系统、开放平台、数据洞察、运营管理等相关模块。而这些业务系统在我们的TorchV AI产品体系中都已经一一落地实现。通过这样的梳理大家应该能明白RAGLLM大模型系统的产品开发是一项综合性极强的工作。它和大模型训练一样整个工程庞大且繁杂绝非单一模块的开发而是一项需要多环节协同的系统性工程。如果我们把“三颗树”中的每一项工作都看作一个独立的技术因子就会发现不同步骤的优化和打磨都会直接影响产品最终的商业影响力。当这些微小的优化积累到一定程度就会实现从量变到质变的突破。这里不妨做一个假设如果我们把数据工程和检索工程的每一个技术步骤都在现有基础上提升10%那么当我们和同类竞品同台竞争时我们的核心优势又会提升多少呢3.2 检索生成在大模型圈子里有一句经典名言“Garbage in and garbage out”道理其实很简单——你给大模型输入的数据质量越高它反馈的回答效果就越好反之如果你给大模型喂的是“垃圾数据”那它返回的结果自然也不尽如人意甚至会出现误导性信息。也正因为如此对于做上层应用开发的我们来说要做好知识库类产品数据工程绝对是第一道绕不开的“拦路虎”。目前市面上的数据集涵盖不同领域对应的格式也五花八门这就给数据工程带来了诸多挑战我们逐一和大家拆解。第一个挑战是常见文件解析。基于文件类型的数据集是最普遍、使用最广泛的比如我们日常接触的PDF、WORD、Excel、CSV、Html、Markdown等格式每一种格式的解析逻辑、处理方式都有所不同需要逐一适配优化。第二个挑战是关系型/NoSQL数据库的数据提取。很多用户的核心数据都会存储在数据库中间件中比如MySQL、Postgres等关系型数据库以及各类NoSQL数据库。其实这类数据源的提取难度不算大开发者只需按照不同数据库的标准协议对接就能完成数据抽取核心难点在于适配不同类型的数据库确保数据提取的稳定性和完整性。第三个挑战是网络数据集的处理。这就要求开发者精通爬虫技术毕竟网络上的数据集种类繁杂既有格式多样、规范不一的普通W3C网页也有视频、音频等非文本类信息每一种都需要针对性的处理方案。除此之外还有不同类型的数据提取难题——包括文本、图片、表格、视频等多种形式单说表格数据在不同文件格式下的处理逻辑就有很大差异需要我们花费大量精力去打磨优化才能确保提取的准确性。而提取方式的选择也很关键目前常用的有传统软件工程方法、OCR识别、借助大模型提取等不同场景适合不同的提取方式需要结合实际需求灵活选择。还有一个重中之重就是分割策略。它在RAG技术体系里占据着举足轻重的地位要是分割不到位很容易在信息检索IR过程中丢失语义影响最终的回答效果。常见的分割方式有语义分割、大模型分割、按固定Token分割、按文档结构分割等每一种都有其适用场景。最后是Embedding索引构建。我们不仅要给每一个chunk块构建向量索引元数据、标题、概要总结等信息的处理也会影响系统的精准度而且这些操作还需要和上层业务深度结合才能真正发挥作用。当然数据工程的挑战远不止这些还有更多细节需要我们不断探索。值得一提的是数据工程这棵“树”上的技术从来都不是停滞不前的。上面我们列举的仅仅是它最基础的一些“树枝”。我相信在大模型AI井喷式爆发的今天一定会加速数据工程ETL的迭代发展出现更多更高效、更便捷的处理方式。技术产品领导驱动商业的发展自从投身RAG这类AI应用开发我最大的感受就是它和之前做普通产品、项目有着本质区别。一方面相关技术栈发展得太快、太新新技术带来的行业变革给我们带来了不小的挑战另一方面有了大模型之后大家的需求和想法也变得五花八门、层出不穷。除此之外我还有一个深刻的体会——目前的AI应用更多是靠技术和产品来引领、驱动商业发展这和普通软件企业的开发流程或许有着不小的差异。结合这段时间的实操经历我觉得有几点特别重要想和大家分享第一新AI技术的快速迭代必然会革新以往的软件开发流程和模式最关键的是我们在思想层面必须做出转变不能固守过去的老思路要主动适应这种变革。第二大模型的幻觉问题一直很突出。用RAG技术解决幻觉做到60分不难但要把底层能力打磨到80分、甚至90分就非常有难度了——这绝非一蹴而就的事情需要一个长期积累、持续迭代的过程。第三企业客户不会为只有60、70分的技术产品付费。所以不管是软件编码、技术架构还是产品交互我们产研人员都得对自己提出更高要求凡事追求极致、力求完美才能真正打动客户。我们团队这段时间也在不断迭代打磨接触了很多客户的真实需求团队的发展方向也在这个过程中不断调整、逐步清晰。当初我们成立TorchV AI时设定的整体架构如下我们整个技术架构的核心始终围绕RAG技术展开在此基础上我们在架构上层搭建了专属的中间件层。而这一层的核心目标非常明确主要聚焦于两个关键问题一是降低大模型的幻觉问题二是实现不同数据源的高效连接。其中中间件层最核心的三个组件分别承担着不同的关键作用具体拆解如下TorchV IC幂等分类器核心作用是让既定的事实数据发挥更大价值通过引入尽可能多的幂等机制有效对抗并降低LLM的幻觉问题让模型输出更精准、更可靠。TorchV Actuator执行器主要负责优化TorchV AI特有的输出格式同时承担着交互界面的组装工作让产品应用更贴合用户使用习惯变得更友好、更易操作。TorchV Connector连接器核心功能是连接本地各类数据有序解决本地化场景下数据种类多样、结构复杂的连接难题为后续的检索和生成提供稳定的数据支撑。正是通过“RAG技术中间件层”的组合模式我们成功开发出了第一款产品基线——TorchV Bot。后续随着我们持续推进产品迭代不断对接不同客户的真实需求、碰撞优化方向TorchV Bot这款基线产品的架构也逐步完善、初步成型。具体架构如下图所示下面我们就将TorchV AI的主要组件逐一拆解方便大家更清晰地了解整个产品架构的核心构成RAG和AgentRAG检索增强生成与Agent如今已是大语言模型落地企业应用的事实标准同时也是TorchV AI核心中间件的重要组成部分支撑着产品核心能力的落地。Tenant租户系统这是我们搭建多租户PaaS/SaaS平台的核心基础能够实现多客户并行使用、数据隔离为不同客户提供专属的产品使用环境。OSS在线文件存储主要用于存储各类文件数据既包括客户主动上传的文件也涵盖从URL中导入的各类数据为后续的知识库处理、检索生成提供稳定的存储支撑。ChatBotTorchV AI会默认配备一个Web版问答系统客户可通过这个系统快速测试知识库内容、验证效果如果是企业内部使用场景这款问答系统也可直接投入使用无需额外开发。数据洞察分析核心负责对各类数据进行深度分析同时支持客户预设洞察条件——一旦触发预设条件系统会自动执行指定动作比如产品服务推荐、咨询分流等。此外客户还可在此模块同步相关数据将其导入自身系统作为后续数据分析的基础。知识库管理支持客户创建专属知识库并且可以为每个知识库上传、导入各类文件。文件一旦上传系统会立即自动处理将其转化为chunk小块文本以及经过embedding处理后的向量数据为后续的检索生成提供核心数据支撑。运营后台整合了多项核心运营功能涵盖计费系统管理、各类产品参数配置、对话记录的查看与标注、用户权限设置以及客户反馈的收集与处理等全方位支撑产品的日常运营与优化。应用中心单个客户可在应用中心创建多个应用既可以通过API对接自身原有系统也能基于API开发新的应用。除了API对接方式我们还提供一键嵌入的便捷方案——只需引入几行JS代码就能在客户的Web应用中添加悬浮icon快速接入TorchV AI的对话能力无需复杂开发。架构编程语言的选择随着大模型LLM的爆火LangChain、LlamaIndex等以LLM为基础的Python数据框架也相继涌现。这对很多想要开发RAG系统应用的开发者来说反而容易陷入迷茫不知道该从何入手。其实我们当初在开发RAG应用时也在编程语言的选择上纠结了很久期间走了不少弯路也积累了一些值得分享的教训。先直接给大家说结论我们TorchV AI产品的服务端开发语言最终选定了JavaPython的组合。之所以做出这样的选择主要有以下几个原因和大家坦诚分享第一我和员外都是多年Java开发出身不管是编码习惯、技术细节还是Java的生态体系我们都非常熟悉。从情感和技术熟练度上来说自然不可能轻易抛弃Java这门陪伴我们多年的语言。第二Python语言在RAG开发中几乎无可避免但我们在整个工程体系里给它明确了职责分工——无状态的各类逻辑操作我们全部交由Python来实现让它发挥自身的优势。第三Java作为成熟的企业级开发语言其配套的技术组件生态非常完善能够很好地支撑我们做企业级产品开发满足稳定性、安全性等核心需求。第四从中间件的丰富程度以及开发社区的健康发展来看Java和Python的组合能够兼顾开发效率和工程稳定性减少后续维护的成本。下面这张图是我整理的Java和Python两种编程语言在不同领域的特性对比大家可以直观参考目前市面上开发RAG大模型应用最热门的当属LangChain和LlamaIndex这两个框架。它们均基于Python开发最大的优势就是“开箱即用”甚至不用超过10行代码就能轻松搭建出一个RAG大模型应用的demo上手门槛极低。我们当初在搭建TorchV AI架构时也一度在这两个框架的选择上陷入纠结反复考量如何取舍才能更贴合企业级需求。后来经过团队内部的充分讨论我们最终决定将部分业务逻辑放在Java语言中实现同时重写RAG流程中的一些核心逻辑和组件。做出这个决定我们主要有以下几点思考和大家坦诚分享第一RAG架构本身涉及的环节多且杂那些开箱即用的LLM数据处理框架虽然上手快、成本低但很难适配企业多变的业务诉求——企业需求灵活且复杂通用框架的固定模式往往无法满足个性化的业务场景。第二RAG目前还没有形成像HTTP那样统一的协议规范没有明确的标准约束。这就导致不同的RAG实现流程、不同的LLM模型选型都会直接影响最终的RAG效果很难保证企业级应用所需的稳定性和一致性。第三国内的LLM市场如今百花齐放但大多无法直接开箱即用同时国内企业还有很多本地化适配的需求比如数据安全、场景适配等这也需要我们结合自身技术栈做定制化开发才能满足。结合我们在RAG应用开发中涉及到的数据工程等相关逻辑我们充分发挥Java和Python两大语言的特性也能轻松勾勒出一张跨语言级别的架构图。这张图会清晰呈现在企业开发、业务场景落地过程中如何快速适配上层应用的各类需求。具体如下图所示从这张架构图里我们能清晰地看到针对不同的任务和需求Java和Python的职责分工非常明确各自发挥自身优势。先说说Java我们在使用Java生态时主要聚焦于企业级应用接口的开发。比如业务系统的数据一致性、分布式部署、鉴权、限流等核心需求目前Java生态都有非常成熟的解决方案能大幅降低开发难度、提升系统稳定性完全适配企业级应用的诉求。再看Python当涉及到无状态服务需要支撑上层应用各类处理需求时——包括数据工程、Chat模型调用、数据处理、模型微调等系统工程选择Python是毫无疑问的。它在这类场景下的开发效率和生态适配性有着不可替代的优势。其实我们在开发应用服务、挑选编程语言时核心优先考量的始终是生态的完善度和系统的稳定性。这两点直接决定了后续产品的落地效率和长期运维成本。当然这并不是唯一的标准也没有绝对正确的选择。对每个开发者、每个团队来说结合自身的实际情况比如技术栈、业务需求来做选择才是最优解。以上也只是我结合自身开发经验和大家做的一点分享而已。总结好了整篇文章到这里就正式结束啦最后和大家做个简单总结RAG、LLM等AI产品的开发节奏日新月异相关技术栈和体系也在飞速迭代升级。对于我们这类深耕AI领域的公司而言小步快跑、快速试错或许是适配行业变化、稳步前行的关键。目前来看这类AI应用的场景还主要聚焦在知识密集型任务上但随着技术的持续发展和突破未来它一定会延伸到更多行业、更多场景中创造更大的价值。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
