扒扒RAG:当大模型学会“查资料”,AI 的脑子发生了什么变化?

从零开始!在 Windows 上安装与配置 Dify 这篇博客将详细介绍如何在 Windows 系统上部署 Dify,适合零基础用户。从 Docker 和 WSL 的安装配置开始,逐步指导用户设置 Git、Docker 环境以及 Dify 配置文件,解决可能遇到的端口冲突等问题,最终完成 Dify 的启动和测试。通过简明易懂的步骤,帮助用户在本地成功运行 Dify,实现模型供应商配置,让 Dify 项目在 Windows 平台上顺利上线。 阅读详情

前瞻导读:2020 年,RAG 把大模型从“只靠记忆答题”带进了“先查资料、再给答案”的阶段,也成为今天企业知识库、智能问答和 Agent 系统里最常见的底层能力之一。


2020 年,一篇名为《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》的论文,把一个后来影响整个 AI 应用行业的概念推到了台前:RAG,检索增强生成。简单理解,它让大模型从一场“闭卷考试”,变成了一场允许查资料的“开卷考试”。

图片

图片来源:arXiv

为什么大模型明明很聪明,

却总在一本正经地胡说八道?

先说一个大模型最尴尬的问题。

你问它一个问题,它可能不知道。

但它通常不会老老实实地回答:

“对不起,这个我不会。”

它更有可能根据自己学过的语言规律,拼出一个听起来非常合理的答案。

  • 人名有了。
  • 时间有了。
  • 数字有了。
  • 甚至"参考文献"都给你列出来了。

唯一的问题是:

全是编的…

这就是我们经常说的“幻觉”,hallucination

还有另一个问题。

大模型的知识,大量来自训练时见过的数据。

训练结束之后,它脑子里的知识不会像新闻网站一样自动实时刷新。昨天发生了什么、公司内部最新政策是什么、你电脑里那份 PRD 写了什么,它本来都不知道。

所以,大模型一直有两个很现实的短板:

不知道的东西,可能瞎编。

新发生的事情,可能不知道。

RAG 的出现,就是在尝试给这两个问题补上一块拼图。

它没有让模型凭空变得更聪明,而是教会了模型一件很重要的事:

不知道的时候,先去查。

RAG 通过引入外部知识源,让模型在生成答案前先寻找相关信息,从而有机会获得更新、更具体、也更贴近特定领域的上下文。它能够提高知识密集型任务中的答案准确性和可信度,但并不能保证彻底消除幻觉。

简单整理了下面要展开的RAG的工作原理概览:

图片

图片来源:image2

RAG 到底是什么?

把大模型想成一个参加开卷考试的学生

RAG,全称:

Retrieval-Augmented Generation,检索增强生成。

这个名字听起来很技术。

但它的核心思想其实很简单:

回答之前,先查资料。

图片

图片来源:aws

假设你问一个普通大模型:

“我们公司今年的差旅报销标准是多少?”

如果这个政策从未出现在模型训练数据里,那它当然不知道。

它可能拒绝回答。

也可能根据常见企业制度,给你编一个看起来很像真的答案。

但接入 RAG 之后,流程就不一样了:

第一步,

模型会先去公司的制度知识库里搜索,比如,

  • 有没有差旅制度?
  • 有没有报销标准?
  • 最新版本是哪一份?
  • 北京、上海和其他城市的标准是不是不同?

第二步,

找到相关文件之后,再把问题和资料一起交给模型。

这时,大模型不再需要靠“回忆”回答。

它可以根据刚刚查到的证据组织答案。

所以可以把两种方式理解成:

  • 普通 LLM:凭脑子里记住的东西回答。
  • RAG:先翻资料,再结合自己的理解能力回答。

2020 年,Patrick Lewis等人在 RAG 的经典论文里,提出了一个很有意思的思路:

不要再逼着模型把所有知识都背在脑子里,而是给它配一个可以随时翻阅的外部资料库。

你可以把大模型想象成一个正在参加考试的学生。

它在训练过程中学到的知识,就像已经记在脑子里的东西,这叫参数化记忆。

而 Wikipedia 这样的外部知识库,则像一本可以随时翻阅的参考书,这叫非参数化记忆。

问题来了以后,模型不用只靠脑子硬想。

检索器会先去外部资料库里寻找相关内容,再把找到的资料交给生成模型,由它结合问题组织最终答案。

比如你问:

“《老人与海》的作者是谁?”

普通模型可能直接凭记忆回答。

但在 RAG 里,系统可以先从外部知识库找到与《老人与海》相关的文档,再根据检索到的内容回答:

欧内斯特·海明威。

这就是 RAG 最核心的变化:

它不是让模型记住更多,而是让模型在需要的时候,知道去哪里找。

一套最常见的 RAG,到底是怎么工作的?

