当前位置:   article > 正文

【开源】基于OCR和文档解析的下一代 RAG 引擎,结合大语言模型(LLM)针对用户各类不同的复杂格_大模型ocr文件理解

大模型ocr文件理解

它是一款基于深度文档理解构建的开源 RAG(Retrieval-Augmented Generation)引擎。它主要为各种规模的企业及个人提供一套精简的 RAG 工作流程,结合大语言模型(LLM)来处理用户各类不同的复杂格式数据,并提供可靠的问答以及有理有据的引用。

它的主要功能包括:

1. 深度文档理解:能够从各类复杂格式的非结构化数据中提取真知灼见。

2. 基于模板的文本切片:提供多种文本模板,实现智能且可控的文本处理。

3. 降低幻觉(hallucination):通过文本切片过程可视化,支持手动调整,确保答案提供关键引用的快照并支持追根溯源。

4. 兼容各类异构数据源:支持丰富的文件类型,包括 Word 文档、PPT、Excel 表格、txt 文件、图片、PDF、影印件、复印件、结构化数据, 网页等。

5. 全程无忧、自动化的 RAG 工作流:优化了 RAG 工作流,支持从个人应用到超大型企业的各类生态系统,提供易用的 API,便于集成到各类企业系统中。

它的推出,是为了解决目前 RAG(Retrieval-Augmented Generation)在实施中遇到的问题,如数据库的多路召回能力和数据处理问题。通过提供专用的数据库和工具,旨在使 RAG 更易于被更多企业和个人使用,并解锁更多应用场景。

在很长一段时间内,RAG 在行业的代名词都叫知识库,上述的应用架构,不仅带火了向量数据库,也带火了以LangChain,LlamaIndex 为代表的中间件,它们负责处理上图中各个箭头背后的工作流。具体包括:

1、把用户的文档进行切分,然后再调用一个 Embedding 模型把切分好的文档生成为向量。

2、把生成好的向量连同原始文档写入到向量数据库中。

3、查询时,将用户的提问也根据相同的 Embedding 模型生成向量,然后查询向量数据库返回 Top K 结果。

4、把 Top K 结果对应的文本拼成提示词交由大模型做最终的摘要和内容完成。

因此,整个架构图里核心部分是两个:

1、向量数据库:负责基于向量对用户的文档进行查询召回。

2、中间件:负责对文档的切分,并转成适合的向量。

采用向量这种形式是因为向量可以提供语义召回,用户只要提问,最终能按照相似度高低返回最接近的答案而无需考虑问题是否真的有哪些关键词匹配到了文档。即使没有匹配,也依然可以根据语义相似度返回答案。之所以需要对用户文档进行切分,是因为向量表征的语义比较含糊,不仅一篇文章可以表征为一个向量,一个单词也可以表征为一个向量,这就导致文字块跟向量对应的粒度很难控制:粒度过粗,用一条向量对应一大段话,对这些文字的细节很难表征;粒度过细,那么一大段文字会对应一堆向量,而每个向量又仅仅代表几个词的语义,因此无法简单根据相似度来找到符合语义的向量。因此,需要对文档进行“恰当”的切分,这就是 LangChain,LlamaIndex 等中间件的核心工作。

那么,如何定义“恰当”呢?通常会采取一些简单的策略:例如先根据文字间的空白将文档切分成不同的段落,这些段落表征的粒度相对比较适合。随后通常会把一些标题(通常需要根据一些规则来判断)跟这些段落合并,让这些只包含局部文字的段落也能体现整篇文章或者部分章节的语义。

因此,有了这类组件就可以快速搭建一套 RAG 系统。不过,自从这种应用架构从 23 年 4 月开始流行,就一直面临一个争论:“把用户的数据微调进大模型直接回答问题更好,而无需 RAG 这一整套基于检索的架构”。这类争论伴随了整个 2023 年。直到今天,这类争论的声音才渐渐淡去。因为,很显然,无论是实时性还是成本等方面, 采用 RAG 是碾压对 LLM 进行微调的方案的。支持微调的拥护者所最看重的问答质量,但更多评测发现,两者差距并不大,而逐渐得出了两者需要搭配使用的结论。并且,这种所谓搭配使用的方案,随着开源 LLM 不断快速迭代推陈出新,也导致实际真正采用微调的已寥寥无几。

基于深度文档理解,能够从各类复杂格式的非结构化数据中提取真知灼见。

真正在无限上下文(token)的场景下快速完成大海捞针测试。

不仅仅是智能,更重要的是可控可解释。

多种文本模板可供选择

文本切片过程可视化,支持手动调整。

有理有据:答案提供关键引用的快照并支持追根溯源。

