@murmur #13 举个例子，像独立开发者做一些 saas 的推荐还是能用用的 ，我自己做的图库和音乐网站的推荐系统就打算用这个，使用用户 like 过的内容 embedding 之后算出一个大概的范围，再使用向量 db 搜索最接近这个范围的结果
我觉得可以不要太局限于文档类的(PDF,docx,纯文本等等) 可以往专业性强一点的文件类型扩展，应用场景才可能更广，更有生产力 比如你文章里也提了 Claude 能通过读软件开发领域的源代码，代码中的引用声明来了解路径信息和项目结构 其实在工作中，其他类型的文件也会有很多 比如制造业里大量的机械图纸，3d 文件，再比如影视行业大量的视频素材，音频素材 对于偏视觉系的资料，我觉得按现在多模态模型的能力 做视觉识别，总结，然后结构化列出文件大纲信息也是不错的 idea
这篇文章的作者指出的痛点（如上下文碎片化、本地资源开销、专业词汇不敏感）是非常真实的，确实反映了**早期/基础 RAG （ Naive RAG ）**在实际落地中的普遍困境。 但是，如果要反驳这篇文章，核心切入点在于：**作者是在用“2023 年的基础 RAG”的缺点，来衬托“2024 年高级 RAG”的优点，然后通过“偷换概念”宣称自己放弃了 RAG ，本质上是一篇为自己产品（ Linkly AI ）带货的精彩软文。** 以下是具体的反驳逻辑和视角： ### 1. 概念偷换：他并没有放弃 RAG ，只是做了一个“层级 RAG” 作者提出的终极解法是 **Outline Index （搜索 -> 看大纲 -> 精读）**。 * **反驳**：这根本不是放弃 RAG ，这在业界被称为 **Hierarchical Retrieval （层级检索）**、**Document Summary Index** 或者类似 RAPTOR 的树状检索结构，LlamaIndex 等框架早就支持了。 * 本质上，它依然是“检索（ Retrieval ）+ 增强（ Augmented ）+ 生成（ Generation ）”的管线。作者只是把“直接检索碎片（ Chunk ）”改成了“先检索大纲（ Outline ），再按需加载大区块（ Section ）”，这是 RAG 架构的演进，而非颠覆。 ### 2. 逻辑自相矛盾：解析难度问题 * **作者的论点（问题四、五）**：文档被固定大小切块后语义破碎。并且不同文档类型（表格、合同、代码）结构不同，提取和分块的开发维护成本极高，效果还不好。 * **反驳（致命漏洞）**：如果一份排版复杂的 PDF （包含多级标题、跨页表格、双栏文本），你连准确的文本分块都做不到，**你的 Outline Index 是如何凭空为它生成完美的“结构化大纲（章节、层级、行号）”的？** * **真相是**：无论做高级 RAG 还是做 Outline Index ，核心瓶颈都是**文档版面分析与结构化提取**（ Document Parsing ）。只要你能完美解析出文档结构，传统的语义切块（ Semantic Chunking ）加上父子文档关联（ Parent-Child Retriever ）同样能完美解决碎片化问题。作者把文档解析的锅，硬扣在了 RAG 的头上。 ### 3. 以偏概全：拿“纯向量检索”的弱点当作整个 RAG 的弱点 * **作者的论点（问题二、三）**：Embedding 对专业词汇不敏感，Rerank 模型太重且不能解决根本的召回问题。 * **反驳**：现代生产环境的 RAG 标配是 **混合检索（ Hybrid Search = 向量 Dense + 关键词 Sparse/BM25 ）**。作者在文末也承认自己的方案也是用“BM25 + 向量”双路召回来解决领域词汇问题的。既然大家都在用双路召回，为什么这成了传统 RAG 的缺点，却成了他们产品的卖点？此外，API 化的 Rerank 模型（如 Cohere 、BGE ）速度极快，几百毫秒的延迟在动辄数秒的 LLM 生成时间面前几乎可以忽略不计。 ### 4. 场景局限：把“本地优先”的短板无限放大 * **作者的论点（问题一）**：本地桌面应用跑大 Embedding 模型太吃资源，跑小模型效果差，陷入两难。 * **反驳**：这是“本地桌面端”的软硬件限制，而不是 RAG 技术的限制。绝大多数企业级 RAG 或 SaaS 应用都在云端运行，调用顶级的 Embedding API 成本极低且效果极好。即便在本地端，随着端侧 NPU/Apple Silicon 的普及以及诸如 BGE-M3 等轻量级高性能模型的出现，这个门槛正在迅速降低。 ### 5. 成本与效果的掩耳盗铃（关于大模型长文本陷阱） * **作者的方案**：给 AI 一张地图，AI 看完大纲后决定按需加载精读（甚至加载整个章节）。 * **反驳**：这种做法极度依赖大模型的**超长上下文能力（ Long Context ）**和**推理能力**。 * **Token 成本极高**：如果用户问一个简单的数据点（例如“Q3 的利润是多少？”），传统 RAG 返回 3 个精准的 Chunk 可能只消耗 1000 Token 。而 Outline Index 需要先让 AI 读几百 Token 的大纲，然后加载可能长达 5000 Token 的整个财报章节去“精读”，Token 消耗和首字等待时间（ TTFT ）反而飙升。 * **迷失在中间（ Lost in the middle ）**：即便是现在的长文本模型，在塞入一个巨大的章节让其自己寻找细节时，依然很容易出现幻觉或遗漏。精准的 Chunk 召回反而是降低 LLM 幻觉的最有效手段。 ### 总结 如何一针见血地评价并反驳这篇帖子？ > “文章写得很好，对早期无脑切块（ Naive RAG ）的批判刀刀见血。但作者用 2023 年最基础的 Fixed Chunk + 纯向量检索作为‘靶子’，刻意无视了 2024 年业界早已普及的**混合检索、语义切块、父子文档结构（ Auto-merging retrieval ）以及多步 Agentic RAG**。 > 作者兜售的『 Outline Index 』本质就是带 Metadata 的层级检索（ Hierarchical RAG ），依然是 RAG 家族的一员。这就像是说：**‘为什么我放弃了汽车？因为三轮车太颠簸了，而且拉货太少。所以我现在改用四个轮子、带独立悬挂的交通工具了。’** 这是一次精彩的降维打击式营销，但从技术层面来看，RAG 并没有被放弃，只是在向着更精细的结构化和 Agent 化演进。”
我个人最初使用方法是把问题和答案进行结构化处理，然后将问题作为索引内容作为文档保存到向量数据库中，它效果很好，但是一旦问题数据量多起来的话，命中的索引也会成倍的增加，最终效果就不好了。只适用于小型数据量的处理。
@YanSeven #22 知识图谱化召回率非常高，这肯定是有价值的。对于知识密集型行业效果很好，例如医疗、法律、历史、地理等等，至于像企业内部知识库等场景或许划不来，烧掉的 token 实在太多了。 有没有价值还是得看资料的质量如何，garbage in, garbage out