今天工程里常见的 RAG 系统,其实可以简单理解成四步:

先把资料整理好,再建立索引;用户提问后去找相关资料,最后把找到的内容交给大模型生成答案。

第一步:先把资料整理成“能被搜”的样子

假设你手里有一份 200 页的 PDF。

里面可能是企业制度,也可能是产品文档、研究报告或者操作手册。

你当然不能每次有人提问,就把整整 200 页全部塞给大模型。

所以第一件事,通常是把长文档切成一个个更小的片段。

这就是常说的:

Chunk,分块。

但问题很快就来了。

切得太小,上下文容易断掉。前半句在一个块里,后半句跑到了另一个块,模型拿到的可能只是一截残缺的信息。

切得太大,又会把大量无关内容一起带进来。真正有用的信息只有两句话,旁边却塞着几千字背景资料。

所以分块并不是简单地“每 500 字切一刀”。

更重要的是,要让每个片段既保留足够的上下文,又尽量围绕一个相对完整的主题。

这也是为什么很多 RAG 项目做到最后会发现:

真正麻烦的,往往不是接上一个大模型,而是先把资料整理成适合被检索的样子。

第二步:让机器知道每段资料大概在说什么

文档切好之后,系统还需要理解:

这一段讲年假。

那一段讲报销。

另一段讲供应商管理。

工程里常见的做法,是把每个文档块转换成一串数字,也就是所谓的:

向量,Vector。

你可以把它理解成给每段文字放到一个“语义地图”上。

意思接近的内容,会被放得更近。

比如:

“员工每年享有 10 天年假。”

和:

“公司的年度带薪休假是多少天?”

两句话虽然用词不同,但表达的是同一类意思。

一个好的向量模型,就应该能看出这种语义上的接近。

这样以后用户提问时,系统找的就不只是“有没有出现同一个关键词”,而是:

哪段资料真正和这个问题意思最接近。

第三步:用户提问,系统开始查资料

假设用户问:

“我工作满一年有多少天年假?”

这时候,系统不会立刻让大模型直接回答。

它会先拿这个问题去已经建立好的索引里找相关资料。

可能找回来的是:

员工手册里的休假章节。

2026 年最新修订版的休假制度。

或者 HR FAQ 里关于工作年限和年假天数的说明。

这一步,就是:

Retrieval,检索。

说白了,就是先从一大堆资料里,把最可能有用的那几段找出来。

第四步:把找到的资料交给大模型

最后,系统会把用户的问题和刚刚检索到的资料一起交给大模型。

这时候,大模型不再只靠自己“脑子里记得什么”来回答。

它有了一个额外参考。

比如系统可能告诉它:

用户的问题是:

“我工作满一年有多少天年假?”

同时提供一段公司制度:

“员工连续工作满一年后,每年享有 10 天带薪年假。”

大模型再根据这段资料组织答案。

于是整个过程就变成了:

用户提问 → 系统查资料 → 找到相关证据 → 大模型组织答案。

这就是今天最常见的一套 RAG 工作流。

看起来并不复杂。

但真正做过的人通常很快就会发现:

RAG 最难的,从来不是“能不能搜”,而是“搜回来的,到底是不是模型真正需要的东西”。

RAG 不是一个技术点,而是经历了三代进化

随着技术发展,RAG 早就不只是最初的“检索一下,然后生成”。

Gao 等人的综述将 RAG 的技术演进总结为三种主要范式:

Naive RAG、Advanced RAG 和 Modular RAG。

范式怎么做最大特点
Naive RAG索引 → 检索 → 生成简单直接,但检索质量容易不稳定
Advanced RAG检索前优化 + 检索后优化想办法让模型找到更准、更干净的资料
Modular RAG路由、搜索、记忆等模块灵活组合根据不同任务动态选择处理方式

为什么看似最简单的 RAG,经常一上手就不好用?

很多人第一次做 RAG,思路都差不多。

RAG vs Long Context

把 PDF 扔进去,切成小块,做 Embedding,存进向量数据库。等用户提问时,再搜几个最相关的片段,交给大模型生成答案。

听起来很顺。

但真正跑起来以后,经常会出现一个很尴尬的问题:

流程全对,答案还是不准。

很多时候,不是模型不够聪明,而是它一开始拿到的资料就错了。

比如用户问:

“这个产品为什么下线?”

结果系统检索回来的是产品上线时间、使用手册、另一个同名项目的复盘,甚至一些根本不相关的资料。

这时候,再强的大模型也很难救回来。

就像你让一个学生参加开卷考试,题目问的是产品下线原因,桌上放的却是一堆产品说明书。

他翻得再认真,也不一定能找到答案。

所以,RAG 真正难的地方,从来不是“有没有接上向量库”,而是:

