RAG以其结合外部知识库和大型语言模型（LLM）的强大能力，展现了巨大的潜力。然而，做一个RAG原型只需要1个小时，但要转化为一个在真实业务场景中稳定、可靠、可信赖的产品，需要跨越一系列重大障碍。
第一部分：检索（R）环节的挑战
检索的质量直接决定了RAG系统性能的天花板。如果检索环节无法为生成模型提供准确、相关、完整的“原材料”，后续的一切都将是空中楼阁。
问题1：知识的摄入与预处理
这是最基础、最容易被低估，却也最致命的环节。
- 1）非结构化数据处理的复杂性
企业知识库中充斥着PDF、Word、PPT、图片甚至扫描件。
- 版式解析失败
PDF中的多栏布局、跨页表格、页眉页脚、图表和公式，在自动化解析和文本提取时极易造成内容错乱、信息丢失。
- 表格与图像的“黑洞”
虽然MinerU、VL等工具或模型的准确率越来越高，但是对于复杂表格等可能需要做专门处理，仍需人工检验、优化，而且最好可以过滤掉和RAG无关的信息。
2）知识的质量与一致性
内容过时与版本冲突
知识库中常常包含多个版本的手册、相互矛盾的政策文件或已失效的公告。系统必须有能力识别或被告知知识的“权威版本”。
- 事实错误与噪声
源文档本身就可能包含错误信息。RAG系统会忠实地放大这些错误。
3）文档切块的“艺术”
规则切块的弊端
简单粗暴地按固定字符数（如1000字）或标点符号切分，极易切断完整的语义单元，导致上下文丢失。一个问题的答案可能被分割在两个独立的块中，导致检索失败。
- 语义切块的挑战
根据段落、标题等语义边界进行切块效果更好，但这需要为不同格式的文档编写复杂的解析规则。
- “大海捞针” vs. “只见树木”
块太大，包含太多无关的“噪声”，会干扰LLM的注意力，导致“迷失在中间”问题（大模型可能更重视开头和结尾的信息）；块太小，上下文信息不足，LLM无法进行有效的推理。
4）知识的结构化与关联性 为了对知识之间内在的、丰富的结构化关系建立联系，高级的RAG系统需要引入知识图谱（Knowledge Graph, KG）。知识图谱将非结构化文本中的关键信息，如实体（人、项目、部门）、属性和它们之间的关系（
隶属于、负责人、技术栈），提取出来并以图的形式进行结构化存储：构建成本极高
从海量、异构的文档中自动构建一个高质量的符合业务场景的知识图谱，本身就是一个复杂的NLP（自然语言处理）工程，涉及命名实体识别（NER）、关系抽取（RE）等多个技术环节，且往往需要大量的实体定义、关系建模和领域专家校验（很多场景的实体和关系是需要自己设计的，不能直接使用GraphRAG等）。
- 查询与检索的融合复杂性 (Graph RAG)
引入知识图谱后，检索环节不再是单一的向量搜索。系统需要一个更智能的“查询规划器”（Query Planner）来决定：用户的这个问题，是应该去向量库里找相似文本，还是应该去知识图谱里做图查询（如路径遍历），或者是两者结合？例如，回答“负责‘凤凰项目’的经理的上级是谁？”，就需要先在图谱中找到“凤凰项目”->“负责人”->“上级”的路径。这种融合检索的架构设计和实现非常复杂。
- 生命周期管理难题
知识图谱也需要与源文档同步更新，这引入了额外的维护成本和数据一致性挑战。
问题2：实体级别的模糊性
文档内容本身充满了需要消歧的实体，这与简单的段落匹配是两个维度的难题。
- 1）实体识别与链接
系统需要能识别出文本中的关键实体，如人名、项目代号、产品名称、部门等，并将其链接到唯一的实体ID上。
- 2）实体消歧
当用户提问或文档中提到“张伟”时，系统需要有机制去分辨这是研发部的项目经理“张伟”，还是财务部的总监“张伟”。缺乏这种能力，会导致检索到错误的人员信息。
- 3）同义词与别名
用户可能会问“凤凰项目”，但官方文档中的名称是“Project PXR”。系统必须维护一个庞大的同义词库，建立各种实体名词的别名库。
问题3：检索召回的准确率
即使用户的问题和知识库都很清晰，传统的检索方法也存在瓶颈。
- 1）语义鸿沟
用户的口语化提问与文档中的书面语或专业术语存在巨大差异。单纯依赖向量相似度，可能无法捕捉到这种深层联系。
- 2）关键词的刚性
对于必须精确匹配的专有名词、产品型号、错误代码，向量检索的“模糊性”反而成了弱点。
3）为了解决上述问题，必须引入更复杂的检索架构：
混合搜索 (Hybrid Search)
结合向量搜索的语义能力和传统关键词搜索（如BM25）的精确匹配能力。
- 查询重写/转换 (Query Rewriting/Transformation)
在检索前，先用一个LLM将用户的原始问题，改写、扩展成多个更适合检索的、包含更多潜在关键词和表述方式的查询。
- 多路召回与重排 (Multi-path Recall & Reranking)
从多个来源（如向量库、关键词索引、图数据库）召回大量候选文档块，然后用一个更强大、更消耗资源的重排模型（Reranker）对这些候选块进行二次排序，选出最优的几个交给生成模型。这显著增加了系统的复杂度和延迟。
第二部分：生成（G）环节的挑战
即便检索环节提供了完美的上下文，生成模型（LLM）的行为也充满了不确定性。
问题1：幻觉与事实不一致
- 违背上下文的“创造”
LLM并没有100%忠实于提供的上下文，而是出现了“创造性发挥”。它可能会错误地概括、进行不当推理，或将多个不相关的上下文片段捏合在一起，制造出看似流畅但与原文事实相悖的“新知识”。
- 引用外部知识的污染
LLM可能会不自觉地混合使用其庞大的内部知识（训练数据）和RAG提供的上下文，导致答案被污染，尤其是在上下文信息不充分时。
问题2：上下文的综合与推理
- 多源信息整合失败
当一个问题的答案需要从多个、甚至观点有些许矛盾的文档片段中综合提炼时，LLM可能会表现不佳。它可能只关注了第一个或最后一个片段，或者无法构建一个连贯的逻辑链条。
- 复杂逻辑推理的瓶颈
需要多步推理才能得出的结论，对LLM来说依然是挑战。例如，“根据A产品的安装手册和B公司的安全策略，说明安装A产品是否会违反B公司的规定”，这对模型的逻辑推理能力要求极高。
问题3：答案的完整性与拒绝能力
- “知道自己不知道”的挑战
当检索到的上下文不足以完整回答问题时，一个理想的RAG系统应该明确拒绝，并告知用户“根据现有资料，我无法回答关于XXX的部分”。然而，很多LLM倾向于“尽力而为”，基于不充分的信息给出猜测性或片面的答案。
- 答案的偏见
LLM可能会在整合信息时，不自觉地偏重于某些片段，导致最终答案虽然基于上下文，但却是有偏见的。
问题4：复杂问题的分解与规划
- 问题描述：
用户的单个问题，往往包含了多个需要独立查询才能解答的子问题（查询分解），或者需要一个依赖前一步结果的逻辑链条才能解决（多步推理）。一个简单的“检索-生成”管道无法处理这类问题。
- 比较类问题
“对比A产品和B产品的优缺点。” -> 这需要分解为两个独立的子查询：“A产品的优点和缺点是什么？”和“B产品的优点和缺点是什么？”。
- 关联/多跳（Multi-hop）问题
“负责‘凤凰项目’的经理的上级的电话是多少？” -> 这需要一个更长的推理链条：
Step 1: 找到关于“凤凰项目”的文档。
Step 2: 从文档中识别出项目经理是谁（比如“张三”）。
Step 3: 再去检索“张三”的个人档案或组织架构图，找到他的上级是谁（比如“李四”）。 Step 4: 最后再去检索“李四”的联系方式信息，找到他的电话号码。
解决方案的引入与挑战：
为了解决这个问题，需要引入一个 “规划器”（Planner）或“编排器”（Orchestrator），这实质上是将RAG系统 “代理化”（Agentic RAG）。
- 规划器的角色
这个更高层次的LLM（或逻辑模块）首先分析用户的原始问题，决定是直接回答，还是需要将其分解成一个包含多个步骤的“计划”。
- 工具使用（Tool Use）
规划器将每个子问题或推理步骤，分派给不同的“工具”去执行。最核心的工具就是我们之前讨论的RAG检索器，但可能还包括代码解释器（用于计算）、Web搜索、数据库查询等。
- 状态管理
系统需要维护一个“草稿纸”（Scratchpad），每一步执行完，需要记录下执行结果，因为后续步骤的执行可能依赖于前面步骤的输出。
问题5：结果的融合与合成
- 问题描述：
在所有子查询或推理步骤都执行完毕后，系统拥有了一堆来自不同检索结果的、零散的信息片段。如何将这些片段智能地、连贯地、不失真地融合成一个最终的、统一的答案，是一个巨大的挑战。
挑战所在：
信息冲突
不同的检索结果可能包含相互矛盾的信息，系统需要有策略来判断哪个更权威或如何向用户呈现这种冲突。
- 逻辑连贯性
简单地将所有答案片段拼接在一起会显得生硬和混乱。LLM需要理解每个片段在整个逻辑链条中的作用，并用流畅的语言将其组织起来。
- 答案的完整性
如果某个子查询失败了，系统在合成最终答案时，必须能识别到信息的缺失，并明确地告知用户“关于XXX的部分，我未能找到相关信息”。
- 系统复杂性剧增
引入规划和分解机制，意味着系统从一个线性的“管道”变成了一个复杂的、带有循环和条件判断的“图”或“状态机”。这给开发、调试和维护带来了巨大的挑战。
- 错误传播（Error Propagation）
在这种链式调用中，任何一个环节的微小错误（一个子查询的检索不准、一步推理的幻觉）都可能被放大，并传递到后续环节，最终导致整个计划的失败或产出一个看似合理但完全错误的最终答案。
- 成本与延迟的叠加
每一次分解、每一步推理、每一次最终的合成，都可能需要一次LLM调用。这使得整个过程的延迟和API调用成本成倍增加。
第三部分：产品设计与交互
在生产级RAG项目中，产品经理的能力要求远超传统软件系统的需求分析和功能设计。他们必须成为连接用户心智、业务逻辑、大模型能力和系统工程四大领域的“超级连接器”。这对产品经理的技术素养和综合能力提出了极高的要求：
深谙大模型（LLM）
- 清楚大模型的能力
大模型的生成原理，以及生成、推理、规划、摘要、意图理解等能力。
- 清楚大模型的能力边界
必须清晰地认识到LLM固有的“幻觉”、事实不一致、逻辑推理脆弱等问题。
- 了解相关技术栈
多模态模型（模型能力及边界）、嵌入模型（基于encoder架构和decoder架构，以及多模态）、智能体框架LangChain或平台Dify等。
- 掌握成本与延迟
需要对不同模型的Token消耗、API调用成本和推理延迟有量化认知。在设计一个需要多步推理的复杂交互时，必须权衡其带来的用户价值与背后高昂的资源消耗。
精通RAG及Agentic架构的运作逻辑
- 洞察RAG全流程
能清晰地画出从“数据摄入”到“最终答案生成”的全流程图，并理解每个环节（如分块、嵌入、检索、重排、生成）的技术细节及其对最终结果的影响。
- 理解Agentic的整体流程
对于涉及规划、分解和工具使用的Agentic RAG，产品经理需要理解其状态管理、错误传播（瀑布效应）等内部执行逻辑。
- 识别失败归因
当用户报告一个错误时，产品经理需要能与工程师协作，快速判断问题根源是出在“检索（R）”、“生成（G）”还是“规划（Planning）”环节，看是否需要修改设计或系统执行流程，从而推动有效的系统优化。
产品设计、软件系统与数据工程
针对可能出现的各种情况，进行相应的交互设计（引用、引导、澄清、追问、确认）。
理解非结构化数据的ETL（抽取、转换、加载）的复杂性，尤其是在处理PDF、表格等数据时，避免过度设计（例如想要支持所有格式的文件）。
了解知识图谱、向量数据库等核心组件的基本原理和应用场景。
对系统的可评估性、可维护性、知识的生命周期管理有深刻认识，并在产品设计中为这些“非功能性”需求预留空间。
第四部分：系统与运营的挑战
这些是贯穿整个RAG系统生命周期的、更宏观的挑战。
问题1：模型的选型、部署与维护
- 内网/私有化部署的困境
在需要内网部署的场景下，无法使用强大的商业API（如DeepSeek V3.1）。团队必须：
- 选择合适的开源模型
在Qwen、GLM等众多模型中，根据模型性能、显存、中英文能力、推理性能进行选型。如果需要OCR，还需做OCR模型选型，并权衡准确率和生成速度。
- 应对硬件挑战
部署LLM需要选择并熟练使用常用推理引擎，了解量化等优化技术，配置合理的参数，并需要专业的工程能力来保证服务的稳定性和吞吐量。
- 模型微调（Fine-tuning）
为了提升模型在特定领域的表现（如客服场景、运维场景），可能还需要进行微调，这需要高质量的数据集和微调技术。
问题2：评估体系的缺失
这是RAG落地过程中最核心的痛点之一。
- 评估的复杂性
如何科学地、自动化地评估一个RAG系统的好坏？这需要一个多维度的评估框架，至少包括：
- 检索评估
准确率（Precision）、召回率（Recall）、平均排序倒数（MRR）等。
- 生成评估
答案的忠实度（Faithfulness）、相关性（Relevance）、无害性（Harmlessness）。
- 自动化评估的挑战
目前虽然有RAGAS、ARES、TruLens等开源评估框架，但构建一个稳定、可靠、能反映真实用户体验的自动化评估流水线，本身就是一个复杂的工程任务，此外，每个客户的数据分布都不一样，数据质量也良莠不齐，在一个场景测试的准确率，在另一个场景准确率很可能相差很大。
问题3：知识的生命周期管理
- 知识的持续更新
业务知识是动态变化的。当源文档被修改或删除时，如何保证向量数据库中的内容同步更新？如何处理文档的版本控制？如何动态更新图数据？
- 成本与效率
对整个知识库进行全量重建索引，成本高昂且耗时。实现高效的增量索引、实时更新，对系统的工程架构提出了很高要求。
结论
RAG技术虽然强大，但它绝非一个即插即用的“银弹”。一个真正能在生产环境中创造价值的RAG产品，必然是一个系统工程的产物，需要仔细设计和打磨。它至少需要：
- 1）在前端
有健壮的、能处理各类复杂文档的数据ETL流水线。
- 2）在检索端
有结合了混合搜索、查询重写、重排等技术的高级检索策略，并能处理实体级别的模糊性。
- 3）在生成端
有精巧的提示工程、事实校验机制来确保答案的忠实与可靠。
- 4）在运营端
有科学的评估框架来指导迭代，有完善的模型管理和知识更新机制来保证系统的持续演进。
忽视上述任何一个环节，都可能导致RAG系统在真实世界的复杂性和用户的严苛要求面前，暴露出其脆弱和不可靠的一面。