2024年大家都在为检索增强生成Retrieval-Augmented Generation, RAG着迷吗构建向量数据库vector database、分割文档chunking documents、创建嵌入embeddings以及处理复杂的流水线pipelines只为了回答关于公司文档的问题好吧我有一些消息可能会让你重新思考这一切。本文的目标是探讨 2025 年检索增强生成RAG的现状并深入分析关于“RAG 已死”的争论。我们将通过构建一个简单的 RAG 替代方案并将其与传统方法进行比较来实现这一目标。此外我们还将讨论“思考模型与非思考模型”的话题。为了验证这一想法我们将在 30 分钟内构建一个简单的问答QA代理完全跳过 RAG直接使用搜索 APITavily和大上下文窗口large context windows。你猜怎么着它不仅比传统 RAG 更简单、更便宜而且往往表现得更好。让我向你展示为什么这可能是基于文档的问答系统的未来。友情提示本文篇幅比较长请耐心阅读或者收藏慢慢阅读剧透警告不RAG 并未消亡——但在 2025 年它不应该是你的首选。保持简单2025 年的 RAG 大反思我们的目标不是抨击 RAG它仍有其用武之地而是通过一个实际案例来探索 2025 年的技术趋势。我们将构建一个传统上会使用 RAG 的系统但采用一种完全不同的、越来越流行的方法。通过本文你将了解•为什么“直接访问源数据”的方法go to source因工具调用tool calling和模型上下文协议MCP而逐渐受到关注。•RAG 仍然适用的场景剧透比你想象的少。•如何构建一个用户喜爱的实用替代方案。•额外内容为什么非思考模型non-thinking models在简单结构化任务中往往优于“思考模型”thinking models。准备好了吗让我们开始吧RAG优点、缺点与复杂性什么是 RAG你可以将 RAG 想象成一个非常高级的图书馆员系统。当有人提出问题时1.将文档分割成小块因为模型有上下文限制。2.将所有内容转换为嵌入embeddings数学表示形式。3.将嵌入存储在向量数据库vector database你的数字图书馆。4.当问题到来时将问题也转换为嵌入。5.使用向量相似性搜索vector similarity search找到相似的文档块。6.将这些文档块与问题一起输入到大型语言模型LLM。7.根据检索到的上下文生成答案。RAG 架构以下是一个简化的 RAG 流水线示例# 传统 RAG 流水线简化版想了解更多关于 RAG 的内容可以观看这个简短视频。RAG 的历史为何它曾如此流行在 2020-2023 年期间RAG 非常有意义原因如下•小上下文窗口GPT-3 只有 4K 令牌tokens这是 RAG 被引入的主要原因。•高昂的令牌成本处理大型文档的成本很高。•“迷失中间”问题模型无法很好地处理长上下文。•对新鲜数据的需求模型有训练数据截止时间。RAG 通过选择性地包含信息解决了这些问题并允许将最新数据添加到过时的模型中。简单 RAG 示例假设你有公司文档有人问“如何在我们的 API 中设置认证”传统 RAG 方法1.将文档分割成 500 字的块。2.找到 3-5 个与认证最相关的块。3.仅将这些块输入到 LLM。4.生成答案。在上下文受限且成本高昂时这种方法效果很好但……隐藏的复杂性RAG 的不为人知之处虽然 RAG 在理论上听起来优雅但实现和维护的现实远比大多数教程描述的复杂。以下是一些真正的挑战 基础设施噩梦•复杂设置RAG 需要向量数据库、嵌入流水线、分块策略、监控和扩展 → 高复杂度。•高成本向量数据库和 RAG 流水线的运行和维护成本高昂一旦数据量达到一定规模成本会激增每月可能高达数千美元。•供应商锁定选择 Pinecone、Weaviate、Chroma 或自托管解决方案均需支付高额月费。 分块问题分块是将文档分割成小块并保留语义意义的过程这些小块随后存储在向量数据库中。分块策略有很多种各有优缺点且都不完美以下是一些问题•上下文丢失分割文档会破坏逐步说明代码与解释分离。•无完美策略固定大小、语义或段落分块都有重大缺陷。•跨引用断裂相关部分被分开丢失重要联系。 相似性搜索的假象向量数据库使用相似性搜索概念上类似于 Elasticsearch但专为 LLM 嵌入优化。虽然 Elasticsearch 经过多年验证但向量数据库较新且仍在发展。正如我们稍后将讨论的RAG 的一个替代方案是利用现有的 Elasticsearch 基础设施通过创建工具查询其上下文检索。这种方法对已有 Elasticsearch 集群的组织特别有价值因为它避免了引入向量数据库等额外基础设施。•数学 ≠ 相关性高相似性得分并不保证结果有用。•查询不匹配问题与文档语句对齐不佳。•缺失上下文嵌入丢失重要的限定信息。 维护噩梦•文档更新每次更改都需要重新分块、重新嵌入、重新索引整个流水线•模型不兼容无法混合不同模型的嵌入升级 完全重建这使得切换模型非常具有挑战性•性能下降随着向量数据库的增长速度会变慢。一旦数据量较大延迟将成为问题。 扩展现实•指数成本基础设施需求增长速度超过文档数量。•收益递减更多文档往往意味着更差的搜索质量。•运营开销大型部署需要专门的 DevOps 团队。 常见失败•“迷失中间”LLM 忽略搜索结果中的中间块。•数据过时向量搜索没有新鲜度感知。•上下文碎片化复杂答案被分散在多个块中。现实检查•指数成本基础设施需求增长速度超过文档数量向量数据库扩展挑战。•收益递减更多文档往往意味着更差的搜索质量。•运营复杂性需要专门的 DevOps 专业知识。这种复杂性正是我们构建的简单搜索优先方法获得关注的原因。核心思想是直接访问数据而不是创建复杂的 RAG 流水线。通过使用成熟的搜索 API 和大上下文窗口我们可以以更低的复杂性获得更好的结果。RAG 在 2025 年格局已剧变上下文窗口革命过去 18 个月的变化彻底颠覆了一切上下文窗口 成本等等100 万令牌的窗口只需 0.075 美元这相当于大约 75 万字——整整一本书的内容谷歌凭借其 Gemini 模型引领了这波创新浪潮。得益于专用 TPU 和大规模数据中心基础设施谷歌将上下文窗口推高至 500 万令牌同时保持每令牌成本极低。然而长上下文窗口也有类似 RAG 的扩展问题真正的变化在于直接访问源数据而不是构建复杂的流水线。像 Gemini Flash 这样的模型为许多 LLM 使用场景提供了快速、成本效益高且简单的解决方案。此外最新的 Gemini 版本在主要基准测试中超越了大多数竞争对手。正如我们稍后将探讨的我非常喜欢 Gemini 2.0 Flash——它速度极快、价格实惠且能轻松处理大上下文窗口。更新Gemini Flash 2.5 模型刚刚发布是一个极佳的替代选择尽管价格略高。这开启了一个根本性的范式转变。与其将多个来源的数据加载到向量数据库并维护复杂的 RAG 流水线我们可以构建直接访问工具并将其提供给 LLM 和代理。核心思想是利用组织可能已经拥有的成熟解决方案例如文档网站或 Elasticsearch。这种方法远比传统 RAG 简单。凭借当今快速、价格实惠的 LLM 模型和大上下文窗口成本和延迟不再是限制因素。模型上下文协议MCP的引入从根本上改变了代理与工具的交互方式。MCP 使代理能够自动发现工具并动态连接到数据库、API 和企业系统而无需手动配置每个工具连接。这创建了真正的非确定性代理工作流non-deterministic agentic workflows其中魔法发生工具本身可以成为代理递归调用其他工具。想象一个代理发现数据库工具用它查询客户数据然后自动找到并调用电子邮件 API 工具发送个性化消息——所有这些都不需要预定的工作流。结果是自组织代理生态系统根据可用功能动态适应而不是依赖刚性编程或确定性工作流。曾经需要复杂手动设置的内容现在通过工具交互自然浮现使复杂的多代理系统对任何开发者都触手可及。未来文章预告在下一篇文章中我们将为代理添加 MCP并讨论 MCP 革命以及 CrewAI 或 LangGraph 等框架可能的消亡敬请期待关键外部数据检索工具如前所述RAG 的主要替代方案是构建直接查询源数据的工具提取相关内容并将其作为上下文提供给 LLM。额外福利这些工具本身可以是代理创建层次结构每个工具封装复杂性暴露简单的可发现接口。另一个优势是 LLM 可以根据输入动态决定使用哪些工具使代理能够智能选择工具并配置参数创建真正的非确定性工作流。以下是一些可用于从现有系统提取上下文的工具示例 公共搜索工具•Tavily使 LLM 能够搜索预索引的公共网站以获取相关上下文 → 这是我们将在代理中使用的工具 企业搜索工具•Elasticsearch 等平台直接连接到现有搜索索引以检索查询的相关数据。•利用现有基础设施无需重建已有的内容。•搜索引擎 vs 向量数据库像 Elasticsearch 这样的传统搜索引擎已使用多年在检索相关信息方面通常优于向量数据库。️ 数据库集成工具•SQL 生成使用 LLM 生成 SQL 查询并直接从数据库检索结构化数据的工具。这更复杂但可行。未来文章预告对数据库集成方法感兴趣请告诉我——我计划撰写一篇关于 LLM 到 SQL 工具和技术的专门文章得益于 MCP代理可用的工具数量激增你可以在这里找到精选列表也可以使用 Awesome MCP Servers 发现更多。你甚至可以直接从代理连接到远程服务器。我将在下一篇文章中详细讨论 MCP为什么 RAG 替代方案表现更好✅更简单的架构—— 更少的活动部件✅更低的维护成本—— 利用现有搜索基础设施✅始终新鲜的数据—— 无需担心过时嵌入✅成本效益高—— 现代 LLM 使这在经济上可行✅更快开发—— 基于成熟的搜索技术核心洞察当搜索引擎已经有效解决了检索问题时不要重新发明轮子。RAG 替代方案的优势✅搜索优先更便宜比传统 RAG 维护成本低得多搜索优先始终新鲜—— 无需更新过时索引或重新生成嵌入✅无“迷失中间”问题—— 搜索优先返回最相关内容✅更好的上下文相关性—— 搜索算法优化查询相关性✅更快迭代—— 文档更改时无需重新生成嵌入✅更简单调试—— 容易查看检索到的内容及原因然而RAG 在以下场景仍有用•超大数据集100GB•细粒度文档块访问控制•离线/隔离环境•超高流量场景10万查询/天•需要复杂关系的文档结论RAG 不应是首选仅在隐私敏感或数据难以即时访问的特定情况下考虑。动手实践构建搜索优先的问答代理好了理论讲够了让我们构建一个能证明搜索优先优于 RAG 的系统。获取代码关注本公众号并回复0615获取代码下载地址。我们要构建什么我们将创建一个特定领域的问答代理它•仅搜索批准的组织文档网站 → 设置护栏guardrails•使用搜索 API 而非向量数据库•在需要时回退到全面的网页抓取•提供透明的来源归因•可选地总结搜索结果以降低成本和延迟•成本仅为传统 RAG 系统的一小部分将其视为“无检索的 RAG”——我们用新鲜、全面的搜索结果增强生成而不是预处理的分块。传统上当我们受限于 4K 令牌窗口时开发者会将所有文档加载到向量数据库并使用 RAG 提取相关上下文。如前所述这相当复杂且难以维护。以下是传统解决方案的样子复杂 RAG 解决方案这种方法非常复杂我们的方法则不同直接使用工具访问源数据充分利用已证明其数据提取效果的现有搜索引擎。更简单的解决方案重要说明此解决方案专门适用于搜索引擎索引的公开网站。如果您处理的是内部文档或私有数据我很乐意展示如何使用 Elasticsearch 进行内部上下文检索或使用 SQL 即时检索结构化数据。特性为什么这优于传统 RAG架构实际工作原理1.初始化阶段代理启动时读取包含以下内容的 CSV 文件•要搜索的网站 URL•领域或类别主题/学科领域非网站域名•帮助 LLM 理解何时使用每个网站的描述2.查询处理当用户提交查询时LLM 分析查询并智能选择最可能提供答案的网站。所有查询均异步处理。3.搜索执行选定的网站被传递给搜索工具使用 Tavily 在这些预批准的域名内执行快速、针对性的搜索。4.动态决策根据搜索结果LLM 评估是否足以提供完整答案•如果是立即返回响应•如果否可能调用网页抓取工具以从特定页面收集更多细节此解决方案展示了真正代理化设计的美妙之处——简单却异常强大。我们不遵循僵化的预编程路径而是让代理根据每个查询的特定上下文智能决定采取哪些行动和使用哪些工具。为此我们使用简单的非思考模型遵循著名的 ReACT 框架让代理在循环中思考并决定下一步行动。这是使非思考模型“思考”的简单方法。我们使用双层策略•快速搜索90% 的查询使用 Tavily 在批准的域名内快速搜索并总结结果。•深度抓取10% 的查询当搜索不足以提供答案时抓取整个页面。ReACT vs 思考模型为什么我们选择速度而非“智能”这是一个有争议的观点我们故意选择 Gemini 2.0 Flash 而非“思考”模型如 OpenAI 的 o3 或 Gemini 2.5 Pro。为什么•Gemini Flash 2.0 便宜且快速•ReAct 框架以 1/200 的成本提供结构化思考我更喜欢使用带 ReACT 的非思考模型的主要原因是可扩展性。在许多情况下查询生成简单响应不需要广泛推理思考模型显得过于复杂。非思考模型为这些场景提供快速且成本效益高的解决方案。对于复杂问题ReACT 通过循环模拟思考模型的推理能力。ReAct 循环对于搜索和回答工作流这比内部链式推理chain-of-thought更高效。根据我的经验当使用多个工具且每个工具有多个输入时这种解决方案比使用链式推理 LLM 更有效。代理遵循 ReACT 提示每个工具的描述详细说明了输入和输出。运行应用程序时你会看到代理可能通过链式思考循环进行多次搜索或决定使用网页抓取所有这些都由代理自行决定无需人工干预✅ReACT 提示在长上下文窗口中也能有效防止幻觉hallucinations模型选择对于问答代理gemini-2.0-flash提供了出色的平衡具备惊人的速度、成本效益以及轻松处理大上下文窗口的能力。其免费层限制相当宽松提供每分钟 15 次请求RPM、每分钟 100 万令牌TPM和每天 1500 次请求RPD非常适合广泛的应用场景在考虑付费层之前。这是我在仓库中使用的模型。当您的问答代理需要更强的推理能力和更“智能”的响应时gemini-2.5-flash-preview-05-20是更好的选择。该模型性能更佳分析能力更强适合复杂查询。然而其免费层限制更严格例如10 RPM、25 万 TPM、500 RPD且价格略高。如果您有付费账户且需要高准确性请使用此模型。另一方面如果您的主要关注点是高吞吐量、成本效益和最大化免费层使用量以处理简单、高流量的问答gemini-2.0-flash-lite是最合适的替代选择。虽然其复杂推理能力略逊但其显著更高的速率限制例如30 RPM、100 万 TPM、1500 RPD和价格允许更大的交互量。实现让我们看看代码现在是激动人心的部分我们将逐步讲解实际实现。即使您对 Python 或 LangChain 不熟悉我也会一步步解释。我们使用LangChain因为它提供了统一的、模型无关的接口简化了复杂 LLM 应用的开发。它擅长通过“链”Chains和“代理”Agents编排多步骤工作流使 LLM 能够使用“工具”Tools并轻松管理对话记忆。这种抽象层减少了样板代码加速开发增强应用灵活性未来-proof并通过 LangSmith 等集成提供关键的调试功能。Pydantic AI是 LangChain 的一个更易用的替代方案。️ 架构概览文件如何协同工作仓库遵循简单的分层架构非常简洁项目结构流程•main.py→ 接收用户 HTTP 请求•qa_agent.py→ 决定使用哪些工具并编排响应•search_tool.py / scraping_tool.py→ 执行查找信息的实际工作•返回qa_agent.py→ 合并结果并生成最终答案•返回main.py→ 将响应返回给用户将其想象成一家餐厅main.py是服务员qa_agent.py是决定烹饪什么的厨师工具是专门的厨房设备。1. 搜索工具search_tool.py让我们从搜索功能开始。此工具连接到 Tavily 搜索 API 以查找相关信息。这里发生了什么•LangChain BaseTool我们继承这个类来创建代理可以使用的工具在下一篇文章中我们会将其转换为 MCP 服务器。•工具描述非常重要告诉代理何时以及如何使用工具。确保描述精确。•Pydantic 模型用于工具输入的类型验证——确保代理传递正确的参数。•域名限制通过include_domains参数实现护栏确保仅搜索批准的网站。•智能摘要可选的 AI 驱动结果压缩使用 Gemini Flash-Lite 降低令牌成本。•异步支持使用_arun方法支持异步执行。•错误处理全面的日志记录和优雅的失败恢复。•灵活配置支持不同的搜索深度和结果限制。2. 网页抓取工具scraping_tool.py可选当搜索结果不足时此工具抓取整个网页以获取全面信息。️这里发生了什么•AsyncChromiumLoader使用真实的 Chromium 浏览器处理 JavaScript 密集型网站。•BeautifulSoupTransformer从 HTML 中智能提取干净的文本。•选择性标签提取仅提取有意义的标签内容忽略导航和广告。•内容限制自动截断长页面以保持令牌成本合理。注意这里也可以使用摘要•错误恢复优雅处理网络故障、JavaScript 错误和解析问题。•异步支持内置异步方法以实现生产可扩展性。3. 问答代理qa_agent.py - 大脑 这里是魔法发生的地方。代理决定使用哪些工具并编排整个对话。{{{{ “action”: “TOOL_NAME,action_input:TOOL\_NAME, action\_input: TOOL_NAME,action_input:INPUT” }}}}$JSON_BLOB观察动作结果{{{{ “action”: “Final Answer”, “action_input”: “response” }}}}开始提醒始终以单个动作的有效 JSON blob 响应。如有需要使用工具。如果合适直接响应如果不明确则要求澄清。格式为动作$JSON_BLOB然后观察LangChain 使代理代码非常简单大部分代码是提示可以在未来提取到单独文件中。这里发生了什么•结构化聊天代理我们使用比基本 ReAct 代理更可靠的方法来处理复杂工具使用。我发现 LangChain 的create_structured_chat_agent方法 ReACT 使用非思考模型是需要人类交互的大多数代理的最佳组合。•提示我们使用 ReACT 框架加上特定指令和护栏仅回答特定类别/领域的问题。我们解析 CSV 内容并将其传递到系统提示中。•ChatGoogleGenerativeAI为 Gemini 优化的包装器具有适当的错误处理。•动态提示生成系统提示根据 CSV 中的可用知识来源动态适应。•MessagesPlaceholder启用对话记忆和上下文感知。•智能工具策略明确指令何时搜索、何时抓取。•生产安全性迭代限制、错误处理和全面日志记录。•异步支持为高性能网络应用而构建。4. FastAPI 服务器main.py - 前门 这创建了一个生产就绪的 Web API用户可以通过 HTTP 请求与之交互。这里发生了什么•FastAPI现代 Python Web 框架带自动 OpenAPI 文档。•Pydantic 模型类型安全的请求/响应验证和序列化。•依赖注入干净的架构适当的错误处理。•生命周期管理代理在启动时初始化并在请求间持续存在。•环境验证所有配置参数的全面验证。•Cookie 支持API 使用安全的 HTTP Cookie 为每个用户维护单独的对话记忆。首次请求时会自动生成唯一的会话 IDUUID并存储在安全 Cookie 中。每个会话 ID 创建自己的代理实例拥有隔离的记忆因此您的对话历史不会与其他用户混淆——即使他们同时使用 API。•生产功能健康检查、适当的日志记录、错误处理和监控。•异步支持完全异步架构以实现高负载下的性能。 整体工作流程完整流程以下是用户提问时发生的事情1.HTTP 请求→main.py接收到 POST 到 /chat 的消息2.验证→ Pydantic 验证请求格式和代理可用性3.代理处理→qa_agent.py接收问题及对话历史4.结构化思考→ 代理使用系统提示分析问题并决定策略5.工具选择→ 通常首先使用search_tool.py获取快速结果6.域名限制搜索→ 通过 Tavily API 仅搜索批准的域名7.结果评估→ 代理分析搜索质量并决定是否足够8.可选抓取→ 如有需要在最相关的 URL 上使用scraping_tool.py9.响应合成→ 代理将所有信息整合成连贯的答案10.记忆更新→ 更新对话历史以便在未来问题中提供上下文11.HTTP 响应→ 格式化的响应发送给客户端这种架构展示了非思考模型如 Gemini Flash 如何在结构化任务中超越昂贵的“思考”模型。ReAct 框架以极低的成本提供系统化推理而基于工具的架构确保可靠、可追溯的结果。非常适合使用公共网站的生产问答系统这如何扩展你可以不断添加更多工具SQL 生成与执行、Elasticsearch、S3 访问等等可能性无穷无尽只需构建更多工具并通过 MCP 暴露它们但首先检查 MCP 仓库很可能已经有人构建了集成。核心思想是直接访问数据而不是拥有复杂的数据流水线LLM 可以很好地处理噪声或不干净的数据让我们玩吧是时候看到代理的实际行动了以下是如何运行它设置知识来源要配置代理可以搜索的网站你需要编辑sites_data.csv文件。此 CSV 包含三列告诉代理有哪些资源可用CSV 结构•列 1领域/类别主题领域或话题例如“python”、“web-development”、“machine-learning”•列 2网站 URL实际网站域名例如“python.langchain.com”、“docs.python.org”•列 3描述清楚说明网站包含的内容及何时使用示例条目python,python.langchain.com,官方LangChainPython文档包括指南、教程和构建 LLM 应用的 API 参考专业提示描述至关重要——代理使用它来决定某个网站是否对回答用户问题有帮助。明确说明每个网站涵盖的主题和信息类型。你可以根据需要添加任意数量的网站。代理将根据用户查询和你的描述智能选择要搜索的网站。获取凭据你需要前往 Tavily 和 Google 获取 API 密钥。获取 Tavily API 密钥访问 tavily.com[1] 并注册免费账户。登录后导航到仪表板或 API 部分你会找到你的 API 密钥。Tavily 通常提供慷慨的免费层包含每月数千次搜索足以用于测试和小项目。获取 Gemini API 密钥访问 ai.google.dev[2]Google AI Studio并使用 Google 账户登录。在界面中寻找“获取 API 密钥”按钮或导航到 API 密钥部分。如有需要创建新项目然后生成 API 密钥。Google 的 Gemini API 也提供大量免费层请求足以用于开发和小型生产使用。获得两个密钥后你需要将它们添加到环境变量或配置文件中。大多数项目使用 .env 文件你可以在其中添加TAVILY_API_KEYyour_tavily_key_here确保这些密钥安全切勿提交到公共仓库。两项服务都提供出色的免费层因此你可以无前期成本开始构建和测试。免费配额通常足以用于开发和小型生产用途。现在我们可以启动服务器# 克隆并设置访问 http://localhost:8000/docs 查看文档甚至可以发送请求现在让我们用我仓库中的一些网站测试它。示例 1标准搜索curl -X POST http://localhost:8000/chat \响应{示例 2搜索 抓取回退curl -X POST http://localhost:8000/chat \代理首先搜索意识到需要更多细节然后自动抓取完整的 LlamaIndex 页面示例 3护栏生效curl -X POST http://localhost:8000/chat \响应{完美的护栏——无未经授权的知识访问注意此项目仅为教育目的示例代码不完美没有测试可能有错误等。这只是一个简单的例子用于讨论 RAG 话题不适用于生产就绪应用不过欢迎贡献和改进下一步想为这个项目贡献或扩展以下是一些激动人心的方向 即时改进•添加对多种文件格式的支持PDF、Word 文档•为常见问题实现缓存•添加分析和使用跟踪LangSmith 非常强大且易于使用•支持多种语言 高级功能•集成内部 Elasticsearch 以处理私有文档•SQL 生成和执行•动态代码执行•集成 Slack/Microsoft Teams 以部署聊天机器人查看 GitHub 仓库获取完整文档和贡献指南。 我们开发了一个强大而简单的代理几乎可以投入生产。它已经支持异步调用和错误处理等关键功能仅需微调即可部署。得益于 LangChain代理代码非常简单大部分复杂性由提示本身处理。结论未来比你想的更简单那么RAG 死了吗不完全是——但它不再是曾经的默认选择。以下是我在 2025 年学到的从简单开始对于大多数文档问答场景搜索优先方法比传统 RAG 更简单、更便宜且往往更有效。只有在简单工具不足的特定场景下才使用 RAG。经济已改变大上下文窗口和实惠的定价从根本上改变了成本方程。为什么构建复杂基础设施当你可以以几分钱搜索并加载整个文档在适当时候使用 RAG超大数据集、细粒度权限或特殊用例仍能从 RAG 中受益。但对大多数组织来说搜索优先是更好的起点。核心结论不要从最复杂的解决方案开始。从简单开始证明价值仅在必要时增加复杂性。考虑构建简单工具访问外部可用数据并将其提供给 LLM而不是构建复杂流水线。References[1]tavily.com:https://tavily.com[2]ai.google.dev:https://ai.google.dev想入门 AI 大模型却找不到清晰方向备考大厂 AI 岗还在四处搜集零散资料别再浪费时间啦2025 年AI 大模型全套学习资料已整理完毕从学习路线到面试真题从工具教程到行业报告一站式覆盖你的所有需求现在全部免费分享扫码免费领取全部内容​一、学习必备100本大模型电子书26 份行业报告 600 套技术PPT帮你看透 AI 趋势想了解大模型的行业动态、商业落地案例大模型电子书这份资料帮你站在 “行业高度” 学 AI1. 100本大模型方向电子书2. 26 份行业研究报告覆盖多领域实践与趋势报告包含阿里、DeepSeek 等权威机构发布的核心内容涵盖职业趋势《AI 职业趋势报告》《中国 AI 人才粮仓模型解析》商业落地《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》领域细分《AGI 在金融领域的应用报告》《AI GC 实践案例集》行业监测《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。3. 600套技术大会 PPT听行业大咖讲实战PPT 整理自 2024-2025 年热门技术大会包含百度、腾讯、字节等企业的一线实践安全方向《端侧大模型的安全建设》《大模型驱动安全升级腾讯代码安全实践》产品与创新《大模型产品如何创新与创收》《AI 时代的新范式构建 AI 产品》多模态与 Agent《Step-Video 开源模型视频生成进展》《Agentic RAG 的现在与未来》工程落地《从原型到生产AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。二、求职必看大厂 AI 岗面试 “弹药库”300 真题 107 道面经直接抱走想冲字节、腾讯、阿里、蔚来等大厂 AI 岗这份面试资料帮你提前 “押题”拒绝临场慌1. 107 道大厂面经覆盖 Prompt、RAG、大模型应用工程师等热门岗位面经整理自 2021-2025 年真实面试场景包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题每道题都附带思路解析2. 102 道 AI 大模型真题直击大模型核心考点针对大模型专属考题从概念到实践全面覆盖帮你理清底层逻辑3. 97 道 LLMs 真题聚焦大型语言模型高频问题专门拆解 LLMs 的核心痛点与解决方案比如让很多人头疼的 “复读机问题”三、路线必明 AI 大模型学习路线图1 张图理清核心内容刚接触 AI 大模型不知道该从哪学起这份「AI大模型 学习路线图」直接帮你划重点不用再盲目摸索路线图涵盖 5 大核心板块从基础到进阶层层递进一步步带你从入门到进阶从理论到实战。L1阶段:启航篇丨极速破界AI新时代L1阶段了解大模型的基础知识以及大模型在各个行业的应用和分析学习理解大模型的核心原理、关键技术以及大模型应用场景。L2阶段攻坚篇丨RAG开发实战工坊L2阶段AI大模型RAG应用开发工程主要学习RAG检索增强生成包括Naive RAG、Advanced-RAG以及RAG性能评估还有GraphRAG在内的多个RAG热门项目的分析。L3阶段跃迁篇丨Agent智能体架构设计L3阶段大模型Agent应用架构进阶实现主要学习LangChain、 LIamaIndex框架也会学习到AutoGPT、 MetaGPT等多Agent系统打造Agent智能体。L4阶段精进篇丨模型微调与私有化部署L4阶段大模型的微调和私有化部署更加深入的探讨Transformer架构学习大模型的微调技术利用DeepSpeed、Lamam Factory等工具快速进行模型微调并通过Ollama、vLLM等推理部署框架实现模型的快速部署。L5阶段专题集丨特训篇 【录播课】四、资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容​2025 年想抓住 AI 大模型的风口别犹豫这份免费资料就是你的 “起跑线”