在检索之前,能不能先把问题理解对;在检索之后,能不能把真正有价值的内容留下来。

检索之前:

先把问题和资料都收拾干净

很多人第一次做 RAG,会把注意力全放在模型和向量数据库上。

但真正落到生产场景里,你很快会发现,最先拖后腿的往往不是模型,而是资料本身。

一份制度文档里,可能混着重复页眉、扫描乱码和错位表格;同一份政策可能存了三四个版本,其中还有已经失效的旧文件。

这些东西如果不先处理,后面的检索再聪明,也只是在一堆脏数据里努力找答案。

所以系统级RAG的第一步,很多时候不是换更强的模型,而是先把知识库整理干净:

哪些文档还有效,哪些已经过期;哪些内容重复,哪些需要合并;一份长文档应该怎么切,才能既保留上下文,又不把无关信息一起塞给模型。

这一步看起来不够“AI”,却往往最决定最终效果。

RAG非常现实:

资料本身是乱的,模型再强,也很难替你把混乱自动变成真相。

  1. 查询重写

用户的问题,也不一定适合直接拿去搜索。

比如有人问:

“那个报销规则改了吗?”

这句话人能看懂,是因为我们会自动结合上下文。但对检索系统来说,“那个”到底指什么?是差旅报销、招待费报销,还是采购报销?问的是哪个部门,又想比较哪个时间段?

如果系统直接拿这句话去搜,结果很可能会很乱。

所以一个更成熟的 RAG 系统,往往会先帮用户把问题“问清楚”。

比如把它改写成:

“查询 2026 年最新版员工差旅报销制度,并与上一版本对比是否发生变化。”

问题一旦具体了,后面的检索也会准很多。

但光靠语义理解还不够。

有些内容,人一眼就知道必须精确匹配。

比如合同编号、产品 SKU、员工 ERP、SQL 字段名、报错代码。

你不能指望系统去“理解一个差不多的意思”,因为差一个字符,可能就是完全不同的东西。

这也是为什么很多实际的 RAG 系统不会只用向量检索,而是把语义检索和关键词检索放在一起。

前者负责判断:

你大概想找什么。

后者负责确认:

你找的是不是这个具体东西。

两者配合,才更接近人在真实场景里查资料的方式。

所以 Advanced RAG 真正做的,不只是“搜得更多”,而是想办法让系统在检索前先把问题理解清楚,在检索中找到真正相关的内容,再在检索后把噪声过滤掉。

说到底,它解决的还是同一个问题:

别急着回答,先把资料找对。

检索之后:

搜回来十篇,不代表十篇都有用

找完资料之后,还有第二个问题:

排名靠前的,真的就是最重要的吗?

这真不一定

所以很多 RAG 系统会加入:

Rerank,重排,embark

第一轮先粗筛

比如从十万份文档里找出 50 条候选资料。

第二轮再精排

仔细判断哪几条和用户的问题最相关,把真正重要的内容放到前面。

这很像招聘。

第一轮先从 1 万份简历里筛出 100 个人。

第二轮再认真面试,找出真正合适的 5 个。

除此之外,还有另一个问题:

资料太多。

检索回来十几个文档,每个都有几千字,全部塞给模型,不但成本增加,还可能产生噪声。

于是又出现了上下文压缩:

  • 去掉废话。
  • 提取关键句。
  • 保留和当前问题最相关的信息。
  • 最后再交给大模型。

所以一个真正成熟的 RAG,

不是搜得越多越好。

而是:

刚好把最需要的证据送到模型面前。

再往前一步,RAG 开始学会自己决定“该怎么查”

到了 Modular RAG,RAG 的思路又往前走了一步。

传统 RAG 的流程通常比较固定:

用户提问,系统去检索,再把结果交给大模型生成答案。

这套流程应付简单问题没什么问题。

但现实里的问题,哪有这么整齐。

你问一句:

“1+1 等于多少?”

当然没必要查知识库。

但如果你问:

“我们公司昨天刚更新的差旅标准是什么?”

那就必须去查最新制度。

再复杂一点,如果你问:

“对比过去三年的销售数据,再结合最近的市场变化,判断明年的增长风险。”

这时候,光查一次知识库显然不够。

系统可能要先读内部数据库,再找最新新闻,翻行业报告,做数据计算,最后还要根据中途发现的新线索,决定要不要继续查。

问题就出在这里。

不同的问题,本来就不应该走同一条路。

这正是 Modular RAG 真正厉害的地方。

它不再要求所有问题都按照“检索一次,再生成一次”的固定流程处理,而是把整个 RAG 系统拆成一个个可以自由组合的模块。

简单问题,可以直接回答。

涉及企业内部知识,就查知识库。

需要最新信息,就调用搜索。

问题太复杂,可以先拆成几个子问题。

