Skip to content

结束语 如何确保RAG项目顺利立项？

你好，我是叶伟民。

时光流逝，不知不觉我们的课程就要结束了，感谢你的一路相伴。

在撰写这门课程的时候，为了让同学们更容易地掌握技能，我是按照由易到难的角度来编排章节顺序的。现在学完了整个课程，我们已经拥有了从传统开发转型RAG应用所需要的知识。

接下来，就到了学以致用的环节，需要我们在RAG应用实践中不断锻炼自己的能力。而想要为自己争取到更多锻炼机会，最初的起点往往让我们的第一个RAG应用成功立项。

所以在结束语里面，我将围绕第一个RAG应用立项阶段的关键环节，带你重新回顾一下整门课程。

争取利益相关者支持立项

推动RAG应用，一切的基础就是争取利益相关者同意立项。立项不通过，一切都是空谈。

那么如何争取利益相关者同意立项呢？

主要有两种方式：

  1. 利益相关者有自己的想法，主动提出立项RAG应用，这是最容易的，这时候以利益相关者的想法为核心，逐步实现项目即可。

  2. 利益相关者有兴趣立项，但是没有详细的想法，这种情况下就需要我们提出自己的想法。

我们先从第一种开始，利益相关者有自己的想法，主动提出立项RAG应用。

利益相关者有自己的想法

在这种情况下，立项是没有问题的。但是这时候我们可能会面临两个难点：

  1. 利益相关者的想法往往是模糊的、抽象的、粗糙的，需要我们将这个想法变成明确的、具体的、详细的项目计划。
  2. 利益相关者可能高估大模型的能力，但大模型无法实现利益相关者的预期。

那么有什么好的方法可以解决以上这两个问题呢？

关于第一个问题。如果利益相关者职位比较高或者是初创企业的话，可以申请参加国产大模型厂商推出的扶助计划，例如智谱AI推出的Z计划。如果不能参加这些计划的话，我推荐先浏览 百度千帆大模型平台，看看别人是怎么做的。

不得不说，国产大模型在售前和售后工作比国外大模型到位多了。这也是课程没有使用OpenAI以及我不推荐使用OpenAI的原因，因为在这方面，OpenAI等于零。

关于第二个问题，利益相关者可能高估大模型的能力，大模型无法达到预期这方面，我建议同学们应用第14节课提到的四个基础和一个原则来分析。

这四个基础是：

第一，要明白所使用的 大模型的能力边界。知道自己所使用的大模型能干什么，不能干什么。这一点可能对于目前的你还有点难，但是下一点就比较容易做到了。

第二，要明白 自己当前的能力边界。同学们可以根据自己所掌握的技术点，还有这门课里提供的三个实战案例实现的RAG应用，来评估自己能做什么样的RAG应用，不能做什么样的RAG应用。

第三，从 实用和业务角度 出发。业务价值比较大的RAG应用技术难度不一定高，说不定还很容易实现。技术难度高的RAG应用，业务价值不一定高。我们先前学习实战案例1的时候，就讨论过用RAG改造系统所带来的收益，这种思路在你推动其他RAG项目的时候也可以借鉴。

第四， 求稳为上。如果对大模型和自己的能力没有信心，那么选择一旦出错，影响更小的RAG应用会更稳妥。

结合这四个基础，就得到了RAG理想的一个原则——我们要根据自己当前的能力边界，选择技术难度低、业务价值高的RAG应用立项，而且要尽量选择一旦出错，影响更小的RAG应用。

利益相关者有兴趣但没有想法

接下来我们讲解第二种情况，利益相关者有兴趣但没有想法。

既然利益相关者有兴趣但没有想法，这时候就需要我们提出想法了。你可以回顾我们第1节课的内容。

当时我们说过，如果单纯出于自己想加入AI浪潮的私心，就想推进一个RAG改造项目，这样是很难获得上级或者客户等利益相关者同意的。我们必须要让利益相关者看到改造系统所带来的收益，才可能让利益相关者同意我们改造。

目前来讲，最快、最直观地让利益相关者同意立项的方法，就是像第1节课所描述的那样，让改造结果更加直观，将使用RAG技术改造前后的效果做对比。我们可以着重展示改造项目带来的价值，比如如何减少操作步骤，如何节省用户的时间，如何提高工作效率等等。

