rag已经死了吗?

大二玩了半年RAG,我发现最靠谱的解法,居然是百年图书馆逻辑

本人大二,接触Agent开发从RAG入门,摸过GraphRAG、RAGFlow这些热门项目,也啃过LlamaIndex、LangChain框架,踩了不少坑,也有了些不一样的想法,纯分享思路,不做落地。

先说说我看到的核心问题:
RAGFlow的溯源功能能标清信息出处,解决了模型胡编的问题,却缺了LangChain那样的隐私数据守卫——检索时只过滤正文,溯源链接还留着,等于给隐私泄露、外网信息跳转留了后门。
同时现在的RAG大多是文档乱塞一锅炖,海量数据根本管不住,开源框架要么太笨重新手难维护,要么功能太简陋撑不起场景。

想通这些的时候我正在学校图书馆,突然发现:我们卷破头的RAG问题,现代图书馆这套人类用了上百年的「信息管理系统」,早就完美解决了。

核心思路完全对标图书馆逻辑,分三点:

1. 先分级管控,从根源堵隐私漏洞
像图书馆分普通阅览区、内部资料室、涉密档案室一样,给文档做分级。敏感内容直接拦在库外,内部文档没权限连检索都搜不到,自然不会有溯源链接泄露的问题,只有合规公开内容才开放完整溯源。
2. 先分类入库,解决海量数据混乱
图书馆新书不会直接堆书架,会先验收、查重、按标准分类标引再上架。对应到RAG里,就是文档先自动清洗、去重、分类打标,再分到独立向量库物理隔离,再多文档也井井有条,不会越用越臃肿。
3. 统一规范做开源生态,解决「各玩各的」的痛点
图书馆能跨馆互通,核心是有统一的编目规则。我们也可以定一套极简统一的开源RAG库规范,实现两个核心:一是人人都能按规范分享自己的RAG库,开箱即用不用二次处理;二是符合规范的任意两个RAG库,都能无缝拼接,自动对齐分类、去重、更新索引,不用手动改配置。

现在RAG圈总在卷框架、卷算法,却忘了做RAG的初衷,是让普通人用最低成本让AI落地。这套图书馆逻辑的思路,不用高算力不堆复杂技术,刚好能让本地小模型配上标准化RAG库,真正变得可用。

纯思路分享,不打算自己落地做项目,玩RAG的朋友有想法,欢迎一起交流。

#RAG# 大模型 #AI开发# 开源思路 #大学生编程
全部评论
有的兄弟有的,rag有这些技术,第一点叫做二级权限校验,在用户输入,调向量库之前,先去用户数据库找找有没有这用户,如果没有就挡住,第二部就是调知识库之前再去用户数据库核对一下,他的读库权限和检索库名是否对应,不对应也挡住。第二点叫做分库管理+元数据过滤。核心就是用户问2024或者指定v0.1版本的文档,那检索的时候就筛选对应的文档标签。第三点我还没听说过倒是,毕竟rag这玩意做出来的主要目的就是赋能企业的知识库,而企业知识库一般都是私有的,比较讲究私有化部署,有啥需要共享内容的直接调用web search得了
22 回复 分享
发布于 04-28 13:38 广东
12早就实现了吧,早就分级分类了,3问题是没有一个统一的标准,因为针对不太类型的数据格式目前都是不一样的
4 回复 分享
发布于 04-29 19:02 河南
佬大二就玩这么深啊
3 回复 分享
发布于 04-29 16:10 广东
如果说rag已死那大家理解的rag都是狭义的向量检索,可是rag是叫检索增强生成,个人认为大模型固有知识之外的任何结果的检索,调用,返回都属于rag,读文件,工具调用的返回结果这都是检索增强生成,rag是一个抽象层,并不是应用层
2 回复 分享
发布于 05-23 12:02 陕西
1分级管控挺好的,但不是专门解决隐私问题的,解决隐私,溯源链接等也加个权限管理就行了
2 回复 分享
发布于 05-08 21:42 四川
3不太可行啊😦你怎么解决不同embedding模型的纬度问题,和他们的向量空间分布问题啊
2 回复 分享
发布于 05-06 14:40 浙江
不是死了,是一种选择,无论是缓存还是rag还是agent都是一种设计方案
1 回复 分享
发布于 05-14 14:58 北京
老,能详细谈谈你的RAG思路吗? 最近面试腾讯,问了一个和你这个一样的问题。
1 回复 分享
发布于 05-09 13:23 安徽
问题不是RAG本身是工程化没跟上
1 回复 分享
发布于 04-29 18:16 浙江
技术性的还是吃香的
点赞 回复 分享
发布于 06-01 20:57 江苏
大佬 考虑我司不 考虑的话可以看我主页帖子
点赞 回复 分享
发布于 04-30 08:50 陕西

相关推荐

05-13 20:42
浙江大学 C++
最近看了不少 Agent 相关项目,我慢慢感觉:不是所有 Agent 项目都适合写进简历。有些项目看着挺热闹,功能也不少,但一到面试里其实不太好讲。你能把它跑起来,不代表你能把它讲清楚,也不代表它能撑住深入追问。值得写进简历的 Agent 项目,要能同时体现业务场景、系统设计和工程实现。我现在更推荐的,大概是这 4 类。第一类是 AI Coding / 代码仓库问答 Agent。 这一类很适合拿来写简历,也适合面试展开。好处是天然能把很多高频考点串起来:代码切片、RAG、Tool Calling、上下文组织、状态管理,往深了甚至还能聊 AST、调用链、测试生成这些内容。这类项目不只是“接了个模型做问答”,很容易讲成一个真正服务开发流程的系统。面试官一般也比较喜欢问,因为它兼具 Agent 和工程,不太容易沦为一个单纯套壳的 demo。第二类是 Deep Research / 联网搜索总结 Agent。 一个比较好的 Deep Research 项目,通常会涉及 query 拆分、搜索、多源信息抽取、去重、重排、结构化整理、最后生成带引用的结果。这里面既有 Agent 的规划和执行,也有工具协同和结果校验。对简历来说这类项目通常很占便宜,别人一看就明白做的不是简单聊天机器人,是真的在解决复杂任务的问题系统。第三类是 AIOps / 排障 Agent。 这个方向推荐给偏后端、平台或者基础架构一点的人。它天然和日志、指标、告警、知识库、runbook、故障定位这些东西绑在一起,一旦做出来,整个项目会非常有“真实业务系统”的味道。如果能把“告警来了以后怎么决定查哪些日志、什么时候需要人工接管、误报怎么处理”这些链路讲清楚,这种项目在简历里是很有含金量的。第四类是 长期记忆 / 个人知识库 Assistant。 很多人简历里都会写长期记忆、多轮上下文、个性化助手,但真问到“长期和短期怎么分”“什么时候写记忆”“怎么避免旧信息污染当前任务”,回答就会开始发散。这类项目适合拿来补“Memory 设计”这块的短板,它能把记忆系统真正做成一个能被深挖的点。
点赞 评论 收藏
分享
评论
58
181
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务