第一次结果不够,还可以继续检索,甚至换一种搜索策略重新来一遍。

也就是说,RAG 不再像一根固定的管道。

它开始更像一个工作台:

问题来了,先判断需要哪些工具,再决定先做什么、后做什么。

这也是为什么 2023 年底发布的经典 RAG 综述,会把 Modular RAG 视为 RAG 演进中的重要阶段。

到了 2024 年,研究者又进一步提出 Modular RAG 框架,希望把复杂的 RAG 系统拆成更独立的模块和专用操作组件,让它们可以根据不同任务重新组合、灵活编排。

如果说 Naive RAG 只是教会 AI:

“遇到不会的问题,先去查资料。”

那么 Modular RAG 更进一步,它开始教 AI:

“先判断这个问题该不该查、去哪查、怎么查、查几次,以及什么时候已经查够了。”

这时候,RAG 已经不只是简单的“检索增强生成”。

它开始有了一点真正的任务规划能力。

RAG 也不是万能药

讲到这里,很容易产生一个误解:

既然大模型会幻觉,那加 RAG 不就行了吗?

没这么简单。

RAG 自己也有一堆坑。

第一,检索错了,后面全错

用户问 A。

系统找回来 B。

模型再聪明,也可能只能一本正经地根据 B 回答。

所以,RAG 的上限很大程度上受检索质量影响。

第二,找对了,模型也可能不用

即使正确资料已经放在上下文里,模型依然可能:

忽略它。

误解它。

过度推断。

或者继续使用自己的参数知识。

所以“找到正确证据”和“根据证据正确回答”,是两个不同的问题。

第三,知识库本身可能就是错的

如果企业知识库里有:

过期制度。

重复文件。

互相矛盾的版本。

错误数据。

那么 RAG 只会更高效地把这些问题送给模型。

第四,权限和安全问题会越来越重要

如果员工只能看 A 部门资料,却因为一个统一向量库检索到了 B 部门机密信息,那就不是模型效果问题了。

而是数据泄露。

随着 RAG 进入企业真实场景,权限控制、隐私保护、数据污染和检索安全都会成为不能绕开的工程问题。相关综述也把检索质量、生成忠实性、评估和系统安全列为 RAG 持续面临的核心挑战。

写在最后

所以,RAG 最值得看的地方,不是给大模型外挂了一个向量数据库。

而是它改变了 AI 处理知识的方式。

过去,我们拼命让模型记住更多。

更多参数。

更多训练数据。

更长上下文。

但 RAG 提供了另一条路:

不必什么都记住,但要知道什么时候去找,去哪找,以及找到之后怎么用。

这件事听起来很普通。

因为人类本来就是这么工作的。

医生不会背下所有医学论文。

律师不会记住所有判例。

程序员也不会记住每一个 API。

真正专业的人,不只是脑子里装得多。

而是遇到一个陌生问题时,知道怎么把答案找出来。

但问题也来了。

当知识越来越多、问题越来越复杂,仅仅靠“把问题转成一个向量,再找几个最相似的文档块”,真的还够吗?

显然不一定。

如果一个问题需要跨十几份文档寻找关系怎么办?

如果用户的问题本身就表达得不清楚怎么办?

如果第一次搜出来的资料不够,AI 能不能自己换个关键词再查一次?

如果答案需要同时查数据库、知识库、互联网,甚至一边推理一边决定下一步去哪找呢?

这也是 RAG 现在正在发生的变化。

严格来说,RAG 并没有被某一种新技术直接替代。

真正开始过时的,是最简单的那套:

切块、向量化、Top-K 检索,然后把结果一股脑塞给模型。

新的检索方法已经在往更深处走。

比如 GraphRAG,它不再只寻找“哪段文字和问题最像”,而是尝试把人物、事件、公司、概念之间的关系组织成图,再去回答那些需要跨文档理解的复杂问题。微软研究院已经将 GraphRAG 用于大规模文本数据中的关系发现和全局性问题回答。

还有 Agentic RAG。

它不再规定 AI 每次只能“搜一次、答一次”。

Agent 可以先拆问题,决定要不要检索、查哪个数据源、第一次结果够不够、要不要换个方向继续查,甚至一边推理,一边调整自己的搜索策略。

再比如 HyDE。

它的做法很有意思:

用户先提一个问题,AI 不急着直接搜索,而是先自己生成一份“假想中的答案文档”,再拿这份文档去寻找真正的相关资料。

有时候,人不知道该怎么问,但模型可以先猜出“答案大概长什么样”,再顺着这个方向去找。

还有 ColBERT 和 Late Interaction。

传统向量检索喜欢把整段文字压成一个向量。

但一段几百字的文本,真的能被一个向量完整代表吗?

