平安壹钱包：RAG 等技术在金融支付类 ToC 应用场景的探索与落地_AI阅读总结 — 包阅AI

以下是王良老师分享全文（经 InfoQ 进行不改变原意的编辑整理）：

非常感谢 InfoQ 极客传媒的邀请，也很荣幸能有机会就大模型在金融支付类公司的应用落地和大家进行交流，抛转引玉 ，今天跟大家聊一聊我们平安集团的平安大模型以及在业务落地上的一些实践和经验。

首先，大模型大家肯定都是知道的，自从 ChatGPT 这款应用产品发布之后，仅用了两个月时间，全球用户数就突破一亿了，这比我们人类历史上所有的流行产品速度都要快很多。2 个月破亿这个记录有多惊人，我给大家看一组数据。

固定电话用户破亿用了 75 年，手机 16 年，当智能手机普及之后进入到移动互联网时代，破亿的速度首次缩短到 6 年内，并且以极快的发展速度进入到 1 年以内。从固定电话到移动电话，再到互联网时代的应用程序，信息传递的速度不断加快，信息传递的方式和载体也发生了根本性的变化。说一个大家可能没有察觉到的细节，比如打电话的手势已经在现在的小朋友过家家时不再使用了。

换成了手掌平方在 耳朵边

这预示着信息传播方式的巨大变化。当下许多研究报告和机构预测，到 2026 年，将有 80% 以上的企业接入生成式 AI 或大模型。我个人觉得这个不算激进，甚至还有一些保守，那么以上这些信息汇总起来看，就是告诉我们，要快，不然就跟不上要掉队了。

那么为了不掉队于时代，我们进行了多次调研和头脑风暴，讨论的结果有 2 个确定和 1 个不确定。其中一个确定是【确定未来：AI 大模型未来的前景是明确的，AI 必然会重构世界。】他不像元宇宙或者 web3.0 先有概念，在概念出来后，都在等应用场景的普及，等发展。另一个确定是：【确定现在: 要想不掉队就必须现在就开始进入】，AI 的发展太迅速了，等慢悠悠的确认好方案的时候，友商公司已经有成品了。不确定的是：【不确定落地场景：解决什么需求？降本增效还是扩大收益？用什么技术？开源闭源。。。。。。】这些都是不确定的，这就会涉及到如何去寻找落地场景的问题。2 个确定是全员达成一致的，我们很快就聚焦在不确定的落地场景上，在这里我要特别强调一下，在立项之前，决定做什么的阶段，技术不是影响价值最大的，想要选对选好有价值的落地场景，很重要的一点就是业务驱动，要找能支持项目落地且能持续运营的业务场景，有运营不断的反馈、维护、营销，才能保证项目是可持续发展的。接下来给大家一些寻找落地场景的思路。

1. 从最熟悉的领域入手

2. 让 AI 学习最优秀员工的能力，再让它辅助其他员工，实现降本增效

3. 寻找“文本”进，“文本”出的场景。因为任何问题都可以用语言去描述，把大模型看做是一个函数，给输入，生成输出，大模型最厉害的就是回答你的问题。

4. 不要追求大而全，将任务拆解，先解决小任务，小场景，再考虑怎么工程化的把每一步整合起来，这也是周鸿祎说的“小切口大纵深”。

选好场景在制定落地方案时，有 3 个重点：原理、实践和认知。如果没有深入理解大模型的原理，就没办法举一反三，走不了太远。一定要有实战经验，没有实践，只能光纸上谈兵做事不落地。认知水平不高，就没有办法做出最优的决策，能达到的天花板就很低。

场景选好，接下来就是技术选型。模型分为开源模型和在线模型。开源模型可以部署到本地，前后台链路都在自己手里，模型文件、项目文件、还有模型权重、等等在本地部署，因此可以更好的确保数据安全性。但成本也更高，因为需要自己购买硬件，还需要投入技术进行维护。在线模型就可以通过 API 调用，在线模型普遍性能更强，调用的技术门槛和硬件门槛更低，配套模型生态和服务更加完善，不需要维护，前期成本投入会比较少。知道这两种优缺点还不足以评估技术选型，因为还要了解国家的政策要求。不同的类有不同的政策要求。一些有监管要求的企业在政策上是不允许使用非开源大模型的，比如银行在使用大模型时，把用户数据上传到百度、阿里、OPENAI 的大模型就有可能会涉及到法律合规问题。

