原贴链接

我正在构建另一个‘向PDF提问’的检索增强生成（RAG）系统。我已经成功将PDF转换为markdown格式。然后我使用Jina分割器将其分割成块。每个块大约1000个字符长，但有时短到只是章节标题。之后我将所有这些块存储在向量数据库中，并使用余弦距离对块进行排序，选取前100个，并将相关块包含到用于回答用户问题的大型语言模型（LLM）提示中。然而，我感觉我好像遗漏了一个步骤。查询返回的块虽然大多相关，但并不包含完整的答案，还包含一些不相关答案的片段。我是不是遗漏了某个步骤呢？

讨论总结

原帖主在构建“问PDF问题”的RAG过程中遇到了查询结果不完整和包含无关内容的问题，在Reddit上寻求帮助。评论者们纷纷根据自己的知识和经验给出建议，如ekaj指出需要找出与内容匹配的分块/检索策略；kryptkpr强调语义分块和上下文注入的重要性并给出参考资料；还有评论者从模型设置、特定解决办法等不同角度提供思路，同时也有评论者提出新的相关问题。总体氛围比较积极，大家都在努力为解决原帖主的问题出谋划策。

主要观点

  1. 👍 需要找到适合内容的分块/检索策略
    • 支持理由：原帖主构建RAG时遇到结果问题，合适的分块/检索策略有助于解决。
    • 反对声音：无
  2. 🔥 语义分块和上下文注入对构建RAG很重要
    • 正方观点：能提高RAG构建的有效性。
    • 反方观点：无
  3. 💡 构建RAG的解决方案架构取决于问题领域，无通用最佳答案
    • 解释：不同的问题领域有不同的需求和特点，不能一概而论。
  4. 💡 建议包含食谱标题与块可能有助于解决问题
    • 解释：针对原帖主构建RAG中遇到的问题提出可能的解决方向。
    • 反对声音：原帖主构建通用工具不能做这种假设。
  5. 💡 要设置足够的模型上下文长度
    • 解释：模型上下文长度可能影响RAG构建结果。

金句与有趣评论

  1. “😂 Welcome to RAG. You need to figure out a chunking/retrieval strategy that matches your content.”
    • 亮点：直接点明原帖主在RAG构建中需要做的关键事情。
  2. “🤔 Semantic chunking is crucial, and for many applications so is context injection.”
    • 亮点：强调了构建RAG时语义分块和上下文注入的重要性。
  3. “👀 Does including the recipe title along with the chunk help you at all?”
    • 亮点：提出一个可能有助于解决原帖主问题的简单建议。
  4. “😉 To handle arbitrary user query like this, you make an assistant and give it some tools.”
    • 亮点：针对多参考查询提出了一种构建助手并配备工具的解决思路。
  5. “🤓 Make sure your model is set to sufficient context length.”
    • 亮点：指出模型设置方面可能影响RAG构建的因素。

情感分析

总体情感倾向是积极的，大家都在积极地为原帖主出谋划策。主要分歧点在于原帖主强调构建通用工具不能做特定假设，而有的评论者提出的建议是基于特定假设（如包含食谱标题与块）。可能的原因是评论者从各自的经验和思考角度出发，没有完全考虑到原帖主构建通用工具的要求。

趋势与预测

  • 新兴话题：如何用半结构化数据进行RAG。
  • 潜在影响：可能会促使更多人探索RAG在不同数据类型上的构建方式，拓宽RAG技术的应用范围。

详细内容：

标题：关于构建 RAG 的困惑与探讨

在 Reddit 上，一篇关于构建“向 PDF 提问”RAG 的帖子引发了热烈讨论。该帖获得了众多关注，评论数众多。原帖作者表示已成功将 PDF 转换为 Markdown，使用 Jina 分割器将其分块，每块约 1000 字符，但有时短得只有章节标题。作者将这些分块存储在向量数据库中，用余弦距离排序，选取前 100 个并纳入 LLM 提示以回答用户问题，但感觉遗漏了步骤。返回的分块有时不包含完整配方，还包括不相关配方的片段。

讨论焦点与观点分析： 有人指出需要找到适合内容的分块/检索策略。比如像处理食谱这样的情况，理想应返回整个原始文档或整个食谱，而非只是分块。有人认为按标题进行分块，理论上每个章节可能无限长，需要进一步细分。也有人提到语义分块至关重要，还有上下文注入，比如可参考 https://github.com/D-Star-AI/dsRAG 。 对于一些架构决策，有人建议阅读 LlamaIndex 文档，包括拆分（分块）文本、索引和检索等相关页面。 有人询问包含食谱标题和分块是否有帮助。 有人思考是否分割器并非正确工具，应尝试将 Markdown 转换为分层 JSON。 对于用户提出需要在文档中查找多处不同参考的问题，有人建议通过创建助手并赋予其一些工具来处理。 有人对于不包含完整配方的部分不太理解，提出可让 LM 生成虚假答案，然后与查询进行余弦相似度计算，相关见解可参考https://arxiv.org/abs/2212.10496 。 有人提醒要确保模型设置有足够的上下文长度。 还有人建议将食谱以带 ID 的形式存储在数据库中，通过解析响应中的 ID 从数据库获取完整食谱。

总之，关于如何构建有效的 RAG，大家各抒己见，从分块策略到模型设置，从工具选择到数据存储，讨论丰富多样，为原帖作者和有相同困惑的人提供了诸多有价值的思路。