ColBERT 的思路是保留更细粒度的 Token 级表示,再让查询和文档之间进行更精细的匹配,从而在检索准确性和效率之间寻找新的平衡。

所以,RAG 的故事其实还远没有结束。

它只是从最初的:

“先查资料,再回答。”

慢慢走向:

“先判断该不该查,再决定去哪查、怎么查、查几次,以及什么时候已经查够了。”

RAG 让大模型学会了“查资料”。

但接下来

GraphRAG,Agentic RAG,HyDE,ColBERT这些RAG的优化甚至迭代方案

这些,可能才是检索技术真正开始变得有意思的地方。

下一篇,打算再扒扒GraphRAG,

当 AI 不再只满足于“找到相似的文档”,而是开始试着看懂人物、事件和概念之间的关系时,

它就不只是在查资料了,而是在尝试看懂知识本身


参考文献:

1. RAG 原始论文

https://arxiv.org/abs/2005.11401

2、Naive RAG、Advanced RAG到Modular RAG的演进

https://arxiv.org/abs/2312.10997

3、Agentic RAG

https://arxiv.org/abs/2501.09136

4、Hypothetical Document Embeddings

https://arxiv.org/abs/2212.10496

5、Modular RAG

https://arxiv.org/abs/2407.21059

这里给大家精心整理了一份全面的AI大模型学习资源,包括:AI大模型全套学习路线图(从入门到实战)、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等,资料免费分享!

👇👇扫码免费领取全部内容👇👇
在这里插入图片描述

1. 成长路线图&学习规划

要学习一门新的技术,作为新手一定要先学习成长路线图,方向不对,努力白费。

这里,我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。
在这里插入图片描述

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的,我们精选了一系列深入探讨大模型技术的书籍和学习文档,它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础。(书籍含电子版PDF)

在这里插入图片描述

3. 大模型视频教程

对于很多自学或者没有基础的同学来说,书籍这些纯文字类的学习教材会觉得比较晦涩难以理解,因此,我们提供了丰富的大模型视频教程,以动态、形象的方式展示技术概念,帮助你更快、更轻松地掌握核心知识。

在这里插入图片描述

4. 2026行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估,以了解哪些行业更适合引入大模型的技术和应用,以及在哪些方面可以发挥大模型的优势。

5. 大模型项目实战

学以致用 ,当你的理论知识积累到一定程度,就需要通过项目实战,在实际操作中检验和巩固你所学到的知识,同时为你找工作和职业发展打下坚实的基础。

在这里插入图片描述

6. 大模型面试题

面试不仅是技术的较量,更需要充分的准备。

在你已经掌握了大模型技术之后,就需要开始准备面试,我们将提供精心整理的大模型面试题库,涵盖当前面试中可能遇到的各种技术问题,让你在面试中游刃有余。

在这里插入图片描述

7. 资料领取:全套内容免费抱走,学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型,还是有基础想冲刺大厂、了解行业趋势,这份资料都能满足你!
现在只需按照提示操作,就能免费领取:

👇👇扫码免费领取全部内容👇👇
在这里插入图片描述

802.1AS时间同步机制深度解析:从Sync报文到多域冗余设计 本文深度解析了802.1AS时间同步机制,从Sync与Follow_Up报文的核心交互原理入手,详细阐述了其如何通过精确的时钟频率比测量、链路延迟计算和驻留时间补偿来实现微秒乃至纳秒级同步。文章进一步探讨了802.1AS-2020版本引入的多时钟域冗余设计,为构建高可靠的车载TSN网络提供了关键见解和实战配置指南。 阅读详情

相关推荐

STM32单片机语音提示盲人拐杖整点报时夜间警示超声波测距

STM32单片机语音提示盲人拐杖整点报时夜间警示超声波测距 关键词:语音提示盲人拐杖 整点报时 超声波测距拐杖

LS840233684的博客 2048

LLM - AI四件套 : 大模型、RAG、AI AGENT 、Workflow

十年前,如果有人跟你说"电脑能像人一样写文章、解答难题,还能自己安排工作",你肯定觉得他在吹牛。毕竟,会用ChatGPT的人已经淘汰了不用的人,而会用Agent+工作流的人,正在淘汰只会ChatGPT的人。——知识停留在训练截止日(比如GPT-4只学到2023年),问它“2024年欧冠冠军是谁”,它能给你编个皇马vs拜仁的精彩战报,但其实压根没这比赛!以前的人工智能像偏科生——训练一个只会翻译,另一个只会算数,每个AI都只会一门手艺。现在所有AI应用都在这个"学霸大脑"上做加减法,这才是真正的范式革命。

小工匠 3643

RV1106 SDK 软件开发环境

