惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

阮一峰的网络日志
阮一峰的网络日志
雷峰网
雷峰网
Last Week in AI
Last Week in AI
T
Tailwind CSS Blog
V
Visual Studio Blog
Jina AI
Jina AI
博客园 - 司徒正美
The Cloudflare Blog
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
S
SegmentFault 最新的问题
博客园 - 三生石上(FineUI控件)
有赞技术团队
有赞技术团队
小众软件
小众软件
V
V2EX
Apple Machine Learning Research
Apple Machine Learning Research
美团技术团队
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
IT之家
IT之家
WordPress大学
WordPress大学
爱范儿
爱范儿
月光博客
月光博客
大猫的无限游戏
大猫的无限游戏

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
为什么“传统的”RAG不够用了?
界面与交互 · 2025-10-13 · via 人人都是产品经理

RAG不是“知识补丁”,而是“表达机制”的协同载体。本文系统梳理传统RAG在任务协同、上下文调度与表达清晰度上的能力瓶颈,帮助产品人理解如何在“检索+生成”之间构建真正可用的表达机制,实现从“能查”到“能说”的跃迁。

GraphRAG系列内容拆解(一)

痛点与起源:为什么“传统的”RAG不够用了?

一、RAG的价值与瓶颈:企业知识应用的局限

自大语言模型(LLM)兴起以来,检索增强生成(RAG)技术凭借其在解决知识时效性、数据私有性和模型“幻觉”方面的出色表现,迅速成为企业级LLM应用的主流方案。传统的RAG通过将企业的私有数据分割、向量化并进行相似度检索,使得LLM能基于事实依据进行回答。

然而,当企业的知识库规模达到PB级(注:PB级,即拍字节级,形容超大规模的数据集),数据复杂度涉及跨文档、多实体和复杂逻辑时,基于向量相似度的传统RAG架构开始暴露出其固有的局限性。

二、传统RAG在“大型/复杂知识库”下的三大核心痛点

传统的RAG依赖将文本切块,然后通过向量数据库进行相似度匹配。这种方法在处理简单、直接的问答时表现良好,但在以下三个核心痛点场景中,它已无法满足企业级复杂知识应用的需求:

痛点一:难以“连点成线”–多跳推理的瓶颈

问题描述:用户的复杂查询往往需要答案通过遍历不同信息片段的共享属性才能提供综合见解。例如:询问“所有参与了A客户项目的团队成员,他们是否在B公司的战略报告中被提及?”

传统RAG的不足:向量检索是基于局部语义相似度的匹配。它擅长找到A或B的文档,但无法执行多跳遍历来连接两个实体间的复杂路径。这导致在需要多跳推理时,召回率和准确性会急剧下降。

痛点二:语义理解的碎片化–缺乏知识的全局结构

问题描述:当需要全面理解一个超大型文档或高度分散的知识集的语义概念和知识结构时。

传统RAG的不足:检索结果是孤立、碎片化的文本块。LLM缺乏文档的全局结构图,难以辨别信息的层次、重要性和关系。这使得LLM难以建立完整的概念模型,生成的答案缺乏系统性和全面性,无法提供有价值的全局洞察。

痛点三:非结构化数据的“黑箱”输入

问题描述:企业知识库中充斥着大量的非结构化数据(如PDF扫描件、Word文档、PPT演示文稿等)。这些数据形态杂乱,如果缺乏高质量的结构化预处理,直接进行简单的Chunking和向量化,会给LLM带来极大的噪音。

传统RAG的不足:传统RAG对非结构化数据的处理深度不够,“垃圾输入,垃圾输出”(GIGO)问题突出。这极大地限制了LLM知识应用的天花板,是目前阻碍RAG效果提升的主要瓶颈之一。

三、GraphRAG的应运而生:从“向量”到“图谱”的跨越

GraphRAG的诞生,正是为了解决传统RAG在上述三个核心场景中的根本性缺陷。它通过引入知识图谱这一结构化的处理和存储层,实现了RAG的代际升级。

核心思路:构建知识图谱(Knowledge Graph)

GraphRAG的核心创新,是将LLM的能力从单纯的文本理解,延伸到知识图谱的构建与应用,优化了RAG的检索和上下文质量。

1.结构化抽取:利用LLM从非结构化文本中自动识别实体、抽取关系,将其转化为可推理的结构化知识。

2.增强检索:在查询时,系统可以在图谱上执行路径搜索,找到完整且相关的关系链,从而解决多跳推理问题。

价值与优势:从“局部相似”到“结构模式”。

通过引入知识图谱,GraphRAG带来了显著的改进:

解决“连点成线”:通过图谱路径搜索,能找到完整、可验证的关系链,为LLM提供逻辑更清晰、证据更充分的上下文。

提供全局视野:将知识转化为结构化模型,确保为上下文窗口填充的内容是相关性更高、逻辑更完整的知识块,帮助LLM更好地理解数据的内在联系和整体结构。

治理数据“黑箱”:通过强制结构化(即实体关系抽取)的索引过程,将杂乱的非结构化数据清洗并转化为明确的图谱三元组。这从根本上提升了输入LLM的知识密度和结构性,有效降低了传统RAG在处理非结构化数据时的GIGO(垃圾输入,垃圾输出)风险。

总结:GraphRAG并非简单地替换了传统RAG,而是通过知识图谱这一中间结构,将RAG的能力从简单的语义相似度匹配提升到结构化关系推理,从而大幅提升了复杂查询的准确性和可解释性。

(未完待续…)

下一篇文章,我们将深入拆解GraphRAG的“PM架构”,详细讲解其核心的索引(Indexing)阶段,即如何利用LLM实现实体抽取、关系构建,以及如何将非结构化数据转化为可用于关系推理的结构化知识。

敬请期待:《GraphRAGde “PM架构”:从文本到知识图谱的流程解析》

本文由 @界面与交互 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。