我该怎么从 0 到 1 构建出一个企业级 RAG 系统 从当下AI Agent 开发的招聘热门给大家分享一下企业级 RAG 的构建流程以及如何才能从0 到 1 构建出一个让客户满意的 RAG 知识库系统。引言前段时间很火的 LLM WIKIOsbian这些概念火的太快很多人都在说还搁这儿学 RAG 呢早过时啦。但是过不过时可能只有那些老牌程序员或者具有大厂前瞻性思维的朋友才会清楚更或者你去看看GitHub 上那些开源很火的 RAG 框架比如 RAGFlow ,LightRAG,GraphRAG他们的星星可是一点没少哦。再多 bb 一句现在这些新概念一天一个AI 时代的 GitHub Star 就跟坐火箭一样三天不见就又听到 xx 框架火啦xx 过时啦。少看点贩卖焦虑的文章都是 qu本文篇章耗时三天打造的万字长文好多东西都是我自己一步一步踩的坑又填上的坑所以读起来肯定会耗时间并且在某些地方可能不太能理解为什么我要这么去设计可以尽情留下你的留言我看到了就会第一时间回复。文章将从以下几个话题开始延伸RAG 扫盲什么是 RAG目前大模型的能力已经很强了为什么还要我们来构建 RAG开源的 RAG 框架那么多为什么不开箱即用呢不同格式的文档文本视频音频我该怎么切分怎么清洗512-4096 维度的存储我应该如何选型才能检索的又快又准涉及到 embedding 和 Reranker 的时候我应该用哪一套组合Chroma、Faiss、Milvus、PGSQL、ES这么多向量存储引擎我又该选哪个索引如何才能优化我的 RAG 检索结果总是乱飘要不要用知识图谱体系大文档已经入库了但是文档更新了怎么办整库重建单文档切块更新LaLamaIndex 和 Langchain 到底哪个更适合做 RAG如何才能把我的 RAG 和智能体结合起来最终构建出一个让客户满意好用的 RAG 系统不知道你看到这些问题的时候是不是想起来了你被面试官拷打的场景了又或者有面试官恰巧看到我这篇文章有没有命中你在拷打面试者的情况什么是 RAGRAG 技术最开始在 2020 年的时候一篇论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》提出最开始的设想就是用来解决大模型自预训练阶段的知识无法满足实时更新的需求所以就提出来了通过外部的知识库向大模型注入的这种思想所以就有了 RAG 技术。RAG 技术主要的核心就是检索增强生成由一句话从库中检索出某个大模型不具备的知识再交由大模型进行增强扩充最后生成结果返回给用户。通俗的例子假如 A 是大模型你向 A 提问门口路边那个烧烤店昨天改了价格你知道多少钱吗A 肯定不知道但是这时候有个地方存储了这个更新后的菜单价格就可以在回答的时候根据你的提问去找到这家烧烤店的最新价格然后告诉 AA 这时候就能直接回答你了所以我们构建 RAG 是为了解决大模型在预训练阶段不存在的知识在回答方面出现的幻觉问题例如企业内部员工培训手册福利待遇又或者是一些私有的文档。各开源RAG框架对比了解 RAG 的朋友可能或多或少都听过一些著名的 RAG 框架比如 LightRAG 主打轻量化GraphRAG 主打图谱检索RAGFLow 主打编排。我也不是说这些框架不好用人家开源出来肯定是有实际使用地方的。但是框架始终是具有黑盒性你无法高度定制化稍不注意改人家代码就改崩并且有些时候框架的功能在我们的落地场景中也可能存在过度设计的情况。但是虽然我们用不了这些开源框架但是我们是可以学习人家的设计思想的用一张 Gemini 生成的对比图给大家看看他们的设计思想这些。GraphRAG面向知识图谱的 RAG 框架通过复杂且庞大的知识图谱来构建整个检索体系本质上其实是一次耗费成本巨大的构建和廉价的查询 这样做的优点查询结果及其准确是 RAGFLow 和 LightRAG 无法比的但是缺点也非常明显对知识的准备要求高构建成本的成本高灵活性以及扩展性都比较差LightRAG听名字就知道很轻量化设计思想主要是两个层面通过细粒度实体关系完成精细化检索然后通过实体作为社区聚合类来完成宏观上的表达。优点就是极致的轻量化构建快部署也快但是在稍微复杂的知识体系上可能就稍逊 GraphRAG 了RAGFlowGitHub Star 最多的RAG 框架通过传统的关键字检索向量语义检索这也是我们主推的设计思路并且在数据处理方面也有多层架构流水线处理同时解决掉复杂文档和简单文档的清洗切分而且有意思的是这哥们儿在最近的版本直接把 GraphRAG 和 Light 的设计思路揉进去了把图谱的检索变成了一个可插拔的插件。所以这个框架也是我们学习的一个好框架我能想到唯一的缺点就是太重了定制化不好做。再强调一下我并不是说不让你用这些框架我们学习的永远是设计思路不是框架本身当你有那个能力的时候你也能做出一款这样的框架。文本清洗切分的艺术这个标题起的有意思我自己都笑了。当我们开始着手准备构建一个 RAG 系统时第一件事就直接劝退大多小白文档格式辣么多怎么洗当然是人工洗啊不然指望谁给你洗。我们的文本格式从 txtwordExcelpdfppt 这种稍微带有结构化性质的文档再到图片音频视频资料这种非结构化的文档所以想要设计一个通用的数据清洗基本上是不可能的那我们只能从架构设计上动手了。文档暂且分为三类简单文档和复杂文档以及多模态文档。这里的简单指的时txtExcel pdf 那种行列或者结构清晰的数据这种文档我们可以借助 Python 的一些通用文档解析包比如pandoc,python-doc,docx2txt;但是对于那种复杂的扫描件又或者是图文混合的文档这时候你会发现传统的 Python 包搞不定了那咋整考虑多层降级解析目前我了解到最好的开源工具Mineru支持私有化部署和在线调用让这个工具作为第一层解析但是 mineru 我发现在解析层面也会遇到某些图片数据解析后是乱码的情况那么此时用第二层降级ocr或者VL 视觉模型通过这两种方式对文本内容进行提取再者还不行那就上一点成本最大的方案整份文档交给模型解析数据仅限于数据少的。对于音视频信息如果视频内容非常复杂且庞大建议是通过 ASR 音频解析文本截图抽帧 ocrvl 方案文本提取。所以到这里我们的数据清洗层就算是搭建了一个稍微完善一点的前置步骤。我们拿到文本后切分怎么办一股脑的滑动窗口切分又或者不管 3721 直接就父子切分那考没考虑过不同文档大小的情况下切分的块和滑动窗口如何设计大小所以针对上述的几种文本格式我们会考虑以下几种对应的切分方式固定大小切分根据文档大小固定的 100,200 字符进行拆分字符切分某些文档按行的句号感叹号分好段的那么我们可以直接根据这种方式进行切分结构化切分顾名思义一页一个块适用于 pptmarkdown 文件这些滑动窗口切分这也是用的多的。主要思路就是借助一个文档重叠区域来尽可能减少上下文语义丢失的情况embedding 语义或者大模型语义切分将一份文档交由 embedding 或者大模型按照语义进行拆分但是这种对于 embedding 模型的要求较高尤其是业务方向上的 embedding 和大模型比如医疗金融审计等等父子切分这也是用的多的对父块进行上述的几种切分方式得到大块再对这个大块按照上述的切分方式得到小块检索时用小块做检索返回上下文则直接返回大块特殊音视频根据ASR 解析文本得到时间刻度再根据刻度进行切分minio 存储检索所以上述的几种方案我们用一张图来描述就是向量库怎么选技术发展到现在向量库真的是百花齐放从老牌的 MilvusChromaFaiss再到 pgsqles而且听说 MySQL 的 v9 版本也要开始搞向量化了看样子是真的被 AI 时代拉着走。首先来说Chroma 和 Faiss 两款属于是内存向量库这是什么意思应该不用我多说了吧你敢放几百万数据到内存就算有磁盘持久化在高并发和索引方面也不够亮眼但是可以玩玩写一段伪代码如下import numpy as npfrom sentence_transformers import SentenceTransformerfrom dd_vectordb import FAISSVectorDB, ChromaVectorDB# --- 1. 初始化嵌入模型 (此例使用通用多语言模型)embedder SentenceTransformer(sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2)texts [ LangChain 是一个用于构建大语言模型应用的框架。, 向量数据库是实现语义搜索的关键技术。, 今天天气真好适合出去散步。,]# 生成向量embeddings [embedder.encode(t).tolist() for t in texts]# --- 2. 定义接口函数方便切换数据库def get_vector_db(backend: str): if backend faiss: # 使用 FAISS必须指定向量维度 (此模型为 384) db FAISSVectorDB(dimension384, metriccosine) elif backend chroma: db ChromaVectorDB( collection_namemy_docs, persist_directory./chroma_data # 持久化存储路径 ) else: raise ValueError(f不支持的数据库类型: {backend}) # 将数据加入数据库核心逻辑完全一致 db.add_texts(textstexts, embeddingsembeddings) return db# 3. 用户业务逻辑从数据库进行检索的函数def search_similar(query: str, db): query_vec embedder.encode(query).tolist() results db.search(query_vec, k2) for r in results: print(f得分: {r.score:.4f} - {r.document.text})# 4. 演示无缝切换执行下面任意一行替换 db get_vector_db(...) 即可db get_vector_db(faiss) # 使用 FAISS# db get_vector_db(chroma) # 使用 Chromaprint(使用数据库:, type(db).__name__)search_similar(解释什么是向量数据库, db)再说说 pgsql如果你的业务数据库本身就是 pgsql那我是比较推荐你用的从 0.16 的版本开始pgsql 就支持安装 pgvector 插件来支持数据向量化了这样做的好处就是可以完美无缝衔接你们的数据库无需额外在构建一个数据库出来但是在性能层面千万级别下算是可观千万级别往上就开始捉襟见肘。es 呢目前来看比较优秀的一个不支持事务但是全文关键词检索分布式存储且整个庞大的 ELK 生态都及其友好如果你的业务系统订单系统商城系统已经用上了 es 且有一整套完整的 ELK 系统那我是建议你用这个的而且对后续讲到的 BM25 也能完美融合。Milvus看官网描述说的是单机支持万亿同样不支持事务但是好处就是与 Python 和 Java 的生态整合及其简单你甚至两行代码就能构建出一个 Milvus 向量库。同时支持 HNSWIVF 等多种不同索引检索效率与 es 不相上下。适用场景在与你如果是准备用 Python 生态构建一个 RAG选型的时候我是建议你用 Milvus 的安装部署也非常简单且有分布式场景下的解决方案。另外因为大部分的数据库都支持多种索引所以额外介绍下各种索引的应用场景。向量库的索引和 MySQL 的索引都差不多只是一个是结构化一个是非结构化都从检索性能上来描述分为以下的索引Flat,IVF,PQ,HNSW,LSH,IVF_SQ8不同的索引在存储和检索精度上是有很大的差异的。体现在数据量上给个建议1万直接用 Flat精度100%速度可接受。1万 - 100万IVF 或 HNSW。HNSW更快但内存大IVF更平衡。100万 - 1000万HNSW内存32GB或 IVF_PQ内存受限。大于1亿IVF_PQ 或 LSH配合分布式存储。在性能上追求极致速度HNSW内存换速度 IVF_FLAT较均衡。追求极致内存PQ SQ8 IVF_FLAT。追求绝对精度Flat但只适合小数据或调高HNSW的ef_search参数精度可接近99.9%。在我上面说的那些数据库中常见的默认FAISS提供最丰富的索引常用 IndexFlatIP (暴力余弦)、IndexIVFFlat、IndexHNSWFlat、IndexIVFPQ。Milvus默认索引为 IVF_FLAT还支持 HNSW、IVF_PQ、ANNOY 等。pgvector默认使用 IVFFlat还可以选择 HNSW需编译扩展。Chroma底层封装了HNSW通过hnswlib库。Elasticsearch提供 HNSW 或 IVF 等选择8.0版本默认使用HNSW。索引类型代表算法核心思想搜索速度构建速度内存占用精度适用场景精确索引Flat (暴力)计算所有向量与查询的距离返回TopK极慢 O(N)无构建过程低仅存原始向量100%数据量1万、对精度绝对要求、作为基准对比基于聚类的IVF (倒排文件)IVF_PQ对全量数据K-Means聚类检索时只搜索最近的几个聚类快中等中需存聚类中心95-99%百万级数据、要求快速召回、对精度不极端敏感基于量化的PQ (乘积量化)将向量切分成多个子空间分别压缩编码大幅降低内存中等慢量化训练极低压缩编码85-95%十亿级数据、内存严重受限、可接受一定精度损失基于图的HNSW构建多层图结构贪婪搜索近似最优路径极快慢图构建高需存储多层图98-99%千万级数据、要求亚毫秒级延迟、内存充足哈希家族LSH (局部敏感哈希)用一组哈希函数将相似向量以高概率映射到同一桶快快低仅存储哈希桶70-90%超高维、极大规模、对精度要求不高倒排量化IVF_SQ8先IVF聚类再对残差标量量化每个维度用1字节表示较快中等低90-95%内存敏感的大规模检索比PQ实现简单该说不说DeepSeek 在总结这些东西方面挺牛逼的。但是可能你在用这个向量库的时候会遇到一个选择维度怎么选维度是个啥在向量数据库和嵌入模型里维度就是用来表示一个向量一个物体、一句话、一张图的数字个数。例如 512 维意味着用一个包含 512 个浮点数的列表来描述一个对象。可以类比为“空间坐标”二维点是 (x, y)三维是 (x, y, z)而 512 维就是在一个 512 维的超空间里的一个点。维度越高这个“坐标”能刻画的信息就越细腻、越丰富。我们常见的开源向量模型的维度大多集中在 512-4096 之间那么怎么选 不同的维度带来的不同影响语义区分能力 高维度能捕捉更多细节一段话的语法、语气、特定实体都能被编码到不同维度上。 低维度会丢失一些细微差异但主要语义主题、情感仍能保留。存储与内存 向量维度每增加一倍存储空间就增加一倍因为每个维度一个浮点数。 例如100 万个 512 维向量float32≈ 2 GB同样数量 1536 维向量 ≈ 6 GB。检索速度 暴力搜索Flat耗时与维度成正比计算两个向量相似度需遍历所有维度。 ANN 索引如 HNSW、IVF虽然能大幅加速但维度越高索引构建越慢查询延迟也会上升别想着维度越高越好这是一个很大的平衡点。有时候你的 RAG 检索召回率不高或者答案与问题无关维度的选择也是一个很大的影响点。开源 embedding 和 reranker 那么多我该选哪个先讲述一个现实问题为什么有了embedding 之后我们还必须用 rerankerEmbedding 的本质是“模糊匹配”不是“精准匹配”Embedding 模型将文本映射到高维语义空间相似的句子距离近。这个特性让它擅长理解意图比如 “how to kill a process” 和 “how to terminate a task” 会被认为是相关的。但问题在于它会对所有召回结果统一计算相似度容易被“局部语义相似但整体不相关”的内容干扰。例如你搜 “苹果公司股价”一篇讨论“苹果这种水果的种植技术”的文章可能因为“苹果”一词的语义而排得很前即使它完全不相关。为了效率向量检索通常只返回 Top-K如 100 个最相似的文档。但这个 Top-100 里可能有 20 个是真正有用的剩下 80 个都是“看起来像但实际不相关”的噪声。如果直接将这 100 个喂给 LLM不仅浪费 token还可能因为混杂的错误信息干扰 LLM 的答案。Reranker通常是基于 Cross-Encoder 架构的模型会同时将用户查询和每个候选文档拼接起来输入到一个深度模型中输出一个相关性得分比如 0~1 之间的分数。这个过程非常打脑阔因为每个文档都要过一次大模型但极其精确它能看到查询和文档之间的细粒度交互而不是像 Embedding 那样先把两者独立编码再算余弦距离。举个例子Embedding像两个陌生人分别写一份个人简介然后对比简介的相似度。Reranker让两个人面对面交谈直接感受对方是否真正理解自己的问题。所以典型的两阶段策略是Embedding 召回从海量文档中快速筛选出 Top-100 候选快、宽泛。Reranker 精排对这 100 个候选逐一打分选出 Top-5 真正相关的文档慢、精准。那组合怎么选嗯这个怎么说呢如果你对场景要求不高那就无脑直接bge-m3bge-reranker-v2-m3组合就行这一套组合是目前生产环境上最稳定最经受考验的。当然同款产品如果你的文档大多是中英混合文档那么建议你考虑采用 Qwen 系列的Qwen3-Embedding-4B Qwen3-Reranker-4B。如果你的文档是纯中文且精度要求极高那么建议你Youtu-Embedding bge-reranker-large在推理延迟方面Jina Reranker v3这个 0.6B 的小模型反而比 Qwen 系列更快简单的总结就是Embedding模型的参数量与维度参数量很大程度上决定了模型的上限。像Qwen3-Embedding-8B、Youtu-Embedding这样的模型凭借巨大的参数量能够学习到更复杂的语言模式。模型输出的向量维度则直接影响检索的精度和速度维度越高存储成本越高检索速度越慢但通常语义区分能力也越强例如Qwen3-Embedding系列从0.6B的1024维到8B的4096维。Reranker模型的选择权衡 Reranker是基于Cross-Encoder架构的它需要对每个query, document对进行联合推理因此精度虽高但计算成本也很高。因此Reranker必须在精度和延迟之间做出权衡追求极致精度时可以考虑Qwen3-Reranker-8B而在延迟敏感的生产环境中Jina Reranker v3或 BGE-Reranker-v2-m3 是更务实的选择BM25RRF组合的离谱实力先描述一下概念BM25 是一种基于关键词统计的相关性评分算法是传统搜索引擎如 Elasticsearch、Lucene的核心。核心思想一个词在文档中出现得越多文档越相关词频 TF。但一个词在所有文档中出现得越普遍如“的”、“是”它的重要性就越低逆文档频率 IDF。同时对长文档会做惩罚因为长文档更容易包含更多词。优点速度快无需训练。擅长精确匹配用户输入“OpenAI 收购 Anthropic”BM25 能精准匹配到包含这些词的文档。对罕见词如产品型号、法律条款编号非常有效。缺点无法理解语义搜“苹果手机”永远找不到内容为“iPhone”但没写“手机”的文档。对同义词、多义词无能为力。举例 查询 “机器学习 模型 部署” BM25 会给文档中高频出现这几个词的文档打高分哪怕文档讲的只是 “Keras 模型保存” 而不是 “模型部署流程”那 RRF 又是什么RRF 是一种不依赖具体分数、只依赖排名的融合算法。它用来把多个不同检索系统如 Embedding 召回结果和 BM25 召回结果的排序列表合并成一个统一的排序。为什么需要 RRFEmbedding 检索和 BM25 检索有互补性Embedding 能理解语义BM25 能精确匹配关键词。单独使用任一个都会漏掉一些好的结果。但两者的相关性分数Embedding 的余弦相似度 vs BM25 的得分量纲不同无法直接相加或比较。RRF 巧妙地避开了这个问题。其实这些概念有点太过于生涩无法轻易理解但是看到这里了那么一个完整的流程就出来了使用 Embedding 模型做向量检索召回 Top-200。使用 BM25 做关键词检索召回 Top-200。结果融合RRF将两路结果合并得到 Top-100 候选。精排Reranker使用 Cross-Encoder 模型如 BGE-Reranker-v2-m3对 Top-100 重新打分选出 Top-5。送入 LLM将最终的 Top-5 文档作为上下文与问题一起提交给大模型生成答案。文档更新咋个办是删库跑路还是拼一把重建能提出这个问题那说明业务场景是肯定存在的一些常见的知识库文档更新后偏偏就只更新那一点点。在你整个文档特别大的情况下你全库重建所以到这里你的处理目的就不是要简单的更新而是怎么才能更优雅的更新了。所以常见的方案就几种了小文档直接重建。这种方案虽然有点暴力但是无疑是最简单最高效的办法了。单文档切块更新比较恶心的维护方式什么意思给每个块打个标记弄一个唯一 Id文档更新的时候把这个块以及它的相邻块打成待更新为啥要相邻自己想吧然后把新块直接原子性更新进去完事儿理想化的思路文档 diff 更新借助了块更新的思路那就是直接比较两个新旧文档找出不一样的地方然后直接更新但是这种方案大概率落地不了因为文档太大就完蛋。向量库不像 MySQL 那种结构化数据可以直接 update所以维护数据也是一门比较讲究的艺术了。Langchain和llamaindex怎么选这个问题就跟当年问“Spring 和 MyBatis 到底用哪个”一样属于经典引战题。我的观点很直接如果你只做 RAG无脑 LlamaIndex如果你要做更复杂的智能体Agent系统LangChain 的生态更香。LlamaIndex专为“索引”而生这哥们儿的名字就暴露了它的野心——索引。它的核心抽象就是“把各种各样的数据索引成 LLM 能理解的格式”。数据连接器Data ConnectorsLlamaIndex 内置了一大堆开箱即用的文档加载器从 Notion、Slack 到数据库拿来就用这也是你前面文章里一直强调的“别重复造轮子”的思路。索引构建极其优雅你想要树索引列表索引关键词索引向量索引LlamaIndex 把各种索引结构抽象得很好而且支持索引的组合和嵌套。前面花那么多篇幅聊的父子切分、滑动窗口在 LlamaIndex 里都是几行配置的事。查询引擎Query Engine它把“检索→后处理→合成答案”这条链路打包成了查询引擎非常符合 RAG 的直觉思维。一句话总结LlamaIndex 是为 RAG 场景深度优化的框架它把数据摄取和检索这件事儿做到了极致。 如果你现在的核心任务就是高效、精准地搭建一个知识库问答系统选它包没错。LangChain 的野心明显更大它想当 LLM 应用的“万能胶水”而 RAG 只是它众多能力中的一个。它的核心抽象是“链Chain”和“智能体Agent”。链式调用你定义好步骤 A、B、CLangChain 帮你串起来。步骤 A 是查询改写步骤 B 是调用检索器步骤 C 是调用大模型这种流程化、可编排的思想在你需要做复杂的多步推理时会非常顺手。智能体抽象这是 LangChain 真正的杀手锏。智能体能自己决定“要不要查”、“查几次”、“查完干点啥”。比如用户问“帮我比较一下张三昨天的工资和上个月的平均工资”智能体可能会先查昨天的工资条再查上个月的工资表最后在脑子里算一遍给你结果。不要纠结“二选一”。这俩压根不是对立关系你完全可以用 LlamaIndex 负责数据索引和检索然后把构建好的“检索器”作为一个工具挂载到 LangChain 的智能体上去。学习人家解决问题的思路而不是站队。收尾怎么构建一个 RAG前面写了那么多从清洗到切分从向量库到精排说到底都是在解决一件事怎么在 99% 的情况下把对的文档块从海量知识里捞出来。但只做到这一点在客户眼里你顶多是个“60 分的系统”。客户要的不是一个更快的搜索框客户要的是一个“懂他”的智能体。那从 60 分到 90 分缺的是什么引入“意图理解”与“查询改写”用户问的问题大概率不是你 RAG 能直接检索的。用户问“我快疯了你们这个系统的报表为什么老是加载不出来”这时候如果你把这个句子扔给 embedding 去检索搜出来的大概率是“精神健康”、“压力管理”之类牛头不对马嘴的文档。这时候你要做的不是直接检索而是让一个 LLM 先做一次意图理解与查询改写LLM 会分析用户的原始愤怒发言提炼出真正的检索意图“系统报表加载失败的原因及排查方法”然后用这个改写后的、干净精准的句子去检索。这一步能让你的召回率从 30% 飙升到 80%。实现“多跳推理”与“工具调用”客户的问题往往不是单次检索能解决的。“公司去年在新能源领域总投入是多少其中技术研发占比多少”这种问题你需要智能体自己去规划路径先检索“去年新能源领域总投入”拿到数字 5.7 亿再检索“新能源领域技术研发投入”拿到 2.1 亿最后算一下 2.1/5.7告诉用户是 36.8%。这就是 LangChain 这类框架赋予智能体的核心能力让 LLM 学会使用工具检索器只是工具之一还可以是计算器、代码解释器、天气 API并自主规划解决一个复杂问题的步骤。构建对话记忆与用户画像这是“好用”的最后一公里。客户问“上次那个离职的同事他的社保停了没”几轮对话之后又问“那给新来的那个小张的办好了没”没有记忆的系统“请问您说的是哪件事”有记忆的系统它能记住上一轮上下文里讨论的是“离职同事的社保”并从记忆里调取出“新来的小张”正在办理入职手续。它甚至能结合用户画像知道提问者是 HR 部门的所以优先在 HR 相关的文档里进行检索。到这里你给客户的不再是一个生硬的问答机器人而是一个能记住上下文、理解潜台词、主动调用工具解决问题的智能助手。最后收个尾。这篇文章从最底层的文本切分一路聊到最上层的智能体设计不知道你发现了没真正让一个系统好用的从来不是某一个单点技术有多炫酷而是你把这些看似独立的技术清洗、向量、精排、意图、记忆像乐高积木一样精心设计、稳定拼接在一起的那个架构。任何告诉你“用了 xxx 框架一天就能做出企业级 RAG”的记住我前面那句话都是 qu。最后奉上整篇文章讲到的所有技术点的设计图和架构图Gemini 的图感觉一般学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】