5.30.1 如何开启休眠唤醒功能以project/cfg/BoardConfig_IPC/BoardConfig-SPI_NAND-NONE-RV1106_EVB1_V11-IPC.mk为例:5.30.2 休眠唤醒方案简介SDK的休眠唤醒采用的方案为:进入休眠状态描述:用户层收到触发事件后,暂停业务流程并主动调用echo mem > /sys/power/state命令使系统进入休眠状态。

xzjiang_365的博客 4253

【技术指南】一文搞懂AI三大核心概念:MCP、RAG、Agent详解

在AI技术日新月异的今天,MCP(模型控制协议)、RAG(检索增强生成)和Agent(智能体)已成为推动行业发展的三大关键技术。每天都有基于这些技术的新工具、新应用如雨后春笋般涌现,科技圈的讨论热度持续攀升。 但面对这些专业术语,不少人都存在这样的困惑:它们究竟是什么黑科技?MCP如何实现大模型的高效管理?RAG怎样显著提升AI的回答质量?Agent又为何被誉为下一代AI系统的核心架构?更重要的是,这些技术对普通人的工作生活会产生哪些实质性的影响?

yihanss的博客 1525

Marvell车载以太网交换机芯片88Q5050

Marvell推出了四款车载用交换机芯片,88Q5050,88Q5050, 88Q5072和88Q6113。其中88Q5030有5 Port用于通信,88Q5050有8 Port用于通信,5072与6113有11 Port用于通信。由于项目中用到了88Q5050,所以本文中只涉及到88Q5050的内容。本文是对使用88Q5050的梳理和总结。

zhuwade的博客 2万+

万象RK3506-EG1800网关使用说明

摘要:HD-RK3506-EG1800是一款高性能工业物联网边缘计算网关,支持Buildroot和Ubuntu双系统。文档详细介绍了网关的网络配置(包括ETH0/ETH1的静态IP设置、WiFi连接)、时钟同步、HSL软件安装配置(含开机自启动服务)、系统日志优化以及刷机操作指南(Loader/Maskrom模式)。特别提供了基于lighttpd的网页管理方案,通过HTML界面实现网络参数可视化配置,包含身份验证、实时状态显示和表单提交功能。网关默认ETH0固定IP为192.168.1.10,提供完整的CL

tian_jiangnan的博客 179

RAG技术详解:给AI装个“实时查资料外挂“,告别胡言乱语,答案又新又准!

RAG(检索增强生成)是一种结合信息检索和生成的技术,通过检索外部信息、构建临时知识库、整合生成答案三个步骤,解决AI"记不住新东西、容易瞎编"的问题。其底层原理包括知识库分块、语义编码、向量检索和带资料提问等流程,使AI从"靠记忆瞎编"变为"拿着参考资料答题的靠谱考生",显著提高输出准确性和可靠性。

Trb201013的博客 810

使用 MATLAB/Simulink 构建一个 压水堆核电机组的反应堆控制与功率调节系统 仿真模型

本文通过Simulink构建压水堆核电机组的反应堆控制与功率调节模型,详细介绍了建模流程:从中子点动力学核心方程、反应性反馈模型(控制棒、多普勒和慢化剂效应)、一回路热工模型到完整的闭环控制系统。教程包含系统结构设计、参数设置、模块连接方法,以及典型负荷变化场景的仿真分析,帮助读者理解核反应堆动态特性和控制原理。同时提供了进阶建模建议,如分布参数模型和先进控制策略的应用。该模型为教学简化版,强调核能系统的机理建模与Simulink实现方法,适合核工程与控制领域的学习者参考实践。

amy_mhd的博客 189

让大模型“记住”更多:RAG与长期记忆

RAG技术与长期记忆的融合实践 OpenAI近期强化了ChatGPT的记忆功能,通过RAG(检索增强生成)技术结合长期记忆系统,使AI既能调用外部知识库,又能记住用户个性化信息。RAG通过检索外部数据解决大模型"幻觉"问题,而长期记忆则采用向量数据库、结构化插槽和自动总结三种方式存储用户历史对话。当前主流方案是混合架构,如mem0的轻量级框架和MemGPT的类人脑记忆系统。二者的结合将重塑AI角色,在企业服务、智能客服和教育等场景实现更人性化交互。未来,具备上下文记忆能力的AI将更接近通

2401_82452722的博客 1581

ZYNQ工业级串口方案:AXI UART 16550扩展RS-485实战(自动方向控制+Linux驱动)

可以轻松扩展出多路工业级串口。但常规方案需要手动控制收发方向(DE/RE引脚),存在实时性差、CPU占用高等痛点。本文从硬件逻辑设计到Linux驱动开发,完整实现了ZYNQ平台的RS-485工业通信方案。,解决了传统方案实时性差的痛点。所有代码均经过实际项目验证,可直接用于生产环境。:尝试将此设计扩展为多协议兼容接口(支持RS-422/RS-232切换)!等特性,依然是现场总线通信的首选。,通过硬件逻辑+Linux驱动协同设计,实现零延迟切换。在工业自动化、能源电力等场景中,RS-485凭借。