无论哪个行业，只要是面向用户的，他就必须符合监管要求，涉及到国家的法律道德、涉及到意识形态、那这个在合规性方面要求是非常高的。在用大模型的时候，我们担心的可能是大模型无法回答问题或给出错误答案。但更害怕大模型随意回答，尤其是在涉及国家、民族和相关的重要历史问题时，必须确保大模型不会在这些问题上“一本正经地胡说八道”，这造成的后果是很严重的，所以选择一个靠谱的大模型是非常重要的。目前国内报备审批通过的大模型效果都是很好的。这张表是面向 C 端用户、面向政府、面向商用、出海的一些要求，如果本身对数据安全的要求特别高，那么只能选择开源大模型来保证数据隐私。

在 2023 年 7 月 10 日，政府发布了一项声明，强调了生成式人工智能服务安全的基本要求。根据这一声明，任何 To C 的人工智能服务在上线前都必须根据各种暂行办法报备，并接受审查。虽然现在只是暂行办法，但这不意味着没有约束，暂行办法背后有《网络安全法》、《数据安全法》和《个人信息保护法》等法律法规的支撑，如果违反这些规定就可能会面临处罚或者下线。关于报备的经验和一些关键信息的填写，我整理了一份文档在 PPT 中有提到，大家可以在 archsummit 官网下载我的演讲稿资料查看 。

简答说一下我们的应用落地场景, 一个即时的回答企业微信用户的 AI 运营平台，主要目的不是给大家演示我们的产品，而是展示产品背后的运作逻辑。

在这个场景中，我们应用了 RAG 的技术，把一些业务场景中的知识输入大模型。这个知识库中包含活动营销的相关信息，也包含一些行业规范等内容。我们会提取文本进行数据清洗，然后切割成 chunk 文本嵌入到向量库中。当用户提问时，问题本身也会被转换成向量形式，与向量库中的向量进行匹配，然后通过 prompt 提示词工程和平安大模型，返回生成的答案给到用户。

那么我们为什么用 RAG？因为大模型还是有一些小缺陷或者说是不足的地方，比方说模型训练数据 cut-off 、私有数据、保密数据、可解释性、幻觉等问题。如果问大模型， ArchSummit 2024 架构师峰会有什么议题它可能搜索不到，某位讲师讲了什么它也搜不到，它还可能乱答一通，这就是所谓的幻觉。

为了提高问题答案的准确性，我们可以提前把大会的数据和讲师的演讲内容资料，输入到模型中。通过知识库的输入，进行向量化处理，这样做检索的时候，就能得到准确的结果。

如果模型没有相关信息，是否意味着只能通过 RAG 技术来解决这个问题呢？其实也并非如此。还可以考虑使用 Fine-Tuning 技术，也就是我们常说的大模型微调。那么我们为什么不采用微调？一个是因为微调的投入产出比不高，技术难度大；一个是因为它改变模型的权重。容易造成副作⽤。比如大模型原本计算出的答案不符合预期，我们通过手动调整让他在某个知识点返回我们想要的结果，这就相当于改变了大模型的思维方式。后续再回答其他问题时，比如说，“天王盖地虎”下一句应该关联“宝塔镇河妖”，它给你返回“小鸡炖蘑菇”。这种改变可能带来不可预知的副作用，而且因为数据量庞大，几乎无法覆盖验证。但是 Fine-tuning 技术有其他优势，通过调整以后的内容可以跟原始的大模型融为一体，检索速度会更快，因为不需要再次在向量库中进行匹配，我们当前的体量和技术储备在微调上投产比太低，所以我们选择 RAG，它更容易实现一些。

在实际落地的过程中，我们也遇到了一些问题和挑战。我大概归类 为 8 个方面。

首先是数据源加载和处理。数据量是很庞大的，用户提供的语料库和资源库要输入大模型或者 RAG 的时候，会发现有各种各样格式的文档，即使格式相同，内容大纲和排版也不一样。此外，还有各种的扫描文件，处理起来非常复杂。大模型对 Markdown 格式文档是天然友好的，在初期，我们只能通过手工去约束业务方，尽量按照一定的标准提供数据。需要尽量做好，因为这是整个流程的第一步。就像进行很长的公式计算时，我们不要第一步就把π用 3.14 做出计算结果，带到下一步，我们最好先用π做逻辑运算，在最后一步再用 3.14 求计算值，因为随着计算步骤和环节的增加，误差会逐渐增大。如果在第一步就损失了精度，后续想提升精度就会变得很困难。在一开始，尽可能地进行约束。

然后就是数据切分难的问题。当我们提供数据给大模型后，大模型怎样进行切分，怎样确定向量，这些都是我们不可控的。对于这些问题，通常有五种技术解决方式，

