关于本地文档RAG系统的帮助(存储 + 摄取 + 查询 + 高亮)
摘要
一个关于构建本地文档RAG系统的详细技术咨询,涵盖存储、摄取、查询和高亮,寻求关于向量数据库、GraphRAG可行性以及文档高亮实现的建议。
大家好,我正在设计一个本地离线文档检索与LLM流水线,希望听听大家的架构建议。以下是我的目标:
**存储**
上传PDF、DOCX、XLSX、CSV、表格
所有数据本地存储(无云端)
**文档摄取**
监听文件夹(例如Watchdog)→ 文件添加/修改/删除时自动摄取
嵌套文件夹结构 → 自动标注
支持格式:PDF、扫描版PDF、DOCX、XLSX、CSV、JPG/PNG
重新上传时的版本控制
**查询与检索**
查询限定在单个客户的文档范围内(无跨客户端泄漏)
结构化查询(例如“显示金额超过10万卢比的发票”)
比较性查询(例如“比较FY23与FY24毛利润”)
关键词回退
**高亮与渲染**
为前端提供带注释的PDF
XLSX → 彩色单元格导出
直接跳转到高亮页面
一次响应中显示多个文档的高亮
**答案生成**
仅使用本地LLM
每个引用都需标注文档和页码
**我的问题**
解析:我在考虑使用LlamaIndex LiteParse。→ 是否需要为PDF存储文档ID和块ID以实现高亮?
向量数据库:我是否需要向量数据库(例如Qdrant)?如果需要,如何在嵌入向量旁边存储文档ID和块ID以实现高亮?pgvector在Postgres中是否足够?
GraphRAG:像Neo4j或Microsoft GraphRAG的系统效果如何?它们能否在本地/离线运行,还是计算量太大?这个GraphRAG流水线是否是一个好的起点?
高亮用户体验:我想要类似Turnitin/iThenticate报告的效果——精确句子的高亮+引用。有没有开源项目已经实现了这个功能?我找到了Kotaemon和AnythingLLM,它们很接近但未实现文档高亮。
**简单总结**
尝试构建一个本地RAG系统,包含:
存储 + 摄取 + 标注
查询 + 检索 + 高亮
使用本地LLM生成带引用的答案
寻求以下建议:
向量数据库 vs pgvector
GraphRAG的离线可行性
最佳方式实现文档高亮与引用预览
非常希望听到任何构建过类似系统或探索过这些工具的人的意见。
相似文章
@DanKornas:传统的以文本为中心的RAG系统无法有效处理现代文档中的图像、表格、公式、图表以及多媒体…
RAG-Anything 是一个基于 LightRAG 构建的多模态文档处理 RAG 系统,它解析文档、构建多模态知识图谱,并使用混合向量-图检索来回答问题。
@0x0SojalSec:无向量、基于推理的RAG的文档索引——无需向量数据库构建RAG。该开源库使用文档树...
PageIndex 是一个用于无向量、基于推理的RAG的开源库,它使用层次化文档树而非嵌入向量,在FinanceBench上达到了98.7%的准确率。它无需向量数据库或分块即可实现上下文感知检索。
当更多文档损害RAG:通过领域限定、模型无关的检索缓解向量搜索稀释
本文识别了RAG系统在扩展到大规模异构文档集合时出现的“向量搜索稀释”现象,并提出MASDR-RAG,一种利用组织元数据进行领域限定的检索方法,显著提升了检索准确率。
@akshay_pachaar: RAG vs. Graph RAG vs. Agentic RAG,清晰说明!标准RAG将文档嵌入向量并检索最相关…
清晰解释标准RAG、Graph RAG和Agentic RAG,涵盖它们的区别、用例以及如何处理单跳与多跳查询。
ScalableRAG:零摄入成本的高质量RAG
本文介绍了ScalableRAG,一种检索增强生成方法,通过基于正则表达式的集合创建和聚合推理,在无需任何摄入成本(无需向量数据库或知识图谱)的情况下实现高准确率。它在多个数据集上优于基线方法,并提出了一个有限摄入变体以进一步提升准确率。