许多从业者发现，尽管RAG能在短时间内快速搭建出Demo，但在实际生产环境中落地却困难重重。本文从AI大模型领域创业者的视角出发，深入剖析了RAG在产业落地中的核心问题——问题分级，并详细探讨四类问题的挑战与解决方案，供大家参考。
很多熟悉RAG的产品经理和工程师会吐槽，“做RAG一周就可以出Demo，但真正做到能上生产环境的水平，半年时间都不够！”。
这是现阶段RAG在产业落地的现实问题。RAG框架非常简单易懂，也有很多优化RAG全流程的方式和手段，风叔在此前的文章中也做过详细介绍，《Rag系统的发展历程，从朴素、高级到模块化》。
但无论是企业内部使用，还是面向C端用户，大家最直接的感受是，RAG只能检索和回答相对浅显直观的问题。
企业知识库领域的独角兽Hebbia也曾经做过实验，RAG实际上只能解决企业内部16%的问题，这到底是什么原因呢？
答案是问题分级。
任何用户检索问题都可以分成四类，显性事实查询、隐性事实查询、可解释性推理查询和隐性推理查询，这四类问题的复杂度和解题难度依次提升。
下图列出了每类问题面对的挑战和解决方法。可以看出，只有显性事实查询和部分隐性事实查询，可以通过RAG、Iterative Rag或GraphRag来解决。而可解释性推理查询和隐性推理查询问题，RAG就没有用武之地了，需要依靠其他更复杂和针对性的解决方案。
在实际企业应用场景中，绝大多数对业务部门有价值的问题都处于Level 3和Level 4，因此导致了“RAG一周出Demo，半年上不了线”的窘境。
接下来，风叔将详细阐述这四类问题的特点和解决方案。看到最后，相信你一定会有收获！
显性事实是指外部数据中直接存在的事实信息或数据，不需要进行额外的推理。比如“2016年奥运会在哪里举办的？”、“某传感器的品牌和工作温度是多少？”、“门店A上个月的营业额是多少？”。
显性事实查询是最简单的查询形式，直接从提供的数据中检索到明确的事实信息，不需要复杂的推理和思考，因此非常适合使用RAG。
当然，要准确、高效地检索和生成相关内容，还需要对RAG系统进行优化。可以通过风叔之前介绍的方法，这里再做个简单的回顾。
隐性事实并不会直接在原始数据中显现，需要少量的推理和逻辑判断。而且推导隐性事实的信息可能分散在多个段落或数据表中，因此需要跨文档检索或跨表查询。
比如，“查询过去一个月营收增长率最高的门店”，就是一个典型的隐性事实查询。需要先获取所有门店这个月和上个月的营收，然后计算每个门店的营收增长率，最后排序得出结果。
隐性事实查询的主要挑战是，不同问题依赖的数据源和推理逻辑都各不相同，如何保障大模型在推理过程中的泛化性。
隐性事实查询的主要解题思路包括以下方法：
Iterative Rag：在检索前先生成检索计划，然后在检索过程中不断根据检索结果进行优化。比如利用ReAct框架，沿着Thought – Action – Observation的分析思路，逐步逼近正确答案。
Self-Rag：构建四个关键的评分器，即检索需求评分器、检索相关性评分器、生成相关性评分器和回答质量评分器，从而让大模型自主决定何时开始检索、何时借助外部搜索工具、何时输出最终答案。
Raptor：RAPTOR 根据向量递归地对文本块进行聚类，并生成这些聚类的文本摘要，从而自下而上构建一棵树。聚集在一起的节点是兄弟节点；父节点包含该集群的文本摘要。这种结构使 RAPTOR 能够将代表不同级别文本的上下文块加载到 LLM 的上下文中，以便能够有效且高效地回答不同层面的问题。
GraphRag：一种将知识图谱与Rag相结合的技术范式。传统Rag是对向量数据库进行检索，而GraphRag则对存储在图数据库中的知识图谱进行检索，获得关联知识并实现增强生成。
将自然语言转换成SQL查询
text2SQL：主要用于数据库查询，尤其是多表查询场景，可参考《一文读懂ChatBI的实现难点与解决方案，问答准确率超过99%》
可解释性推理，是指无法从显性事实和隐性事实中获取，需要综合多方数据进行较为复杂的推理、归纳和总结的问题，并且推理过程具备业务可解释性。
ChatBI中的归因分析，就是典型的可解释性推理，比如”过去一个月，华南区域营收下滑5%的原因是什么？“。这个问题无法直接获取，但可以通过一定方式进行推理，如下所示：
总营收 = 新客 * 转化率 * 客单价 + 老客 * 复购率 * 客单价
经过分析，新客数量、转化率和客单价并未发生明显变化，而老客复购率下滑约10%，因此可以推断出可能是”服务质量、竞品竞争“等原因，引起了老客复购率的下滑，从而导致了总营收的下降。
可解释性推理问题主要有两个挑战，多样化的提示词和有限的可解释性。
面对这样的挑战，风叔主要有以下建议：
优化提示词：需要有效地将业务推理逻辑，整合到大语言模型中，比较考验提示词设计人员的行业know-how。
提示词微调：手动设计提示词会很耗时，可以通过提示词微调技术解决这个问题。比如通过强化学习，将大模型生成正确回答的概率作为奖励，指导模型在不同数据集上发现最佳提示词配置。
决策树：将决策流程转换为状态机、决策树或伪代码，让大模型执行。比如在设备运维领域，构建故障树就是一种非常有效的故障检测方案。
Agentic Workflow：通过workflow构建大模型思考和行动的具体步骤，从而约束大模型的思考方向。这种方法的优点是能够提供相对稳定的输出，但缺点是灵活性不足，同样需要针对每类问题设计工作流。
隐性推理查询，是指难以通过事先约定的业务规则或决策逻辑进行判断，而必须从外部数据中进行观察和分析，最终推理出结论。
比如IT智能运维，并不存在先验的完整文档，详细记录每种问题的处理方法和规则，只有运维团队过去处理的各种故障事件和解决方案。大模型需要从这些数据中挖掘出针对不同故障的最佳处理方案，这就是隐性推理查询。
同样，在产线智能运维、智能量化交易等场景中，都涉及大量的隐性推理查询问题。
隐性推理问题的主要挑战是逻辑提炼困难、数据分散和不足，是最为复杂和困难的问题。
对于隐性推理问题所面临的挑战，有以下解题思路：
在本篇文章中，针对Rag上手容易上线难的问题，风叔介绍了用户检索的四类问题，以及每类问题对应的解题思路。
对于显性事实查询和隐性事实查询类问题，可以通过多种Rag优化方案来解决。但是，面对可解释性推理和隐性推理问题时，只使用RAG就会力不从心了，需要引入提示词工程、决策树、Agentic Workflow、机器学习、模型微调和强化学习等多种方法。
其中每个方法要详细展开阐述的话，都可以单独写一个系列。因此，本文只是先抛出这些解题方向，不做展开。后续有时间，风叔再结合实际案例做详细介绍。
本文由人人都是产品经理作者【风叔】，微信公众号：【风叔云】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。