第一种方式是直接将知识当做问题的前置条件输入询问大模型。用《西游记》来举例子，如果我们想问《西游记》相关的问题，假设大模型对《西游记》的知识储备是 0，我们可以将整套《西游记》的文本在问答文本框输入给大模型，并同时提出问题。比如，要求大模型根据故事总结“三打白骨精”的情节，大模型能够做到这一点。但这里存在一个“不可能三角”，如果输入的文本很长，大模型的注意力集中度会提高，但同时算力也提高了，成本也会增加。相反，如果我们的输入不够清楚，或者只输入了“三打白骨精”这一部分的章节，没有师徒四人组队之前的章节，大模型就无法准确捕捉到故事中每个角色的形象和性格，提供的“三打白骨精”的总结可能就不那么准确，也就是说文本长度短了，“注意力”就下降了，算力虽然低了，但是答案就可能没有那么准确了，这就是【文本长度、注意力、算力】的“不可能三角”。

第二种方式是手动切分。继续以《西游记》为例，如果我们还是想要大模型总结“三打白骨精”的情节，我们可以手动输入情节，比如将唐僧师徒的经历和取经的背景外加“三打白骨精”相关的章节输入大模型，去除其他不相关的章节，比如女儿国和火焰山等、其他章节的故事。

第三种方式是利用 LangChain 等工具。这个就是等官方出解决方案，我们碰到的问题在其他公司也是普遍存在的，如果我们无法解决，就可以等待官方去解决。

第四种方式就是上文中提到的微调。当前我们只是对一些语气和回答文案的风格做了微调，使答复内容更亲切更客气一点，不改变检索的内容。如果你的用户量极大，投入足够的技术和精力去微调，提高响应速度，基于庞大的用户体验上，是值得去做这件事的。

第五种方式是利⽤OpenAI Assistant API 进⾏⻓⽂本读取，它具备 knowledge retrieval 功能，翻译成中文就是知识检索功能。就是在提问之前先上传文档，让大模型消化这些文档。这与 RAG 有些相似，RAG 是我们已经事先将所需的语料库输入大模型，等待用户随时提问， Assistant API 是将接口开放给用户。让用户自己上传文档后再提问，相当于将原始文档数据交给了对方。

检索效果的问题，即大模型给出的答案可能不是用户想要的，或者不满足要求。这里建议优化提示工程 prompt 。这是一个门槛低但上限极高的技术。如果用得好，它可以极大地激发大语言模型的涌现力。

关于检索结果过长的问题，也是可以通过提示工程 prompt 来解决。比方说，我们可以限制大模型最多只给出五条答案，每条不超过 2 万字或者 2 千字。如果答案过多，也可以要求大模型进一步总结，然后继续提炼。

可解释性是指的是大模型给出了答案，但用户并不知道它是否正确，答案已经超出了用户的认知范围，看起来非常通顺 非常正确。鲁棒性是指模型在面对各种异常情况或不完美的输入时，仍能保持稳定和可靠的性能。有点类似于拼音输入法在我们拼错拼音时也能打出正确的字，简而言之，它是指模型对于噪声、异常值、缺失数据、模型假设违反等情况的容忍程度。

接下来讨论的是复杂 query。简单来说，如果我们询问去年东方航空的财务报告情况，通常能够找到相关信息。或者东方航空的财报查询不出来的话，一般的其他上市公司的财报也能查出来。但如果要对比东方航空从 2019 年到 2023 年的财务情况，并和竞争对手进行比较，即使有数据，也可能不够准确，不符合我们的需求。对于这种复杂问题，我们建议使用自动化的方法来解决。像 Function calling 继续发展下去，就基本衍化成了 Agent

关于自动化的四个方面，首先是 ALL tools ，像上文提到的，指的是如果遇到问题，可以等官方推出新的工具来解决。因为我们遇到的问题可能不仅仅是我们自己的问题，其他开发者或者公司普遍也会遇到的问题。碰到问题的人多了之后，官方就会着手解决。原生的大模型框架会越来越多的集成一些工具在内部，比如 OPEN AI 和 GML 4 的 Knowledge Retrieval 两个大模型都是围绕长文本进行问答的，ALL Tools 当然会有很多其他的 Tools ，比如绘图、图生文、等等，多模态不仅仅是它具备图文视频这样的能力，而是底层能够近乎无损的进行文字和图片的转化，是一个更加底层的能力。

ReAct 是可以通过信息检索增强我们推理能力的一个东西，它不仅仅能去做推理, 还可以和环境外部数据去做交互获取一些额外的业务知识。

Function calling 是函数调用，它允许模型调用外部函数或者工具来执行特定的任务，举个例子，我们使用手机拍照，是用手点击拍照 APP，然后拍照。这个手就是调用 API 的方式，相机的 APP 就相当于 Function 函数等着我们去调用它。

