本期讨论会参与者：
陈将老师，Zilliz AI云平台负责人
彭昊若博士，FileChat创始人，基于RAG能力的垂直领域应用创业
卢向东老师，TorchV创始人，RAG Solution创业，公众号土猛的员外
RandyZhao博士/王睿博士，OnWish创始人，基金经理/分析师的Copilot
徐嘉浩老师（主持人），Neumann Capital投资人
1 RAG进步很快，但有很多正在解决的难点
RAG主要分为四块，每个环节都有正在解决的难点
RAG流程主要分为内容抽取、索引创建、检索召回和Prompt与生成。
内容抽取中的难点包括拓展内容形式，最早是PDF，现在已经发展到各类结构化数据、多模态等。
创建索引中的难点包括怎么做Chunking，怎么进行数据清洗。
检索召回中包括如何搭配Hybrid Search，采用什么Rerank策略。
Prompt与生成则更与选择的大模型相关。
虽然每一个环节现在都有急需解决的难点，但拆来看每个环节都有提升空间，也或多或少知道该如何改善，仍然处于技术爬坡的早期。
数据清洗是目前RAG主要难点
检索的质量很大程度上取决于数据清洗的质量。换句话说，RAG依赖文档作为知识库，从知识库里边提取到领域相关的信息做问答，合适的文档直接决定提取的质量。
通过观察实际客户案例，绝大部分的文档都不能直接应用。不像行业最初想象的，简单的进行切分后就可以直接使用。
大部分的文档在撰写的时候，面向的是理解自然语言的人。然后在撰写的过程中，也没有对知识进行系统行的分块。这导致在抽取的时候，就很容易造成断章取义，或者信息过于碎片化。
到具体落地的时候，会有很多到行业/场景/客户的定制化需求，这也使得有些客户觉得没有想象中的智能，还需要RAG厂商来处理，或者自己来处理。
短期解决数据清洗难点的方向
文档一般都有大标题与小标题，本身带有一定结构。可以将文档转换为树形结构，不同层级的叶节点对应不同层级的信息。
如果企业有自主开发能力，或者对于文档格式有固定要求。可以将文档信息做标注或总结。这样可以避免在召回的时候只召回了非常小的片段信息，而没有把信息整体召回的情况。
在客户端，也可以为客户提供进行标注/修改的易用界面，方便客户在上传信息后进行二次处理。
长期解决数据清洗需要改变生产信息的方式
虽然有很多类似上面的方法，但短期内不容易被通用框架解决，因为各个业务的信息组织方式都是不统一的。长期来看，信息的消费方式可能会影响信息的生产方式。
比如企业内部的知识，未来可能不以文档的形式存在，可能直接以一种类似树形结构或者其他结构化的方式存在。如果能以结构化的形式展开信息，那对于信息进行检索和消费的效率就会非常高。
如果未来消费信息的形式不是以人的眼睛去看，而是基于大模型+RAG的方式消费，那生产方式也会潜移默化地适应消费方式。但过程可能会很长远。
涉及数值计算的场景很难
去年底Twitter上热议的“雪佛兰事件”就是非常典型的例子，一位Twitter博主通过与客服对话，以1美元的价格购买了SUV，并且系统判断为合理。
例如“最近三年从某家公司一共采购水泥多少？”。这样看似简单的问题，实际上需要经历问题拆解→分布召回→数据加总的过程，非常容易出错。
而到了更广的场景，例如医保局的项目计算，各类药品的起付线、限价，以及涉及到复杂的报销流程，通过RAG来计算仍然难度很大。可能更多仍需要依靠场外协助，例如生成SQL代码到数仓里进行计算，但作为代价客户也要多点几下。
这也能看出来，数值计算+分布召回在RAG中仍然是非常前沿的难点。一方面是大模型本身在做数学问题时容易出现幻觉，例如现在很难做对高数题，甚至四位数乘法都可能出错。另一方面，拆分→分布召回→总结的步骤一多，也非常容易出错。
RAG的可解释性难点
RAG虽然相比Finetune已经比较白盒，但仍然有局限性。例如内容召回了或者没召回，仍然无法解释具体原因，本质上还是模型在决策。
这与传统的Enterprise Search方法BM25不同，BM25的结果可以人为推导，复盘计算，并且对BM25的应用进行改进。
例如一整段话中提到一个词，然后这个词跟问题里面的一个词是完全匹配的。在BM25算法下，只要这个词的出现的频率足够高，或者说这个词足够独特，一定是能够召回。但在Embedding的模型里面不一定，也容易造成预期差。
RAG的场景难点
多数Embedding模型都是为了特定的目的创建的，模型的目的和业务实际目的不一定完全吻合。举个极端的例子，有的Embedding模型是为召回服务的，有的可能是为判断相似性服务的。那如果对Embedding模型的理解不够深入，经验不足，就容易用错模型。例如本来是一个FAQ场景，但Embedding模型返回的可能是与该问题相似的另一个问题。
在应用场景也有很大的不同。例如用Cat来搜索的时候，如果内容中主要是Human和Dog，那该召回什么？还是都不召回？这直接取决于客户的应用场景。
另外除了本身的RAG算法外，针对客户的Feedback数据，如何抽取出来成为对于Retriever文本的Supervision Signal，然后不断提升打磨现有的场景，也非常难但很有价值。
多模态的可用性进展
目前来说，多模态模型去完成生产上的任务，跟单模态模型比较，不管是从召回的能力，而从生成能力上来说还有一定距离，但优势是能够跨模态。
如果应用中，基于图片的语义理解是刚需，把这个多模态模型作为其中一个组件，如把图像的内容给用文字表达出来，然后再用一个单模态的模型去承担后续任务。这样一个组合是比较现实的方案。
传统的搜索在没有多模态或大模型的时候，也做了很多积累。比如有专门的模型，去判断图片上的动物是猫还是狗，形成标签之后，对标签用自然语言的形式去表示。
在对表格的格式有了解的基础上，就可以把表格的格式解析出来，再设计表格中的内容提取出的结构化数据的结构，然后用规则召回的形式去把结构化数据里面的信息给提取出来。
图片一般不孤立存在于一个文本当中的，互联网上的图片往往旁边会附带一些解释文字。这些文字大概率也讲了图片中的内容，甚至有标题、描述这些结构化的信息。通过把这个结构化的信息提取出来，和图片建立一个关联关系。去召回这些结构化信息，然后再把相关的图片给召回出来，这样的方式在目前比较可行。
2 RAG是整体产品，单点突破难做差异化
RAG是系统优化问题
RAG是系统优化问题，分几个模块，各个模块之间又存在联系。
如果想优化端到端的整体质量，不管是召回质量还是回答质量，都需要看成有机整体进行端到端评测，然后逐个优化，并且能拼到一起。
如果要说哪个点比较重要，召回Embedding和Prompt/生成重要。但这两项的行业认知也会随着大模型的发展而水涨船高。
上述两者加起来也不足以解决所有问题，例如先前提到的数据清洗、场景等各个难点。
行业是否分散取决于信息生产方式
也因为有上述诸多难点，出现了很多垂直的RAG方案，或者这个方案适合A场景，那个方案适合B场景。
如果未来信息的生产方式适应RAG做出改变。比如类似当年数据仓库出现后，有了Schema这样结构化的信息存储方式。那行业就可能走向集成，因为很多垂直难点被解决了。
但信息生产方式改变不是一个短期过程，在很长时间RAG市场可能都会比较分散。
3 RAG需求爆发的非常快
RAG需求可以从Horizontal vs Vertical角度区分
Horizonta Solution：将RAG本身技术打包作为Service提供出来。
Vertical Solution：彭昊若博士创业的方向 FileChat 就在此领域，有自己擅长的行业/场景领域，需要与客户的Workflow进行深度结合。
对于需要与行业私域数据结合的Solution，RAG是其中的一部分，但解决方案的壁垒一不仅是RAG，更多在于行业Knowhow。在比较的时候，也不太比较RAG的性能指标，更多比较行业提效。
Horizontal Solution举例
例如Vectara与Twelve Labs：做得是一整套产品，不与行业Domain结合。
例如Humata：主要场景是针对Research Paper做RAG，面相科研人员，有一定行业Domain，但还是更像一个通用型产品。
Vertical Solution举例
例如Extend（网页链接）：一家YC-backed的主做文档抽取的公司。
例如Consensus GPT（网页链接）：GPT Store上现在最火的应用，也主要是面相科研人员需求。
例如Perplexity：其本质上也是RAG基数的延伸，但是面相C端为主。
例如Amazon正在做的导购Bot：涉及到筛选商品，也结合自然语言/语音交流，也是RAG的直接场景应用。
在RAG爆发后，美国在法律、保险、医疗健康、金融领域也都出现了一批Vertical Solution创业公司。
在国内看到了非常多的知识库需求
国内企业有非常多的私域信息，希望通过私域信息做成辅助业务人员的RAG工具，更多可能以定制化解决方案的方式呈现。
例如家电公司有很多家电维修的记录，可以通过维修记录做成RAG方案辅助维修人员。
例如企业内部过去有很多流程以文档和网页方式存在，RAG后可以辅助解决内部运营问题，例如回答“莫员工的行为是否满足企业休假的规范制度”。
例如TorchV还做过不少政府客户，像医保局、行政服务中心也都有RAG需求。
面对2C用户也有泛娱乐化需求，现在有一种形式是讲用的小说做成知识库，然后帮助用户模拟哈利波特或者三体情景进行问答。
RAG有机会成为下一代搜索引擎
很多企业针对自己的内部信息或者面向外部的终端用户，都会应用搜索来解决，但其实没有被很好的解决。
比如Elastic是大家公认的通用解决方案，但可能对Elastic搜索结果满意的没这么多。
拔高搜索技术的还是传统大厂，Google、百度内部有很多未公开的技术，像Embedding、召回也是在这些公司里最先尝试。
RAG再往后发展，很可能会形成搜索的新模式，有的做成通用解决方案，有的做成垂直解决决方案。
4 相比Finetune，RAG更具优势
RAG的功能优势在相对白盒、权限、客户门槛等
Finetune在23年年中更像是通用的解决方案，但随着大模型发展和客户应用增多，更多的场景已经被RAG替代。
相对白盒：虽然RAG相比BM25解释性稍差，但相对Finetune来说解释性仍然更好，并且调整的自由度也更大。
权限好操作：RAG可以对文档进行权限设置，例如哪些文件是A可以看的，哪些文件是B可以看的。但是Finetune后定义什么内容给什么人看难度大很多。
客户门槛：如果做定制化方案，大体量的客户也多数没有Finetune基础。但是应用RAG后，可以做成界面，让客户自己来上传、设置时间、权限，与客户的本地数据打通更加简便。
Finetune需要更多的数据准备成本，但仍然可能幻觉
Finetune要花更长的时间准备数据，即使准备了很好的数据，出现幻觉的比例也较RAG没有明显提高。
例如问题是“San Jose的现任市长是谁？”。在Finetune的过程中即使喂给了他所有市长的数据，模型可能还是会把过去语料对应的老市长找出来。在Finetune的语料中有的是讲新市长的，有的是讲老市长的，模型也会疑惑。
另外Finetune也需要更大更确定的用户场景，Finetune花了这么多精力也需要更大的规模才能有规模效应。
大厂现在有非常多的Finetune立项，主要面对也是大场景。对于企业端的大部分客户，用Finetune来做应该不如RAG的经济效益。
相比Finetune，RAG可以做更多的控制。例如TorchV就对召回得分进行控制，低于基准线就采取备用策略。
5 RAG的评测还缺乏好用的数据集
RAG的评测维度
业界公认将RAG的效果划分为三个维度：召回信息跟问题本身的相关度，经过大模型架构的回答和问题的相关度，回答和问题的标准答案/评测集答案的相关度/吻合率。
现在市面上有不少评测数据集，针对三个维度再进行加权平均，得出RAG的综合评分。
RAG评测数据集建设还很早期
Zilliz 在数据评测上做了全面的测试，在这里也分享一下Zilliz 的经验。
评测维度有相对公认的维度，但是很缺失对应的评测数据集。这里面很大原因是评测数据集需要根据具体的领域/场景，以及有明确的标准衡量哪些正确，哪些不正确。
市面上现在通行的数据集是MS-Marco和BEIR。BEIR里就有例如针对金融、医疗的专业领域数据集，但在召回场景和问答场景的分散度还较为局限。
数据集在映射到实际的使用场景上也有感知差。经常会出现在数据集上测得很好，但到了用户使用场景上，效果很差。例如之前提到的“雪佛兰客户案例”，还需要辅助推理和问题拆解，这类表现往往不尽人意。
HuggingFace MTEB是目前最权威的榜单
Retriever中最有说服力的榜单是MTEB，MTEB也是基于MS_Marco和BEIR的公开数据集进行评测。
但MTEB榜单也比较局限在召回部分，并没有考虑加上问答部分。
考虑加上问答的榜单可以参考RAGAS，RAGAS也采用了多个维度的综合评价指标。
LlamaIndex和Langchain等也有相应的榜单，与RAGAS的情况类似。
6 Hybrid Search与技术栈选择
Hybrid Search的搭配也非常看客户场景
专用的向量数据库例如Milvus即将支持混合检索，老一代技术栈也已逐步支持混合检索方案，混合检索也很可能成为RAG的趋势。
单纯比较ES老方案和Embedding方案，Embedding肯定好于ES，无论是基于公开数据集还是基于大家的普遍认知。
但是Embedding也不是在所有场景下都好。所以把ES+Embedding进行混合召回的话可能会更好。但是怎么进行混合，对实际效果影响很大。比如最简单的RRF基于规则的混排方式，效果就比较一般，至少相比结合了一个好一点的Reranker模型去做混排，如果Reranker是基于某个场景和具体领域优化过，效果就会更好。
ES方式和embedding的结合方案 vs 只用Embedding方案，TopK的选择也有很大讲究，不一定比单独Embedding大召回+重排（比如embedding 粗排，然后把TopK选的的非常大，100、1000这种。再经过Reranker重排，选出Top3、Top5）的效果好。
除了BM25方案外，还可以用基于模型的Sparse Embedding，他的效果介于BM25和Dense Embedding（向量数据库Embedding）之间。但他的好处是比ES BM25的效果在同义词角度上的健壮性更好。
现在很多老的ES方案的细分和Embedding的各种细分的各种混合方案，比如两两混合后，三个混合等等做出更复杂的方法，以求进一步优化。
具体选哪个要看架构复杂度承受能力和场景。ES辅助Dense Embedding，和Sparse辅助DenseEmbedding的提升效果比较局限。但在一些特定领域，问一些稀有关键词，ES+DenseEmbedding的混合效果很好。
选择最适合的技术栈，易用性非常重要
RAG技术栈选择最终还是先看场景，到了具体的应用时候，Chunking怎么做，在哪一蹭做，做大做小，都有非常多影响的点。很难给一个统一的标准，哪种方案好，哪种方案差，只能选择最适合自己的。
易用性是很多评测忽略的点，尤其创业公司客户。其最大的需求就是用最低的成本、最快上手的方式尽快部署，上线以后再看用户的反馈，根据反馈再小布迭代。会不断试用新的组件，对易用性的要求非常高。
对于很多用户场景来说，RAG使用起来差异并不大，甚至OpenAI的Embedding功能就能满足80%的基础需求。
RAG未来不会脱离向量数据库
模型做的是把信息做压缩，然后在压缩之后产生了泛化能力，但不能把原有的数据完整展示给用户。还是要有一个数据管理的地方，存全量数据。
其次，就算大模型能够把这些数据给吸收进入，但数据的管理，比如权限控制，即什么情况下应该给什么用户展示什么样的数据，这样的功能不适合大模型去做，而是数据库或数据管理软件适合做的事情。
现在主流还是用深度学习模型来做检索，ES之前做了些尝试，MDB之前连尝试都没有。
复杂的领域，包括数据清洗和对用户意图的理解。
Elastic定义的清洗主要是按照文档关键词进行Tokenization，然后进行切分。没有涉及到对图标结构进行理解，也没有涉及对图文内容中图片和文字做结合或者绑定关联关系，上面提到的复杂场景都还没做。
在意图理解方面，Elastic的能力也比较有限。这也是比较新的问题，大家都在同一起跑线上，看每家的进化程度。
相比而言，新一代技术栈都在这些领域做了很多功课。
Elastic在搜索场景中有很大的使用惯性，开发者更熟悉。
Elastic自带BM25和KNN-混合检索，也支持调配不同算法在混合检索中的比重。
针对不同的用户，自变量更多。例如问答量大的时候，会调大BM25.在语义比较重要的时候，会把KNN比例调大。
但是Elastic算法比较单调，目前没有太多可以和CUDA的结合。
相比Elastic，MongoDB做的更晚，在去年需求起来后才开始补作业。
7 RAG的商业化与GoToMKT
RAG的受众主要是算法工程师和软件开发者
目前看稍微大点的客户，其RAG开发者主要是算法工程师，或者偏向业务逻辑的算法工程师。
稍微小点的客户，一般都是APP工程师和Web前端工程师。
也有看到一些数据工程师在做。
Horizontal RAG运营好开源社区非常重要
目前构建社区在Horizontal RAG产品中非常重要，这批开发者业余上一代开发者的Mindset有很大区别。
这批开发者有一个特点是已经熟悉各类开源的新技术栈了，动手能力很强，但对过去的机器学习领域可能没那么了解。
所以给他们的产品如果是开源的，那就要易用性特别好，同时在社区内辅助了大量的内容属性，比如怎么做检索、RAG的优化指南等。
开源打法就是要把整个生态开放出去，等成为事实性标准后再做商业化。如果AI浪潮能够影响一代人，就会有很多机会来做开源。
Zilliz就是从做开源Milvus起家，开源是非常好的获客手段，现在在行业内也有大量的拥泵开发者。
像美国的Vectara，其技术实测下来可能没有什么差异化，但面向群体的社区做得很好，对产品起量帮助就很大。
Vertical RAG可能更需要从SLG方向起家
先从一个垂类开始做，例如FileChat最先进入的是供应链垂类。
通过SLG方式找到垂类中的RAG特点，通过客户反馈打磨客户形态，然后再进入新的垂类。
FileChat同时还做了一个2C网站（网页链接），用来收集客户反馈和销售线索，同时打磨终端的产品形态，形成初步的垂直社群。
RAG垂直应用的价值链拆分
RAG 技术栈在Vertica Solution中是偏后端服务，一个完整的Solution包括还大模型、以及应用服务商。
以金融行业为例，大模型本身在这个方案中可以占到10%，RAG大概占3%-5%，占比不高，因为一方面有开源的工具和产品，第二点是这里需要客户的internal development。
在工业方面也是类似的，技术产品其实占比还是比较少的，给10%-15%是合理的范围。这种方案更多的部分是在Service的部分，比如现在很多应用是替代人工录入。
垂直产品卖点多很简单，就是帮客户省钱。通过技术取代人工录入，现在也没有实现100%的的替代。假设客户这部分被完全替代了，那就会有更大的预算流出给RAG垂直应用，或者其他的第三方技术服务商。
8 金融领域的RAG应用
金融领域对RAG有独特需求
市场研究，Recall First的场景，也是选择Hybrid的原因。市场研究特别注重信息的全面性，不能漏，任何一点疏漏都可能对投资判断产生影响。
光用Embedding来达到稳定的不落下内容有一定难度，所以需要加上传统搜索配合。但光用传统搜索也更不可能满足，例如从Amazon的财报中找客户对于GenAI的反馈，Earning Transcript里可能就没出现Customer字眼，那就只能用Embedding Search来解决。
在Tempera Data和Text Data中会有很多Mix，传统的做法是在Tempera Data中MetaData以及Table中Headline作为Input。那么如何能够把这个table里边的更多的spectral information，以及这些table当中不同数据当中的causality correlation能够找出来，然后跟Text一起做inference，这个也是其中的一个很重要的一个挑战。
市场研究还有很多Multi-Step Query，就是上一步的Output是下一步的Input。
Reranking不同Source的可信度也不一样，会影响输出结果。例如公司口述信息、投行卖方信息、自媒体信息的可信度就完全不一样。
Retriever的过程中也要用到很多Tools。比如在金融场景中，非常的Mission Critical，比如很多计算场景LLM就做的不好，那就需要辅助涉及计算的工具。
金融领域也缺乏Dataset
Vertical场景的评测数据集有很大的不同，在金融场景两个月前发布了一个数据集叫做Financial Bench。相比于传统评测数据集，他们更像是QA。但也看到了两个问题。
第一个问题是在投资领域的Diversity很高，有时候需要做市场空间分析，有时候需要做行业竞争分析，更应该从分析师视角去设计评测集。让作为使用者的分析师，能够感觉到不同场景的区别。
第二个问题是很多评测数据还是在为了解决传统NLP场景的问题，很多数据已经过时了。下一步应该与更多行业专家去丰富评测数据集。
Onwish的RAG搭建实践
Search是Onwish系统中很重要的部分，总体分成三大块。
第一块：在找寻信息，做了很重的Planning。从什么数据源找信息，应该找什么样的信息，该用Keyword找还是用Embedding Search找。
第二块：Retriever模块。BM25+Embedding的Hybrid Search。有了Retriever的Rerank，会作为备选的Answer Candidate进入LLM。
第三块：LLM来判断Retriever的Answer里哪一块能够更好回答用户的信息，synthesis answer。