原贴链接

根据我所做的研究和实验，如果你想要从一个或一组文档中提取精华部分，RAG（检索增强生成）是很好的选择。但当你试图引用或获取特定的信息片段，即查询单个部分时就不太适用了。我正在寻找的是解析一个文档，提取文档内定义的部分列表，然后检索该部分中定义的所有信息。RAG和嵌入似乎不适合这种情况，因为嵌入在这里并没有真正的价值——我不是在寻找“相关”信息，而是要对文档进行分割。我已经研究了更细致的RAG示例，如添加BM25或知识图谱，但我不明白它们如何适用于这个用例。

讨论总结

原帖作者对使用RAG提取确切信息存疑，认为RAG在提取特定信息方面存在不足。评论者们积极回应，提出各种观点，包括RAG未规定搜索算法，可采用其他搜索方法；推荐了如https://github.com/ucbepic/docetl、elasticsearch等工具；指出RAG的不足及可与其他工具结合使用；还涉及到成本考量、预处理、分块方法等相关话题，整个讨论氛围积极，旨在为原帖作者提供解决方案。

主要观点

  1. 👍 RAG未强制规定搜索算法
    • 支持理由：像“检索”“增强”“生成”这些词并不意味着只能用余弦相似度向量搜索。
    • 反对声音：无
  2. 🔥 推荐elasticsearch作为满足需求的工具
    • 正方观点：它是一个全文搜索引擎、文档存储和嵌入搜索工具，可按需求搜索并检索全文本。
    • 反方观点：无
  3. 💡 分割文档和检索特定部分时可跳过嵌入并关注结构化方法
    • 解释：如关键词搜索或正则表达式解析等方法更适合分割文档和检索特定部分。
  4. 💡 RAG不足以满足原帖目标，应使用其他工具构建函数或管道检索章节
    • 解释：因为RAG的目的是增强生成而非复述。
  5. 💡 RAG进行有效提取需要良好预处理
    • 解释：若要提取精确内容，不应使用向量存储，需良好预处理。

金句与有趣评论

  1. “😂 RAG doesn’t mandate which search algorithm you use.”
    • 亮点：指出RAG在搜索算法选择上的灵活性。
  2. “🤔 听起来你正在找https://github.com/ucbepic/docetl。”
    • 亮点：直接推荐可能满足原帖作者需求的工具。
  3. “👀 对于分割文档和检索特定部分，你可能想要跳过嵌入并专注于更结构化的方法，如关键词搜索或正则表达式解析。”
    • 亮点：针对原帖需求提出具体的操作建议。
  4. “😎 对于提取确切的章节，将RAG与另一个工具（如基于自然语言处理的文档解析或特定的基于规则的提取方法）相结合可能会有所帮助；您是否考虑过 EyeLevel.ai 用于文档解析中的安全人工智能选项？”
    • 亮点：提出RAG与其他工具结合的思路并推荐相关工具。
  5. “😏 DinoAmino：It does seem like RAG won’t be sufficient as the goal there is to augment generation and not to recite.”
    • 亮点：明确指出RAG在原帖需求下的不足之处。

情感分析

总体情感倾向为积极。主要分歧点较少，大多数评论者都在积极为原帖作者提供建议或分享观点。可能的原因是原帖是一个技术问题寻求解决方案的帖子，大家都抱着解决问题的态度参与讨论。

趋势与预测

  • 新兴话题：尝试开源库解决文档处理成本高的问题可能会引发后续讨论。
  • 潜在影响：如果在文档处理中更多地尝试结合不同工具或方法，可能会对相关技术领域的效率提升和功能优化产生积极影响。

详细内容：

标题：能否用 RAG 提取确切信息？若不行，还有何选择？

在 Reddit 上，有这样一个热门讨论帖子：一位用户基于自身的研究和实验表示，RAG 在提取文档或一组文档的精髓方面表现出色，但在引用或获取特定信息，比如查询单个部分时，效果就不那么理想了。该用户正在寻找一种能够解析文档、提取文档内定义的部分列表，并随后检索该部分所有信息的方法。RAG 和嵌入似乎不太适用，因为嵌入在此没有太大价值，用户不是在寻找“相关”信息，而是要对文档进行分段。此帖获得了众多关注，引发了大量讨论，评论数众多。

讨论焦点与观点分析： 有人指出，RAG 并不强制规定使用哪种搜索算法，例如可以使用 SQL 查询、BM25 或关键词搜索等其他方法。有人分享道会去研究这些建议。还有人推荐了 https://github.com/ucbepic/docetl ，并表示其想法不错。也有人提到 elasticsearch 是一个全功能的搜索引擎，可根据需求选择不同的搜索方式。有人建议对于分割文档和检索特定部分，跳过嵌入并专注于更结构化的方法，如关键词搜索或正则表达式解析，同时提到了 MasteringLLM 的 AgenticRAG 课程。有人表示 RAG 可能不足以满足需求，最好使用其他工具或管道来检索部分，还提到了 Unstructured-IO/unstructured ，但用户表示因成本问题不可行。有人认为良好的 RAG 需要良好的预处理，如果需要提取“确切”的东西，应使用不同的方法而非向量存储。还有人分享自己的方法是使用 LLM 验证向量搜索的前 K 个输出，然后对验证的块进行进一步处理。有人提出将 RAG 与其他工具如基于 NLP 的文档解析或特定的基于规则的提取方法相结合可能会有所帮助，并询问是否考虑过 EyeLevel.ai 用于文档解析的安全 AI 选项。

讨论中的共识在于都在积极探讨如何更好地解决提取文档确切部分信息的问题，不同的观点和建议丰富了讨论，为寻求解决方案提供了更多思路。