而 Agent 的概念则类似于我们有一个秘书。我们可以告诉这个秘书，“请帮我拍下今天的演讲材料，我回去需要做汇报，请尽量拍得清晰。”秘书在执行任务时，就不仅仅是简单地点击相机 APP 拍照 。他拍完之后要检查一下，如果发现拍糊了，要删除重新拍。如果照片中有遮挡，他可能会换个角度或者等更好的时机再拍。这整个过程就是 Agent 将多个 Function calling 集合起来执行一个任务，当然前提是 Agent 提出的 case 本身是支持 Function calling 的，在这个例子中，就是检查照片是否清晰、删除照片、移动位置换角度这些都要单独抽支持被调用。

最后就是反馈、评估和迭代。这就是字面上的意思，在发布了产品之后，怎么知道它的表现好不好？就需要收集反馈的数据，比方说，回答的质量如何，检索质量是否达标，引用是否完整等在前期的每个环节。如果想检查其中某个环节，就应该在那个环节做好数据的召回、采集和埋点等工作。

最后总结一下上手实践的一些经验

再说一下标注平台，我们要怎么提高我们私有化知识库的质量 ，首先，我们先导入数据，将知识库导入后，数据清洗会提取出很多知识碎片。接下来是向量化数据，我们自己先生成一系列问题，自问自答，创建 QA。对这些 QA，我们先自动处理一遍，忽略那些没有歧义 ，而且匹配度特别高的。对于匹配度没那么高的，我们就分配给人工标注。

在人工标注阶段，我们需要选择对业务熟悉的人员进行标注。假设现在我们的知识库是涉及医学领域的，我们就选择有医学知识背景的人来标注，而不是选择非医疗从业者完全不了解的人。我们的经验是，通常，在一个公司内部有很多熟悉业务的人员，比如产品、业务、开发和测试。在这些人里面，测试可能是最合适的选择，因为他们愿意去点，其他人可能点着点着不耐烦了就瞎点。对于标注的人，我们也进行了培训。标注完成以后，就进行质检和审查，确保没问题，然后才能继续进行下一步。

然后就是持续进行迭代，先是将数据导入数据库，接着清洗数据。比如我们生成大约 1000 条 QA，其中有 500 条需要进行人工验证。验证完毕后，我们再不断进行调整，直到确保准确无误。没有问题之后，我们就将其发布上线，用户再去查询的时候就可以获取到真实的数据。

接下来再介绍一下我们已经落地的另一个应用场景。用来总结分析用户被风控拦截的原因。如果人工处理，需要查询多个系统，看身份类型，账号风险，交易风险，操作流程等 ，可以 用工具批量汇总，但是人工分析太耗费时间了，精力不足，我们把需要 关注的关键信息都提供 Function Calling 接口 ，让 大模型自己去查信息，去分析前后逻辑和原因。给出每个 case 的拦截原因说明。下图案例中底部的分析报告【客户在 2016 年注册，但在 2024 年 6 月 9 日首次绑卡，绑卡成功后设置支付密码，随后发起高风险交易。操作、交易归属地为广东，客户本人归属地为云南，交易在异地发生。交易场景为 500 元话费充值，为高风险场景大额交易。综合以上信息，该客户判断为高风险客户。】就是 Agent 在调用了多个用户的相关数据后，分析并整理成文案反馈的。

在大模型的浪潮下，未来的趋势之一是脱离“信息的茧房”。我们每个人的精力有限，最多只能精通两三个行业，比如说我们需要涉及医疗或其他领域时，能够快速检索到相关信息，将各行业顶尖的能力赋予普通人，这也意味着程序员之间的技能差距可能会缩小。在过去，一个有着十年经验的程序员与一个两三年的小白之间的差距很大，但未来，通过 AI 的帮助，新手跟顶级程序员的差距就没有那么大，进步的速度会很快，新手从一出来就基本上满级。再就是对小而美的创业团队的重大机遇，如果能够开发出爆款应用，市场潜力将非常可观。

最后说一些我个人对大模型应用架构师职责的理解，第一个关键在于如何提高答案输出的准确性和稳定性，这是大模型应用架构师职责的核心。另一个重要的考量是成本效率。无论是私有化部署还是去调在线的 API，成本和技术投入都不小。我们要不断提高系统的效率和准确性，不要让用户多次尝试才能找到满意答案，降低成本也提高用户体验。最后是维护好系统的稳定性健壮性，不要频繁出问题，影响业务。

感谢您阅读到最后，如果有感兴趣的点，也欢迎您留言进行交流。