QQ_778132974的博客 832

LabVIEW实现HTTP通信

本节简要介绍HTTP通信的基础知识,并以工业物联网平台TLINK中云端设备的数据发布设计为例,阐述互联网环境下HTTP客户端应用程序设计的基本方法。重点讲解工业物联网平台TLINK中HTTP设备的创建、通信数据帧的构造与测试。

不脱发的程序猿 1550

一文读懂RAG:从生活场景到核心逻辑,AI“查资料答题”原来这么简单

本文以生活化场景切入,通俗解读RAG(检索增强生成)技术。首先指出普通AI存在知识固定过时、易“瞎编”(幻觉)、无法处理专属内容的痛点,点明RAG通过添加“临时知识库”解决这些问题的核心价值。接着拆解RAG“准备专属知识库(拆文档、生成嵌入向量、存向量数据库)—实时检索相关资料(问题转向量、匹配相关片段)—结合资料生成答案”的三步核心逻辑,再通过对比表格清晰呈现RAG与普通AI在知识来源、答案准确性、专属内容处理能力上的差异。最后列举企业客服、个人学习、行业分析、内部办公等实际应用场景

小火龙的博客 682

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

【RAG 详解:让模型学会“查资料”】

本文讲解 RAG(检索增强生成)的核心原理与实现流程,涵盖向量化、向量数据库、Prompt 设计等关键技术,并基于 LangChain 搭建一个完整示例,帮助理解大模型如何通过“查资料”提升回答准确性。

zhai0104的博客 410

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

当大模型遇到“健忘症”,我为什么要写这本 RAG 的书!

我曾经测试过一个医疗 AI,问它一种 2024 年新发现的罕见疾病的治疗方法,大模型能够煞有介事地给出了一套“标准治疗方案”——而这种疾病根本不在它的训练数据,所谓的标准治疗方案,也只是统计结果上最类似疾病的治疗方案的抄袭。如果你也曾经因为 AI 的“胡言乱语”而苦恼,如果你也想让自己的 AI 应用更加智能和可靠,那么希望这本书能成为你探索路上的一个小小指南针。你不可能记住所有的法条和判例,这是事实,但你知道去哪里查找你要的法条和判例,这是你的专业素养,然后结合你的专业知识,为客户制定最佳的辩护策略。

图灵教育 174

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

RAG技术详解:让AI告别“胡说八道“,开发者必看收藏指南

文章介绍了RAG(检索增强生成)技术如何解决传统AI模型"胡说八道"的问题。RAG通过结合检索和生成两个步骤,先从向量数据库中查找相关信息,然后基于这些信息增强提示,最后生成更准确、可靠的答案。文章详细解释了RAG的三个核心步骤:检索、增强和生成,并强调了其在减少AI幻觉、实时更新知识和保护隐私方面的优势。

2401_85373691的博客 690

RAG 要被淘汰了?真正的升级方向是 Agentic RAG:让大模型自己查资料、做判断、会反思!

普通 RAG 只是“检索一次再回答”,而 Agentic RAG 让大模型自己决定查什么、查几次、用什么工具、是否继续验证。它正在把知识库问答升级成真正会思考的 AI 助手。

WenJGo的博客 2万+

从“会聊天”到“会查资料”:RAG 技术如何重塑企业知识库问答

文章摘要: RAG(检索增强生成)技术通过结合检索与生成能力,解决了通用大模型在企业知识库应用中存在的私有知识缺失和“幻觉”问题。其流程包括文档处理、向量化、检索、提示词拼接和答案生成,相比微调更适应频繁更新的企业知识场景,且成本低、可追溯来源。然而,落地难点涉及文档质量、文本切分、检索准确率和权限控制。典型应用如客服知识助手能显著提升效率。未来趋势将向Agentic RAG发展,实现多步骤任务自动化。RAG作为企业AI落地的关键技术,需综合优化各环节以释放知识价值。

2601_96268328的博客 1185

RAG技术详解:给AI装个“实时查资料“的外挂,告别瞎编!

RAG技术结合信息检索与自然语言生成,为AI提供实时查资料能力,解决传统AI"记不住新东西、容易瞎编"的问题。通过知识库分块、语义编码、向量检索、构建带资料的提示词等步骤,让大模型从"靠记忆答题"转变为"拿着参考资料回答的靠谱考生",使输出更准确、有依据且可溯源,广泛应用于聊天机器人、智能助理等场景。

Gaga246的博客 735

RAG技术详解:让大模型告别“胡说八道“的秘密武器_什么是RAG?