支持丰富的文件类型,包括 Word 文档、PPT、excel 表格、txt 文件、图片、PDF、影印件、复印件、结构化数据, 网页等。

全面优化的 RAG 工作流可以支持从个人应用乃至超大型企业的各类生态系统。

大语言模型 LLM 以及向量模型均支持配置。

基于多路召回、融合重排序。

提供易用的 API,可以轻松集成到各类企业系统。

支持的文件类型

它支持多种类型的结构化数据处理。具体来说,它能够处理包括但不限于以下格式的文件:

- Word 文档

- PPT

- Excel 表格

- txt 文件

- 图片

- PDF

- 影印件

- 复印件

- 结构化数据

- 网页等

通过其深度文档理解功能,能够从这些复杂格式的非结构化数据中提取真知灼见,进而提供可靠的问答服务。这使得它成为处理各类企业及个人复杂格式数据的有效工具。

如何确保内容的原创性

它本身并不直接检测或确保内容的原创性,但它在内容创作过程中可以通过以下方式帮助提高内容的原创性:

1. 信息检索与引用:它可以帮助您检索相关信息,并提供准确的引用。这有助于您在创作时明确区分原始资料和引用内容,避免无意中的抄袭。

2. 内容重述与整合:通过检索到的信息,您可以使用它来帮助您重述或整合这些信息,以您自己的话语和角度表达,从而提高内容的原创性。

3. 资料来源多样化:支持从多种数据源检索信息,这可以帮助您获取更广泛的资料,减少对单一来源的依赖,从而创作出更多元化的内容。

4. 提高工作效率:可以自动化和简化信息检索和整理过程,让您有更多时间和精力专注于创作,减少因时间紧迫而导致的复制粘贴等不原创行为。

5. 内容审核与校对:虽然它不直接进行原创性检测,但它提供的信息和引用可以帮助您在后期审核和校对时,检查是否有遗漏的引用或需要进一步改写的地方。

确保内容的原创性最终还是需要创作者自身的努力,比如对资料进行深入分析、批判性思考,以及用自己的话语和观点进行表达。它可以作为一个辅助工具,帮助您在创作过程中更高效地处理信息,但它不能替代创作者自身的原创性和创造力。如果您需要检测内容的原创性,可能需要使用专门的抄袭检测工具或服务。

系统架构

它的系统架构设计旨在提供一个高效、灵活且可扩展的平台,用于处理和增强基于检索的生成(Retrieval-Augmented Generation, RAG)任务。 系统包含以下几个关键组件:

1. 数据输入接口:这是系统接收各种格式数据的地方,包括结构化和非结构化数据,如文本文件、PDF、图像、网页等。

2. 数据处理模块:这个模块负责从输入数据中提取信息,并进行必要的预处理,如文本提取、图像识别、格式转换等。

3. 信息检索引擎:这个组件是它的核心,它使用深度学习模型和大语言模型(LLM)来理解和检索相关信息。这可能包括使用向量数据库和相似性搜索技术来快速找到与查询最相关的数据片段。

4. 生成引擎:基于检索到的信息,生成引擎使用自然语言处理(NLP)技术来生成新的文本内容。这可能包括回答问题、撰写摘要、生成报告等。

5. 用户界面和API:用户界面允许用户与系统交互,提交查询,查看结果等。API则允许开发者将它集成到其他应用程序中。

6. 可视化工具:为了提高透明度和可解释性,可能包括可视化工具,使用户能够查看和调整文本切片过程。

7. 数据库和存储:系统需要一个地方来存储和管理大量的数据,包括原始数据、处理后的数据和生成的输出。

8. 安全性和合规性模块:确保系统的数据安全和符合相关法律法规的要求。

9. 监控和日志记录:这些组件用于跟踪系统的性能,记录操作历史,以便进行故障排除和性能优化。

可试用产品

开源地址

作者简介:

张锋,微服务架构实战原创作者,拥有超过10年的软件开发和架构设计经验。他是一位热衷于探索新技术和模式的软件工程师,对微服务架构、容器技术、自动化部署等领域有深入研究。在职业生涯中,他曾任职于多家知名企业,担任过技术团队负责人,带领团队实现了一系列高并发、高可用的微服务架构项目。

张锋老师在微服务架构领域有着丰富的实践经验,他的作品《微服务架构实战》深入浅出地介绍了微服务架构的设计理念、技术栈选择、项目实践等关键环节,广受读者好评。此外,他还活跃在技术社区,分享自己的见解和心得,助力更多开发者掌握微服务架构的精髓。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/799191
推荐阅读
相关标签
  

闽ICP备14008679号