Prompt, Context, Loop: The Three Engineering Layers Every RAG System Is Built On

提示、上下文、循环：构建每个 RAG 系统所依赖的三个工程层级 | Towards Data Science

大型语言模型

提示、上下文、循环：构建每个 RAG 系统所依赖的三个工程层级

企业文档智能 [Vol.1 #M2] – 每个 RAG 系统都基于单个 LLM 调用堆叠的三个工程层级：提示（调用本身）、上下文（填充模型窗口的内容）、循环（下一次调用何时触发以及何时停止）。了解你所处的层级是构建和调试 RAG 系统的一半工作。

angela shi

2026年8月3日

23分钟阅读

分享

照片由Karola G提供，来源：Pexels。

每个 RAG 系统都基于单个 LLM 调用堆叠的三个工程层级。提示工程是调用本身：系统消息、指令、固定输出形状的模式。上下文工程是填充模型窗口的内容：检索、压缩、决定保留什么内容。循环工程是围绕调用发生的内容：下一次调用何时触发、循环何时停止、检查失败时系统如何恢复。几乎所有关于 RAG 的争论实际上都是关于你所处这三个层级的争论。命名层级后，大部分困惑都会消散。本文是地图：每个层级的职责、它们如何映射到系列内容，以及为什么“一个取代下一个”的整洁故事只讲对了一半。

本文是企业文档智能系列的宣言，该系列通过四个模块构建企业级 RAG 系统。它探讨了已成为 2026 年主流叙事的三层架构（提示工程、上下文工程、循环工程），并提出更困难的问题：从一个层级到下一个层级的演进是否真的是一条序列，还是对原本就存在的模式施加的回顾性叙事？

本文在系列中的位置：与编号主干并列的宣言 – 图片由作者提供

📓 该系列的配套笔记本文件托管在 GitHub 上，地址为 doc-intel/notebooks-vol1。每个笔记本文件都能在真实 PDF 上端到端运行一个模块，因此你可以观察这三个层级如何展开：固定答案形状的提示、从解析问题和检索页面组装的上下文、检查失败时重试的循环。

公共配套代码仓库 doc-intel/notebooks-vol1 – 图片由作者提供

1. 三层架构

三个学科堆叠在 LLM 调用之上。每个层级负责不同的杠杆；它们共同描述了大多数生产团队在超越 hello-world 示例后所做的工作。

提示编写调用，上下文填充窗口，循环触发下一次调用 – 图片由作者提供

提示工程是每个人首先接触的层级。模型需要一个设置其角色和约束的系统消息、一个携带问题和上下文块的用户消息，以及一个固定预期输出形状的模式（可选）。高质量地编写这三部分是区分遵循规则的模型与即兴发挥模型的关键差异。这项学科在 2022-2023 年随 GPT-3.5 和 ChatGPT 一起推出；“提示工程”这一术语也在同一时期进入公众讨论。

上下文工程是当单个提示已不足以解决问题时所引入的层次。模型具有有限的上下文窗口，实践者决定填充内容。检索选择相关文档，压缩去除噪声，隔离防止子代理输出干扰主窗口。这四种经典策略（LangChain 的 write、select、compress、isolate）命名了实践者自第一篇 RAG 论文以来一直隐式执行的操作。该术语于 2025 年确立（Karpathy 和 Tobi Lütke 公开使用，Anthropic 在 2025 年发布经典论文《AI 代理的有效上下文工程》）。

循环工程是当单次调用已不足以解决问题时引入的层次。模型生成了符合格式但不符合模式的答案，列表返回了十二项但模型本身标记答案不完整，API 超时，代理选择了错误工具。此时实践者拥有四个控制面：触发下一次调用的条件、循环终止时机、调用失败时的系统恢复方式、独立代理在提交前验证结果的方式。该术语于 2026 年 5 月确立，Boris Cherny 的表述“I don’t prompt Claude anymore. I have loops running that prompt Claude”以及 Anthropic 十天后发布的 Dynamic Workflows 标志着这一阶段。

叙事本身在演进：提示工程演变为上下文工程，再演变为循环工程，每一层的引入都是在前一层达到瓶颈时发生的。这是一个清晰的故事，但略显不准确。

2. 真实情况：模式早于术语出现

每一层的模式都早于术语的出现。ReAct（普林斯顿大学和谷歌，2022 年 10 月）是经典的推理加行动循环，比“循环工程”这一术语早三年多。AutoGPT 于 2023 年 3 月公开了自主目标驱动的循环。Reflexion 在 2023 年 NeurIPS 会议上增加了自我评估功能。Geoffrey Huntley 的 Ralph Loop 于 2025 年 7 月将目标存储到磁盘。当“循环工程”这一术语于 2026 年 5 月确立时，这些模式已实际应用超过三年。

上下文工程领域同样如此。最初的 RAG 论文（Lewis 等，2020 年）比“提示工程”作为术语的出现早两年。到 2022 年，所有严肃的 LLM 应用都已具备上下文管理方案（分块、检索、去重、截断），但当时尚未被称为“上下文工程”。LangChain 的四策略分类法（write、select、compress、isolate）命名了过去四年所有生产级 RAG 系统中隐式执行的操作。

模式早于术语出现数年；当某一层成为瓶颈时，术语才会确立 – 图片作者提供

真实情况是，这三个层次自 LLM 时代开始就同时存在。在四年的窗口期内发生变化的是哪一层成为生产中的主要瓶颈。只要瓶颈是提示质量，没人关注循环；一旦瓶颈转向上下文规范，LangChain 分类法就会明确；一旦瓶颈再次转向多轮对话中的代理可靠性，Anthropic 的动态工作流目录就会跟进。

学科演进的叙事适合制作简洁的幻灯片。真正描述变化的是瓶颈转移的叙事。

3. 为何瓶颈会转移

三种力量会随时间推移将瓶颈向上推动。

模型在每一层的表现越来越好。每一代模型都需要更少的提示工程就能生成流畅的回答。GPT-4执行了GPT-3忽视的指令，Claude 3.5返回了有效JSON，而早期模型会将JSON包裹在文本中。提示工程层并未消失；它只是不再是瓶颈所在。下一代模型将淘汰今天大部分被视为上下文工程的内容（更长的有效上下文窗口、更少的上下文注意力衰减、原生的多文档推理）。上层所剩的，正是这些内容。

上下文窗口尺寸持续扩大。2023年初的模型搭载4k上下文窗口；同年Claude 2已实现10万上下文窗口，到2024年Gemini 1.5实现百万级上下文窗口，2026年百万级窗口成为主流。虽然媒体仍夸大有效召回能力（百万级窗口的模型在达到名义上限前就会出现上下文腐化），但上下文管理的工程压力正在改变形态。选择重点已不再是"如何装下所有内容"，而是"需要排除哪些内容"，让模型仍能检索到关键信息。瓶颈从"装入"转向"筛选"，这正是"选择"和"隔离"策略的核心。

生产流程持续延长。2022年的用例是单次问答会话，2026年的用例是持续六小时、进行四十轮的智能体，会生成子智能体进行发散与综合。2022年的用例无需循环工程，因为根本不存在需要设计的循环。2026年的用例若没有循环工程将无法存活。瓶颈位置并未移动，因为实践方式改变了；瓶颈位置移动，因为用例本身发生了变化。

这三种力量协同作用。更优秀的模型减轻了下层压力；更长的窗口将压力从装入转向筛选；更长的流程新增了此前不存在的层级。最终形成技术演进的命名序列。这与其说是技术演进，不如说是一系列生产中最关键痛点的演变。

4. 每一层实际负责的内容

三层架构模型最有价值的场景是明确划分边界。每一层都负责一个核心问题。

第一层 – 提示工程负责模型在单次调用中读取的内容。系统消息、用户消息、模式定义、工具定义、打包进下一次调用的对话历史：所有从"{\"role\": \"system\"}"开始到响应结束的内容。提示工程师需要回答的问题包括：应该分配什么角色？哪些约束能确保输出可靠性？什么模式能修正输出结构？这门学科已趋于成熟且边界清晰。

第二层 – 上下文工程负责调用之间进入和离开模型上下文窗口的内容。Lance Martin的LangChain分类将其划分为四种策略。Write是不随轮次变化的缓存前缀（系统提示、工具定义）。Select是检索与记忆召回：从更大池中挑选当前相关的内容。Compress是摘要、紧凑化和按工具截断：压缩可能溢出的内容。Isolate是将子智能体调用放入独立窗口、使用主上下文外保存状态的记忆工具、以及中间结果永不进入上下文的程序化工具调用。这四种策略相互组合，共同描述了生产环境中上下文工程的完整工作内容。

Layer 3 – 循环工程负责控制下一次调用何时触发、循环何时停止、系统如何恢复以及结果在发布前如何验证。四个控制面包括：触发条件（何种条件触发下一次调用）、终止条件（循环直到完成 vs 循环直到预算耗尽 vs 循环直到资源枯竭）、恢复路径（带退避重试、降级到更大模型、升级给人类处理、跳过当前项并返回已计算结果）和对抗验证（其他代理在答案提交前尝试推翻结论）。

各层之间的界限至关重要，因为每一层都有其专用工具和独特故障模式。糟糕的提示词会引发明显故障：模型输出离题内容。糟糕的上下文工程会引发隐蔽故障：模型输出流畅但错误的内容，因为检索到的上下文本身错误。糟糕的循环工程会引发高成本故障：循环持续处理相同负载，消耗令牌预算，最终超时。这三类故障需要三种不同的调试方法；将它们视为单一黑盒会使所有问题都难以处理。

关于 harness 工程的说明。一些从业者将执行环境单独划分为第四层——harness 工程：模型可调用的工具、防护机制、验证逻辑、跨会话的内存管理。在三层架构框架中，这些关注点并未缺失，而是被分散处理。工具和内存位于上下文工程的隔离策略中；验证和恢复逻辑则属于循环工程范畴。配套宣言文件 M6（面向 RAG 的 harness 工程）采用另一种视角，明确命名 harness 概念，将四个模块视为各自独立的小型 harness（一组方法加上选择和验证的代码）。三层还是四层是视角选择问题，而非系统架构的分歧。

5. 七种循环模式与一条规则

2026 年循环工程目录最终确定了七种命名原语加一条结构规则。Anthropic 的动态工作流（2026 年 5 月发布）命名了其中六种；带退避重试模式更早且更通用。该规则更早，存在于从业者文献中。

区分有用循环与低效循环的七种模式加一条规则 – 图片由作者提供

这些模式不是按顺序执行的步骤序列，而是一个术语库。实际循环通常组合使用其中两到三种模式。将问题分发给三个子代理进行并行处理。通过让反驳代理尝试破坏共识答案来对抗验证。基于完整性条件执行循环直到完成。对瞬时故障执行带退避重试。组合方式体现工程设计；名称则是团队讨论工程设计的术语。

将目录统一在一起的规则更简单且早于这些名称出现。每次重试都必须带来某种改变。在相同故障后重复处理相同负载的循环并未学习，只是在空转。改变可以体现在负载（调度器扩大检索范围）、模型（小模型失败后大模型获得第二次机会）或策略（关键词检索遗漏后第二次使用密集检索）。缺少这些改变的重试是循环工程层最典型的资源浪费。

该规则与目录共同描述了生产级循环的主要行为。这项工程实践的价值不仅在于模式本身，更在于针对具体场景组合使用哪两到三种模式，并确保每次重试都带来实质改变。

6. 瓶颈的下一步发展方向

三层架构框架预示着自身的过时。如果瓶颈随着底层稳定而向上移动，那么在循环工程之上的层将成为下一个被命名的层级。

这些候选层级已经有了非正式名称但尚未达成共识。技能工程（Anthropic 2025 年底推出的 Agent Skills）处理代理在运行时可部署的能力目录。记忆工程处理跨会话持续存在的状态（项目惯例、先前决策、用户偏好）。目标工程处理代理在多次循环迭代中维持的长期目标（Anthropic 的 /goal 命令和 OpenAI 2026 年 5 月 Codex CLI 的等效功能）。工具目录工程处理代理选择为下一阶段工作提供哪些工具的元层级。

目前尚不清楚这些候选中哪个会成为主导的第四层名称。前三个层级的规律表明，答案将是第一个成为生产瓶颈的层级。第三部分提到的三种力量将推动它，就像它们推动前三个层级一样。

对于 2026 年阅读本文的团队来说，一个有用的立场是停止过度关注名称，而是专注于识别瓶颈何时移动。如果大多数生产失败是模型说了与团队瓶颈无关的内容，瓶颈是提示工程。如果大多数失败是模型说了流畅但错误的内容，瓶颈是上下文工程。如果大多数失败是循环四次尝试相同的事情，瓶颈是循环工程。如果大多数失败是代理忘记了昨天达成的共识，瓶颈已从循环工程转移到下一个层级。

7. 通过三层视角看系列文章

这是地图，而且是完整的：系列中的每篇文章都在下方按阅读顺序排列，并标记了其作用的层级。你不需要单独的公告文章就能看到整个计划。这些层级在构建时并非严格按顺序出现（第二部分在提示工程接管生成之前就处理了输入模块的上下文关系）；它们是覆盖在阅读顺序上的视角。已发布的文章附有链接，其余的正在路上。

第一部分：任何单一层级之前的框架

• 1 – 最小 RAG：一个约百行代码的 PDF 输入、高亮答案输出的管道，不使用向量数据库和框架。整个四模块循环的微型版本。

• 2 – 嵌入不是魔法：嵌入检索的可预测失败模式，以及为什么主题相关性不等于问题与答案的关系。

• 2bis – 重排序器也不是魔法：交叉编码器重排序器何时需要额外延迟，以及何时字典方法已经胜出。

• 3 – RAG 不是机器学习：为什么机器学习工具包为检索生成系统解决了错误的问题。

• 4 – 哪种技术适合哪种问题：从正则表达式到视觉模型，将每种 RAG 技术与实际适用的问题进行匹配的网格。

• 4bis – 十个常见 RAG 错误：整个系列其余部分针对的生产失败模式。

第二部分：四个模块

文档解析，选择从 PDF 中提取哪些内容（上下文）：

• 5A – PDF 的两层结构：文本层和结构层，以及为什么 extract_text 会丢弃影响 RAG 质量的一半内容。

• 5B – 关系数据模型：PDF 应该转换为的关系表（行、页面、区块），而不是扁平文本。

超越默认的 PyMuPDF 解析，当页面需要时，brick 会调用更强大的方法，每种方法都能生成相同的输出表格：

• 5bis – Azure Layout：当 PyMuPDF 无法识别表格时，调用 Azure Layout。

• 5ter – Docling：使用 Docling 进行本地解析，适用于复杂表格，无需上传云端。

• 5quater – 视觉 LLM 作为解析器：使用视觉模型读取文本解析器跳过的图表和图示。

• 5quinquies – EasyOCR：对扫描 PDF 进行 OCR，以及为什么免费 OCR 只能提供文字而非完整文档。

• 5sexies – 可搜索图像：在不付费阅读所有内容的情况下，使 PDF 中的图像可搜索。

• 5septies – 重建目录：重建 PDF 忘记携带的目录，以便按章节范围检索。

接下来是两个循环层后续步骤，解析不再是一次固定过程，而是自适应的：

• 5octies – 目录作为循环：将目录重建重新构造成一个从上到下读取文档的循环。

• 5nonies – 代理式解析：让流水线根据每页内容自行选择解析器。

问题解析，搜索前对问题进行结构化（上下文）：

• 6A – 首先解析问题：大多数 RAG 流程中缺失的步骤，检索前对问题进行结构化。

• 6B – 从问题中提取的五个字段：关键词、范围、形状、分解和澄清。

• 6C – 分发解析后的问题：将一个解析后的问题转化为四个路由决策（分块策略、模型层级、碎片、审计）。

• 6bis – 明确模糊问题：一次性澄清模糊问题，然后学习默认值以避免重复询问。

• 6ter – 问题解析的未教课程：教程中跳过的 brick 上的问题解析位置。

然后是两个为该 brick 命名分层的同伴：

• 6quater – 问题解析的上下文工程：将原始问题输入到引导检索和生成的字段中。

• 6quinquies – 问题解析循环：在检索触发前运行的小循环。

检索，过滤而非搜索（上下文）：

• 7A – 检索即过滤：心智模型，将检索视为缩小范围而非搜索索引。

• 7B – 锚点检测：关键词、嵌入和目录信号并行运行，最后通过一次 LLM 调用完成。

• 7C – LLM 裁决者：LLM 选择合适的候选页面并给出理由。

• 7bis – 上下文工程：四种类型输入：明确命名的上下文层，每条答案背后的四种类型输入。

• 7ter – 检索的未教课程：为什么余弦相似度并非其被对待的基础。

• 7quater – 分层检索：通过目录循环读取长文档的循环工程（循环层）。

• 7quinquies – 检索停止幻觉：检索 brick 如何决定模型甚至能发明什么内容。

• 7sexies – 表格行检索：从宽表格中检索正确的行。

生成，提示工程接管：

• 8A – 类型化答案契约：通过拒绝返回自由文本来防止幻觉的模式。

• 8B – 提示组装：将每个生成提示从基础提示和问题所需规则组装而成。

• 8C – 验证答案：在用户看到答案前检查跨度和引用，并通过反馈循环。

然后是循环层后续步骤，当一次生成过程不再足够时：

• 8bis – top-1 与 top-K 生成：何时单次生成过程足够，何时需要多次（循环层）。

• 8ter – 生成模式：类型化生成合约中重复出现的模式。

• 8quater – 模型级联：从廉价本地模型到托管旗舰模型（循环层）的LLM级联。

第三部分：显式循环工程

• 9A – 生产流水线：将四个升级后的模块组装成一条流水线，从关系解析到TOC检索再到类型化答案。

• 9B – 一条流水线处理四份PDF：同一流水线对四份截然不同的文档进行端到端处理。

• 9bis – 检索返回错误页面时：在答案生成前捕获并恢复检索遗漏。

• 9ter – 路由到廉价模型：将简单问题发送至更廉价的模型以降低成本。

• 10A – 升级级联：自适应解析，从廉价起点开始，仅在页面需要时使用更复杂的解析器。

• 10B – 升级操作实例：完整演示升级过程，从平面表格到Azure，从图表到视觉LLM。

• 11 – 交叉引用：直接返回"See Section 7.2"所指向的章节内容本身，而非仅返回指针。

• 12 – 列出问题：当答案需要包含所有匹配段落而非仅最高匹配项时。

• 13 – 工作流调度器：决定何时循环处理、何时终止的调度器。

• 13bis – 流水线的循环工程：为复合调度器流水线明确命名的循环层。

第四部分：语料库

将四个模块从单文档扩展到多文档。在语料库层级，工作仍主要围绕上下文展开，选择哪些文档和章节进入单文档流水线处理前的窗口：

• 14 – 语料库问题（上下文）：为何朴素RAG在真实档案库中失效。从单文档到完整语料库会发生哪些变化。

• 15 – 准备语料库（上下文）：从PDF文件夹到可查询语料库。预先进行索引、类型标注和版本管理。

• 16 – 语料库本体论（上下文）：为何企业RAG需要本体论而非知识图谱。使语料库可查询的类型化标签和关系。

• 17 – 查询语料库（上下文）：查询语料库：先使用SQL过滤，再进行检索。一次性跨多文档提问。

• 17bis – 语料库澄清循环（循环）：在语料库层级澄清问题。将单文档澄清循环提升到语料库层级。

• 17ter – 语料库的上下文工程（上下文）：文档语料库的上下文工程。将上下文层提升到语料库层级。

• 17quater – 语料库的循环工程（循环）：语料库的循环工程。将循环层提升到语料库层级。

第五部分：生产环境

不是第四层而是操作横截面：这些内容运行、衡量并保障三层架构，而非设计单层，因此每层都涉及所有三层：

• 18 – 代码架构：如何按模块逐步构建流水线代码结构。

• 19 – 存储：长格式表格和可重放的工件，包含19bis（模式迁移）和19ter（存储映射）。

• 20 – 评估：按故障模式切片评估而非单一聚合评分。

• 21 – 成本与延迟：随着流水线扩展保持两者平衡。

• 22 – 安全：围绕语料库的访问控制和数据保护。

附加内容

• B01 – 拼写修正：在检索前清理OCR和拼写错误噪声。

• B02 – FAQ作为RAG：将现有FAQ视为检索语料库。

• B03 – 有依据的"I don't know"：拒绝回答并附上拒绝依据。

• B04 – PDF中的表格：表格解析的深度解析。

• B05 – 选择模型：在每个模块中应选择哪种模型。

• B06 – 分发架构：完整实现调度器模式。

• B07 – 保真模拟：使用行为与真实调用一致的模拟器测试流水线。

• B08 – CV 解析器基准测试：在真实简历上对解析器进行基准测试。

• B10-B12 – 本地运行：使用 Ollama 的本地大语言模型、本地嵌入向量及本地模型基准测试。

姊妹宣言

• M1 – 放大专家：贯穿整个系列的核心理念，系统增强专家判断而非取代。

• M3 – 未传授的教训：逐篇解析系列中每个原始立场。

• M4 – 十个立场：系列与主流 RAG 教程决裂的十个关键点。

• M5 – 记忆超越与数量超越：机器学习不超越专家的思维能力，而是超越其记忆广度和数据量。

• M6 – 为 RAG 赋能工程：从另一视角审视系统，四个模块作为赋能工具（方法集合加选择与验证），模型作为框架中的单次调用。

术语有助于团队协作；不要让术语沦为检查清单。说"我们需要在此处添加对抗性验证"的团队，比说"有时答案感觉不太确定"的团队进行着更有成效的讨论。当术语能促使讨论深化时，它们的价值就得到了体现；当术语沦为形式主义的勾选项时，它们的价值就消失了。最糟糕的循环工程由那些机械套用扇出、锦标赛和对抗验证模式的团队制造，优秀的团队会根据具体场景选择两到三个适用模式，忽略其余模式。

8. 结论

提示、上下文、循环：这三个工程层级构成一次大语言模型调用，也是本系列所有文章的分析框架。第7节是路线图；后续每篇文章都对应这三个层级之一，明确对应层级能让你清楚了解当前实际工作内容。唯一需要注意的是整洁的演进故事。这三个层级自大语言模型时代开始就已存在，名称则是按顺序三年间逐步确立的，每个层级依次成为生产瓶颈。更优秀的模型消除了提示工程中大部分困难；更长的上下文窗口改变了上下文工程的形态；更长的运行周期催生了此前不存在的循环工程层级。因此这个框架同时包含两层含义：一种持久的工作组织方式，以及2026年瓶颈位置的快照。第四个层级将在其瓶颈出现时获得命名。

团队的务实做法是将三层框架视作调试指南。当模型输出异常时，检查提示；当模型输出流畅但错误时，检查上下文；当循环无法终止时，检查终止条件；当代理在会话间遗忘信息时，说明瓶颈已超越循环层级。术语有助于定位问题，但更关键的是诚实地判断当前周二下午瓶颈具体出现在哪个层级。

• 《构建 Claude Code 的 Anthropic 首席工程师表示他已放弃提示工程：现在他只编写循环》，The New Stack。Boris Cherny 的逐字引用将循环工程带入开发者视野。

谱系。

• 《从 ReAct 到循环工程：2026 指南》，Data Science Dojo。ReAct（2022 年 10 月）→ AutoGPT（2023 年 3 月）→ Reflexion（NeurIPS 2023）→ Plan-and-Execute → OODA → Ralph Loop（Huntley，2025 年 7 月）→ /goal（Claude Code，2026 年 5 月）→ Dynamic Workflows（2026 年 5 月 28 日）的历史演进路径。

• 《面向知识密集型 NLP 任务的检索增强生成》，Lewis 等人，NeurIPS 2020（arXiv:2005.11401）。原始 RAG 论文。比“上下文工程”这一名称的提出早五年。

• 《ReAct：在语言模型中协同推理与行动》，Yao 等人，2022 年 10 月（arXiv:2210.03629）。经典的推理加行动循环。比“循环工程”这一名称的提出早三年多。

实践者视角。

• 《代理循环的解剖》，Steve Kinney。四种协调模式（流水线、管理者、交接、扇出）和六种失败模式。对循环层的清晰极简视角。

• 《循环工程》，Cobus Greyling。六模块框架（调度、工作树、技能、插件、子代理验证器、持久化记忆）。对三控框架的有用补充。

• 《我不再提示 Claude。我现在编写提示 Claude 的循环。》，James Fahey，Medium（2026 年 6 月）。完整保留 Cherny 的逐字引用，并附带生产级循环的成熟度检查表。

系列中的配套文章（全部映射在第 7 节）：第 7bis 篇聚焦单文档范围的上下文工程，第 13bis 篇聚焦单文档范围的循环工程，第 17ter 和 17quater 篇则将两者扩展至语料库范围。这对组合在系列后续工作中于每个新范围重复出现：针对文档意图、工具目录和代理案例，分别配套上下文工程和循环工程内容。无论在哪个范围，将两者并列阅读，是最快感知二者边界的途径。

作者信息

查看 angela shi 的所有文章

人工智能工程

,

深度解析

大语言模型

RAG

RAG 架构

分享本文

• 在 Facebook 上分享

• 在 LinkedIn 上分享

• 在 X 上分享

Towards Data Science 是社区出版物。提交你的见解以触达全球受众，并通过 TDS 作者支付计划获得收益。

更新为你的实际投稿链接

为 TDS 撰写文章

✦ 结束 CTA ✦