RAG技术:解决AI"幻觉"问题的创新方案 RAG(检索增强生成)技术通过"检索-增强-生成"三步骤,有效解决传统AI模型易产生错误信息的问题。该技术首先从海量数据中检索相关信息,然后将检索结果与用户问题结合形成增强提示,最后生成更准确的答案。相比仅依赖训练数据的传统AI,RAG具有三大优势:显著减少AI"幻觉"现象、支持实时知识更新、保护数据隐私。目前已在客服系统、知识问答等领域广泛应用,成为提升大模型可靠性的关键技术。学习RAG技术需要掌握向量

2401_84494441的博客 594

大模型开发:微调vs RAG,AI落地的“内功“与“外援“,一文看懂技术选型与黄金组合!

微调与RAG是大模型落地的两条核心技术路线。微调通过修改模型参数让模型"内化"专业知识,适合知识稳定场景;RAG通过外部检索让模型"借助"知识,适合知识动态变化场景。微调成本高但稳定,RAG灵活但依赖检索质量。未来趋势是"轻微调+智能RAG"的混合架构,RAG解决"知道什么",微调解决"怎么说",两者融合是通往真正智能应用的"黄金组合"。

m0_59163425的博客 705

【值得收藏】高校“AI+教育“大模型选型:微调vs RAG,助你避坑指南

本文探讨高校"AI+教育"中大模型技术选型,对比微调与RAG的原理、适用场景及挑战。微调适合专业课程教学和稳定科研,但需高算力和数据;RAG适合实时信息查询和多源知识整合,但依赖检索质量。文章提出"微调+RAG"协同架构作为最优解,建议高校根据学科特点和资源制定方案,以需求为导向,实现大模型在教学、科研和管理中的深度融合。

嘴巴吃糖了 973

收藏!小白程序员必看:从RAG到Agentic RAG,轻松入门大模型进阶玩法

本文介绍了RAG技术如何通过检索资料降低AI幻觉问题,并引出升级版本Agentic RAG。传统RAG通过“先查资料再回答”的模式提升AI可靠性,但存在只检索一次的局限。Agentic RAG则引入智能体(Agent)概念,能理解、拆解任务并多次检索,更接近真正的AI助手。文章对比了两者在动态决策、检索次数、任务拆解等方面的差异,指出Agentic RAG是RAG的进化形态,代表了AI从简单问答向复杂任务执行的转变趋势。

2401_85375186的博客 1391

大模型RAG技术如何让AI大模型变得更强大?

RAG 的全称是Retrieval-Augmented Generation,中文译为 “检索增强生成”。从名字上我们就能看出,它由 “检索(Retrieval)” 和 “生成(Generation)” 两部分组成,核心逻辑就是将 “检索外部知识” 与 “AI 生成回答” 这两个环节结合起来,让 AI 在生成回答前,先从外部知识库中找到相关的、可靠的信息,再基于这些信息进行创作,从而提升回答的准确性和丰富度。

star_nwe的博客 1017

收藏必备!小白也能看懂RAG,让你的AI生成模型“实时查资料”!

RAG是一种结合信息检索和自然语言生成技术,旨在提高生成模型的性能和准确性。它通过检索外部数据库或网页中的相关信息,并将其转换为可读的参考资料,最后生成答案。RAG的核心步骤包括检索、增强和生成。它解决了AI“记不住新东西、容易瞎编”的问题,使输出更准确、更有依据。RAG广泛应用于聊天机器人、智能助理等领域。RAG(Retrieval-Augmented Generation)是⼀种结合了信息检索和⾃然语⾔⽣成的技术,旨在提⾼⽣成模型的性能和准确性。

qq_46094651的博客 569

深入 RAG(检索增强生成)系统架构:如何构建一个能查资料的大语言模型系统

在大语言模型(LLM)迅猛发展的今天,如何突破“模型只能回答记住的内容”这一瓶颈,成为构建实用智能问答系统的关键。本文系统梳理了 RAG(Retrieval-Augmented Generation,检索增强生成)系统的核心原理、组成结构与工作流程。我们将深入解析向量检索、文档切分、Embedding 建模与上下文拼接等关键技术环节 文章不仅适合对 RAG 感兴趣的开发者和架构师,也为希望构建企业级智能问答助手的技术人员提供了明确的思路与实操建议。

博客虽小,世界尽在其中 3086

如何让AI变得更聪明?RAG vs 微调到底该怎么选?一篇文章带你彻底搞懂!

大模型很多技术干货,都可以共享给你们,如果你肯花时间沉下心去学习,它们一定能帮到你!

2401_85375186的博客 1235
上一篇: 我们用 RAG 自建了一个能读懂源码的智能知识库
下一篇: 我把运维知识库接入了大模型,然后发现 RAG 没那么简单
AI_小站
博客等级 码龄3年 6255粉丝 1154原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值