在这个过程中，我们需要尽量用数字具体量化，例如使用了RAG之后，某个操作由多少步减少到了多少步，而不仅仅是笼统地说可以降本增效。

评估指标和整理原始数据

除此之外，我们在立项阶段就应该考虑到评估指标的设定。我们可以参考第20节课所讲的Ragas评估指标，从中选择好初始的RAG评估指标，并围绕这些指标去思考和整理原始数据，比如将好评、差评拆分为两个字段。

做完这一步之后，我们还要设计好收集用户反馈结果的方式，这是整个RAG应用最重要和基础的一个方面。

系统设计原则

打通了前面几关，我们就打好了RAG项目的基础。接下来就是最核心的部分，思考如何做好这个RAG应用，确保我们能够把美好的想法落地。

在这方面，我们要谨记第21节课讲过的原则——尽量将模糊检索转化为精确检索。

这个原则由两部分组成：

  1. 将模糊检索转化为精确检索。我们可以看到，第1章的精确检索质量比第3章的模糊检索高很多。

  2. 尽量转化，而非绝对的非此即彼。之所以说尽量，是因为要完全将模糊检索转化为精确检索是很难做到的。所以我们只能从多个层面入手，尽量地提高转化率。

根据这个原则，我们就能推导出改进RAG应用质量的两种方法：

  1. 在用户交互层面提供精确信息。

  2. 在业务逻辑层面提供精确信息。

除了这个原则之外，我们还需要牢记，业务价值比较大的RAG应用技术难度不一定高，说不定还很容易实现。因此，在各方面，我们都应该尽量选择技术难度低的方式。

比如说我们在选择知识入库的方式时，就可以这样思考：

  1. 我们先考虑实战案例1所讲的方式，所有数据都已经在数据库里面了，不需要单独入库。

  2. 如果不能直接使用现有数据，我们还可以参考第23节课GraphRAG 适用场景部分所讲的，基于社交关系的风控系统。像这种场景，数据（也就是社交关系）已经入库了，我们仅仅需要将现有数据改造成适合具体RAG技术的格式，比如将其改造成Neo4j图数据库格式。

  3. 如果前面两种方式都不行，我们可以按照第11节课的方案，使用RSS或者RESTful API将数据入库，而尽量避免使用Word和PDF入库。

原型设计

前面所讲的这些方法都是用数据说话，量化且理性。但是除了理性之外，我们还需要像第1、8、14节所描述的那样，提供一个更加直观、能让利益相关者感性认识到我们RAG应用的方式。

不过课程里编写代码、做出界面的方式并不是最优解，这么做成本太高了！记住，在项目成功立项之前，我们要尽量少写代码。

最好的方法是使用原型设计工具，例如Axure、Sketch、Figma、墨刀等，先做一个原型出来。我参与过的项目曾经用过Axure和Figma，专业的原型设计人员使用这两个工具两天就可以设计出效果惊艳的原型，可以同时在感性维度让利益相关者满意，在落地方面让程序员能够实现。

这里我也顺便分享一个踩坑经验，最好请专业的原型设计人员去做原型。因为程序员或者项目经理做出来的原型，美观和用户友好度是不够的，从感性层面上会让利益相关者觉得别扭；美工和需求分析师做出来的原型，虽然美观和对用户很友好，利益相关者很容易买单，但是把这个原型变成代码是有难度的。

总之，术业有专攻，做原型还是要请专业的原型设计人员，内部没有可以寻找外部资源。毕竟原型做得好，项目立项就容易很多。

再次感谢你选择这门课程。RAG领域进步很快，GraphRAG刚火完，现在又出了StructRAG。但是不管怎么变，我们只要掌握第22、23节课所讲的新技术学习、借鉴要领，就可以将这些最新技术整合进我们的RAG应用。

预祝同学们第一个RAG应用项目成功！我知道有很多同学都在努力学习，课程告一段落，但我们的RAG征程仍在继续。最后，这里我还准备了一份 毕业问卷，希望你能花几分钟填写一下，我会根据你的反馈继续优化课程。