一、以集群形式存在的大数据, 难道已然变成了一种负担吗, 中小型的人工智能团队, 迎来了一种关于实时检索增强生成的崭新选择吗?
好多从事AI应用开发的人员, 都碰到过一个实际困难, 那就是, 若想构建一套能够使用的即时RAG系统, 直接首先想到的就是去搭建一套Spark或者Flink大数据集群。
为达成文档实时更新, 以及向量数据库增量同步, 团队需维护多套组件, 致使运维成本急剧上升。中小AI团队人力有限, 多数师仅熟悉, 复杂流处理框架学习障碍大 , 部署处理耗费诸多开发周期, 本只想进行实时向量化检索, 却被底层大数据组件所束缚。
近期, 有一篇专题文章, 其热度迅速地快速走高, 整篇的全部内容是围绕着开源项目而展开的, 上线之后, 它的阅读量快速地上涨, 评论区里挤满了各类关于部署、踩坑的提问, 这足以能够说明这个方向击中了大量一线开发者的真实诉求。
它是一款用于流批一体处理的库, 其底层借助 Rust 达成高性能计算, 对外展现出简洁的 API, 该项目是完全开源且免费的。到目前为止, 它拥有数千个 Star, 它是专门针对 AI 数据流场景进行设计的, 主要强调不需要部署重型大数据集群, 靠着它就能够搭建生产级实时数据管道。
有相当一部分人瞅见这套方案之际会萌生出好奇之感: 倘若不依靠传统的大数据中间件, 果真能够达成毫秒级别的实时 RAG 吗? 与此同时开发者内心里会萌生一份焦虑情绪: 当前已有的项目已然绑定了 Spark、Flink, 那更换全新框架所需付出的成本究竟有多高呢? 可同时也能够产生强烈的共鸣: 没有谁是愿意把大量的时间消耗在集群运维这事儿上面的, 业务目标才是开发工作的核心要点。要是这套方案能够得以实现推行, 那么开发者便能够切实体会到其中的让人心爽之处有: 仅仅凭借少量的代码, 就能够达成文档增量更新、向量库切实实时同步, 快马加鞭上线那具备可用性质的实时检索相关能力。
这套技术, 究竟是那种充满噱头的玩具项目, 还是能够投入生产使用的工具呢, 接下来就要将其完整地拆解开来。
二、核心拆解： 实现实时 RAG 完整实战
传统RAG大多是批处理模式, 文档有新增、修改情况后, 得手动重新执行脚本, 全量刷新向量库, 新文档要等许久才可被检索调用, 做不到数据变更立刻生效。其核心能力是持续监听文档变化, 自动增量处理, 将更新数据实时写入向量库, 实现毫秒级检索响应。
2.1. 整体工作流程中, 对数据源进行监听, 持续监控文档文件夹, 专门捕捉新增、修改以及删除的文档。2. 接着进行流数据解析, 自动解析各类文档格式, 从中提取文本内容。3. 然后展开向量化处理, 调用模型把所说文本转为向量。4. 随后进行增量写入向量库操作, 也就是说只推送发生变更的数据, 并不做全量重计算。5. 最后对外提供检索服务, 当用户发起查询时, 实时返回最新文档的检索结果。
整个链路, 并不需要借助 Spark、Flink 来进行流调度, 所有逻辑都是基于相应编码完成的, 底层的 Rust 负责其中高性能的执行。
2.2 核心示例代码
import pathway as pw
from pathway.xpacks.llm.vector_store import VectorStoreServer
from pathway.xpacks.llm import parsers
# 1.监听本地文档目录，自动捕获文件新增、修改、删除
documents = pw.io.fs.read(
"./docs",
format="binary",
mode="streaming",
)
# 2.文档解析，提取文本内容
markdown_parser = parsers.UnstructuredParser()
parsed_docs = documents.select(text=markdown_parser.parse(pw.this.data))
# 3.初始化向量服务，内置增量更新逻辑
vector_server = VectorStoreServer(
parsed_docs,
embedder=pw.xpacks.llm.embedders.OpenAIEmbedder(),
)
# 4.启动实时服务，文件改动自动更新向量库
vector_server.run()在运行代码之后, 只要 docs 目录当中的文档出现了改动, 框架便会自动去完成解析, 接着进行向量化, 随后更新向量库。在此过程中, 开发者既无需手动去编写轮询脚本, 也无需搭建消息队列来做数据中转。
2.3 调用实时检索接口
服务启动完毕后, 径直调用接口便能获取到实时检索所得结果呈现, 新添加的文档在毫秒等级层面方可实现被查询精准所获取命中, 并不是让使用者去等待面向定时的任务来执行完成, 从而达成了具备真正深层含义之下表现的实时 RAG 这一结果出现句号。
优势总结：
上层开发，Rust 底层保障性能，兼顾开发效率与运行效率
增量更新，只处理变动文档，避免全量重算带来的资源浪费
无重型大数据集群依赖，降低硬件与运维负担
三、辩证分析：优点突出，但不能盲目替换现有技术栈
带来的突破值得予以肯定, 它实实在在地解决了居于中小AI团队最感头疼的痛点之处, 将实时流RAG的门槛大幅度予以降低。以往若要达成同等能力, 起码得有文件监听服务、消息队列、流计算引擎、向量库多个组件相互配合才行, 如今仅仅依靠这单独的一个开源库便能够形成闭环。
但呢, 我们对此也得要持凭理性去看待的态度, 它不是那种能够在所有业务场景里全面适用的万能解决办法, 在这儿是有着几个关系到现实情况的问题, 很值得开发者去进行权衡思量的。
其一, 它在适配AI文档数据流场景方面更具优势, 然而这并不意味着能够将Spark、Flink的所有能力都进行完整替代。传统大数据框架历经多年生产实践的打磨之后, 是面向海量业务日志以及复杂多源异构大数据的, 其算子生态、容错运维工具的发展更为完善。要是业务自身已经拥有庞大的离线数仓以及复杂的统计计算, 那么直接进行全盘替换的风险是相当高的。
第二点, 虽说所撰写的是代码, 其性能依赖于 Rust 底层, 然而调试排查问题的门槛仍旧是存在的。对此, 评论区涌大量提问便是例证: 在流模式里的数据状态进行调试、执行异常重试以及故障恢复, 这些和普通脚本开发的思维是全然不同的。开发人员务必要理解流批一体的运行模型, 不然上线到生产环境就极易遭遇问题。
其三, 该项目的发展周期相对较短, 其社区规模相较于传统大数据框架而言更小。在生产环境中使用时, 需要自身储备排除故障的能力, 倘若碰到疑难问题, 公开的资料并非那般丰富。
在此处呈现, 提供给众人作思考: 你的团队, 是遭受大数据集群运维的拖累, 还是原本就存有复杂且规模大的离线计算要求? 别一见到新技术便急切地去重构旧项目, 需与自身团队的技术储备相适配。
四、现实意义：给中小型 AI 团队指出另一条技术路线
往时, 行业之中存有这么一种思维定式, 即只要是进行实时数据处理, 那就必定要去部署一套重型的大数据组件。诸多 AI 创业团队, 其业务仅仅是一套文档问答系统, 然而因实时能力的需求, 不得不引入一堆中间件, 如此一来, 团队的大部分精力都耗费在了集群维护方面, 而非专注于打磨 AI 业务自身了。
使这套方案具备最大现实意义的情况, 是将固有的技术路径撕开, 进而给中小团队增添了一种选择。
对于那种人员数量不多, 且是以开发作为主要工作内容, 其核心诉求着重聚焦于文档实时RAG的团队而言, 是完全能够优先去评估这一套方案的。不用去招聘专门的大数据开发人员, AI工程师便能够完成一整套实时数据管道的开发工作, 从而缩短项目上线的周期, 将资源回归到业务迭代当中。
与此同时, 还得要以一种客观的态度去看待, 它并非意味着要去否定Spark以及Flink所具备的价值, 在针对于大型企业面临的那种海量、多源数据场景而言, 成熟的大数据栈依旧是不可以被其他事物所替代的, 技术并不会存在绝对的好或者坏, 仅仅存在适不适合业务当前状况之分而已。
致使诸多团队陷入困境的根本缘由, 在于不加思索地套用大厂的技术架构, 却对自身业务规模以及人员配置予以漠视。大厂所构建的架构, 乃是针对几十乃至上百TB的数据量、大规模的研发团队精心设计的, 中小企业若原封不动地照搬, 只会无端增加复杂度, 徒增麻烦。
技术选型的核心，永远是用最低成本，解决自己真实业务问题。
五、互动话题
看完这套实时 RAG 方案，分享几个问题欢迎大家一起交流：
你们在项目中做RAG时, 是采用全量更新向量库的方式, 又或者是已经达成了增量实时更新? 在这个过程中踩过哪些方面的坑? 要是团队人手处于有限的状况, 你是情愿去尝试这种新的流处理库, 还是宁愿继续沿用Spark、Flink这样成熟的方案? 在你所拥有的认知范畴里面, 实时RAG最大的难点究竟是数据流处理这一方面, 还是跟检索调优相关的问题?
于评论区域留下你亲身经历的实战方面的经验, 一同去交流有关AI工程在实际落地过程当中确实存在的问题。