企业 RAG 值不值得做：从场景选择到持续治理

假设一名在悉尼工作的员工准备去墨尔本参加行业会议。某企业的差旅制度规定，员工前往墨尔本出差时，普通住宿上限为每晚 250 澳元；大型会议或重大活动导致酒店价格明显上涨时，经直属经理事先批准，上限可以提高到 320 澳元。

规则看似不复杂，实际执行却涉及诸多细节：这场活动是否符合例外条件？员工是否必须在预订前获得批准？邮件批准能否作为报销依据？相关说明又可能分散在内部网站、差旅制度、报销页面和历史通知中。如果员工找到的是旧版本，或者遗漏了特定条件，超出费用可能无法报销。

员工真正需要的不是再得到一份搜索结果，而是直接询问：

我下周去墨尔本参加这场会议，每晚 295 澳元的酒店能否报销？如果可以，我需要怎样获得事先批准，还要保留哪些材料？

如果企业内部有一个 AI 助手，能够找到当前有效的制度，结合出差时间和审批情况解释适用条件，并展示原始依据，这个问题或许可以更快解决。检索增强生成（Retrieval-Augmented Generation，RAG）是实现此类能力的技术方案之一：系统先从企业知识库中检索相关材料，再由大语言模型根据这些材料组织回答。

但技术上能够实现，不等于企业就值得建设一套 RAG 系统。企业还需要判断此类问题出现的频率、现有搜索、人工支持或成熟软件是否已能解决，以及系统带来的收益能否覆盖建设与维护成本。若决定采用 RAG，企业还需处理知识版本、访问权限与回答责任等问题。

因此，企业面临两个连续问题：哪些业务场景值得使用 RAG；确定场景后，又该如何建设并持续治理这套系统？

RAG 如何让大语言模型使用企业知识 #

要判断这类内部助手能否可靠地解决问题，需要先理解大语言模型如何获取知识，以及 RAG 在其中改变了哪个环节。

大语言模型（Large Language Model，LLM）通过学习大量文本中的语言规律，预测在当前上下文中接下来最可能出现的内容。2017 年提出的 Transformer 架构，通过自注意力机制（Self-Attention）处理词语间的关系，成为现代大语言模型的重要技术基础[1]。

这种训练方式让模型具备了较强的语言理解和生成能力，却不能保证回答符合事实。模型在训练过程中吸收了一部分知识，但这些知识分散编码于参数之中。企业很难准确判断某条回答来自哪份材料，也无法通过修改一份制度文件立即更新模型。

对于公开语料中反复出现的通用知识，这种局限并不总是明显。大语言模型通常能够较好地理解、归纳和表达这些知识。但这不意味着模型本身能搜索最新信息；只有接入搜索引擎、数据库或其他工具后，它才具备外部检索能力。

企业内部的专业知识则不同。这些内容通常不会进入公开训练语料，而且具有很强的时效性和情境性。同一业务规则可能因地区、岗位、客户类型或生效时间不同而异。模型即使理解用户问题，也未必清楚当前应使用哪份材料。

检索增强生成（Retrieval-Augmented Generation，RAG）的基本思路，是在生成答案前从外部知识库中寻找相关材料。Lewis 等人在 2020 年提出经典 RAG 架构，让模型在处理知识密集型任务时，同时使用参数中已有的知识和外部检索结果[2]。

一套常见的企业 RAG 系统通常包含五个环节：

1. 解析文档并切分正文、表格和其他内容；
2. 为文本建立索引，记录版本、来源和权限等元数据；
3. 根据用户问题检索候选材料；
4. 筛选并重排证据；
5. 让 LLM 根据证据生成带来源的回答。

这套流程主要解决的是如何为模型找到并组织可引用的知识，但无法单独完成所有与个人状态相关的业务判断。开头的住宿问题还涉及员工身份、出差日期、会议性质和审批状态，这些信息通常存储于身份、差旅、费用和审批系统中。

企业内部助手可以在权限允许的情况下，通过受控接口查询这些系统，并将查询结果与 RAG 找到的制度依据结合起来。RAG 提供政策证据，业务系统提供当前状态，规则引擎执行明确的条件判断；需要组织授权的批准或例外决定，则由正式流程或获得授权人员完成。将文档接入向量数据库，并不会自动获得这些能力。

稠密段落检索（Dense Passage Retrieval，DPR）等研究表明，系统可通过学习问题和段落的稠密表示进行语义检索[3]。这类方法能够发现用词不同、含义接近的内容。例如，员工可能问：“育儿假结束后，我能不能申请每周工作四天？”企业制度使用的却是“灵活工作安排”。检索系统需要识别两种表达之间的关系，但员工是否符合申请条件，仍然取决于个人情况、岗位要求和正式审批。

企业可通过更新知识库调整系统使用的材料，不必在每次制度变化后重新训练模型。系统也可展示引用来源，供用户检查答案依据。

然而，RAG 改变的是模型获取知识的入口，不会自动修复企业知识本身。知识库中的版本冲突、权限边界与解释责任，仍需企业处理。

企业 RAG 的核心矛盾：知识连接与访问控制 #

企业知识通常并非一个已整理完毕、等待模型读取的资料库。制度、项目记录和操作经验可能分散于文档平台、邮件、工单系统及员工个人经验中；不同部门使用不同术语，旧版本未及时下线，责任人与适用范围也未必清晰。

知识越分散，企业越希望能通过 RAG 将其连接起来。但企业知识不能像公共网页一样向所有人开放。员工能够查看哪些材料，取决于身份、岗位、部门、地区和具体业务场景。同一份销售报告中的产品说明可向多数员工开放，但客户名单、合同价格和下一季度收入预测仅能提供给特定角色。

企业把资料接入 RAG 后，数据会沿着一条新的链路流动：

用户身份与问题 → 权限判断 → 企业知识库 → 检索与重排 → 模型服务 → 答案、引用与日志

任何环节处理不当，都可能扩大信息暴露范围。NIST Privacy Framework 强调，组织需要从完整的数据处理过程识别和管理隐私风险[4]。对于 RAG，企业不仅要保护原始文档，也要保护检索结果、模型上下文、生成答案、缓存与使用日志。

因此，企业 RAG 并非简单地将更多文档交给模型，而是在知识可用性与访问控制之间建立动态连接。系统可以扩大知识的可发现范围，但不能扩大用户原有的权限范围。要实现这一点，企业必须同时处理三种边界：

这三种边界共同决定一条回答能否进入真实工作流程。模型找到相关文字只是起点；企业还需确认材料是否适用、用户是否有权查看，以及错误发生后由谁处理。至于企业是否有理由建设这套系统，则取决于使用规模、总成本与预期收益。

常见 RAG 方案的局限性 #

一个 RAG 系统的最终回答至少经历文档处理、检索、筛选与生成环节。每个环节都可能引入错误，而不同错误最终可能表现为同一种结果：系统给出了一个流畅但错误的答案。

RAG 会继承知识库原有的问题 #

企业资料并非都是格式规范的纯文本。许多重要信息存在于 PDF 表格、扫描文件、流程图、附件、脚注及跨页段落中。文档解析程序可能将表头与数值分开，也可能忽略图像中的文字。文本切分过短，条件与结论可能落入不同片段；切分过长，则可能混入大量无关信息。

开篇的差旅问题说明了文档处理可能造成的影响。如果系统把“普通住宿上限为每晚 250 澳元”和“事先获得批准后可以提高至 320 澳元”切分到不同片段中，模型可能只看到普通标准，也可能仅看到例外金额。

即使系统找到完整条款，仍需结合出差日期、活动类型与审批记录，才能判断例外是否适用。结构化切分、表格解析和扫描件识别可以减少信息丢失，但无法替企业判断业务条件。

企业还需控制知识来源、写入权限与版本替代关系，并明确谁有权批准和解释这些材料。RAG 可以检索知识，但无法自行判断组织中的知识权威；知识库中的混乱不会因接入大语言模型而消失，模型反而可能将相互冲突的材料组织成一个看似完整的答案。

检索相似内容不等于找到适用依据 #

用户的表达可能含糊、口语化，甚至缺少关键条件。“这个还能报吗”没有说明费用类型、地区、日期或员工身份。系统若仅按语义相似度检索，可能找到内容接近但不适用的规定。

企业检索需同时考虑关键词与向量相似度、文档权威等级、有效期、适用地区与用户权限。条件不足时，系统还应提出澄清问题，而非自行补全业务条件。

将更多文档交给模型也无法代替这种判断。Liu 等人的研究发现，相关信息在长上下文中的位置可能影响模型表现；当关键信息位于输入中部时，部分模型的利用效果会下降，这种现象通常被称为“迷失在中间”（Lost in the Middle）[5]。更多上下文还会增加延迟及推理成本。

因此，企业检索不能仅判断哪段文字最相似，还要判断哪份材料适用于当前用户、时间与场景。长上下文扩大了模型处理信息的空间，但无法替代文档筛选、重排和证据组织。

回答流畅不等于系统可靠 #

模型可能错误综合多份材料，引用存在也不代表引用真正支持答案。仅检查最终回答，仍无法判断错误来自检索、证据筛选还是生成过程。

RAGAS 等框架尝试分别衡量上下文相关性、回答相关性和忠实度[6]。此类自动评估可帮助团队比较系统版本，但无法取代业务专家的判断。

企业仍需建立覆盖制度冲突、权限差异、模糊提问、时间变化与材料缺失的真实问题集，分别评估检索、证据、回答、引用和拒答。高风险问题还需人工评审或明确的转交渠道。

这些失败说明，企业不能仅优化模型与检索组件，还需同时治理知识、权限、答案和运行过程。即使企业能控制这些技术风险，仍需判断：此场景是否值得为 RAG 承担长期成本？

有些知识问题并不需要 RAG #

并非所有企业知识问题都需要生成式回答。若文档数量有限、结构清晰且更新不频繁，改进目录、关键词搜索和页面导航可能已足够。若问题发生频率很低，却高度依赖专业判断和具体情境，人工支持可能更经济、也更可靠。

企业需要比较的并非“RAG 能否替代一个员工”，而是不同方案在相同服务质量和风险要求下的总拥有成本。若现有搜索、工作流程、员工支持或成熟软件能以更低成本解决问题，企业应选择更简单的方案。是否需要 RAG 能力，与是否需要自建 RAG 系统，是两个不同的问题。

企业 RAG 的建设方法：从业务问题到持续治理 #

第一步：找到真正值得使用 RAG 的业务 #

企业 RAG 的第一步并非选择模型或向量数据库，而是找到一个高频发生、现有处理成本较高、专业知识可维护和验证的问题。企业随后再比较 RAG、传统搜索、流程改进、人工支持与成熟软件。

开篇的差旅查询确实反映了知识查找问题，但一次查询困难不足以支持一个 RAG 项目。企业还需统计类似问题的发生频率、员工用于查找和确认规定的时间、错误理解造成的返工或争议，并判断差旅平台、内部搜索或人工支持能否以更低成本解决。

对于咨询量有限的小型企业，更新差旅页面或指定行政联系人可能更合理；对于拥有大量跨地区员工、内部规则频繁变化的企业，此类知识服务才可能成为 RAG 的候选场景。

企业在试点前还需记录现有流程的基线，包括员工查找资料所需时间、重复咨询数量、转交专家比例，以及错误信息造成的返工或争议。试点不仅要比较回答准确率，还要观察实际使用率和端到端处理成本，并事先设定继续、调整与停止投入的条件。即使一次回答能节省时间，若系统很少被使用，或者员工需投入更多时间核对结果，也很难形成实际回报。

软件开发是一个典型场景。开发人员经常并非找不到任何文档，而是不知道某个决定记录在哪里。相关知识可能分散于代码仓库、README、API 文档、架构决策记录、Wiki、工单及事故复盘中。他们可能会问：

用户账户服务为什么没有使用公司统一的认证组件？这个设计决定是谁作出的？

若系统能找到当时的设计记录、工单和讨论，RAG 可将分散的证据组织起来；若组织从未记录此决定，系统则应说明证据不足，而非根据当前代码推测历史原因。精确查找函数、调用关系和依赖项时，代码搜索或静态分析通常也比 RAG 更合适。

此场景的优势在于，开发团队既是专业知识的主要使用者，也是知识的生产者与验证者。企业可以衡量找到可核对答案所需时间、重复技术咨询数量、新人熟悉系统时间与故障诊断时间。

客服或联络中心是工程团队之外的另一个例子。客服人员每天需查询产品说明、退换货规则、促销条件、服务故障及问题升级流程。资料可能分散于操作手册、内部公告和产品知识库中，客户的自然语言表达又未必与企业使用的标准术语一致。

RAG 可帮助客服人员定位政策，展示来源与适用条件。产品、运营与知识管理团队负责维护材料，一线员工则通过日常使用发现错误与知识缺口。

企业可同时观察回答准确性、平均处理时间、一次解决率、人工升级比例与错误信息数量，避免为缩短通话时间而牺牲服务质量。系统可以帮助员工查找和解释内部知识，但不应在缺少正式授权的情况下自动批准退款、修改账户或作出其他影响客户权益的决定。

两个场景虽然来自不同部门，却具有相似的判断条件：

确认一个场景适合 RAG 后，企业还需比较采购成熟产品与自行建设。若知识主要集中在一个现有平台中，平台提供的搜索和 AI 能力可能已足够；若企业必须连接多个系统、同步复杂权限、建立领域专用评估，或将知识查询嵌入自己的业务流程，定制建设才可能具有长期价值。

这里的“自建”通常并非从零训练大语言模型，而是由企业自行组合模型服务、数据连接、检索、权限、评估与运营机制。企业需将集成成本、供应商锁定、数据迁移与退出成本一并纳入比较。

让自上而下与自下而上在具体场景中汇合。 #

企业 RAG 可由两个方向同时启动。管理层、平台团队和治理部门自上而下（top-down）确定战略目标、投资边界、公共平台以及数据、安全与审计要求。一线员工和专业团队自下而上（bottom-up）识别高频问题，提供并验证专业知识，同时记录现有工作方式的成本与不足。两条路径最终需在一个边界清晰、能衡量实际价值的业务场景中汇合。

单纯自上而下，项目目标易远离真实工作，系统上线后也可能缺少持续使用者。单纯自下而上，团队虽可能做出有用的原型，但未必拥有正式的数据权限、安全审查、长期预算与知识维护责任。管理层不应通过行政要求为 RAG 制造需求，一线团队也不能将局部原型直接视为生产系统。

双方据此选择小范围场景进行试点，再根据实际使用、回答质量、总拥有成本与新增风险决定扩大、调整或停止，而非因为已提出 AI 战略就继续投入。

第二步：先治理知识，再建立索引 #

进入 RAG 的知识需记录来源、责任人、生效与失效时间、适用地区、业务范围、权威等级、访问级别以及与旧版本的替代关系。

知识负责人负责确认材料是否有效以及如何解释，技术团队负责系统如何解析、索引与检索材料。两者不能相互替代。没有这些基础信息，系统即使找到语义相关的文本，也无法稳定判断其是否为当前问题的有效依据。

企业还需控制知识写入来源，识别未经验证的内容，防范文档中的提示注入指令影响检索与生成，并避免敏感信息在后续链路中泄露[7]。

在软件开发场景中，系统负责人需确认架构决策记录何时更新或失效；在客服场景中，产品或运营团队需明确促销规则由谁发布、活动结束后何时下线。

第三步：把权限带入检索过程 #

系统不能先检索全部材料，再在回答阶段删除敏感内容。访问控制必须在检索前或检索过程中生效，并贯穿上下文组装、缓存、引用与日志。系统不仅要找到正确材料，还要找到当前用户有权使用的正确材料。

这要求系统同时考虑用户身份、角色、部门、地区与业务场景，以及文档和文本片段的访问级别。原文件权限变化后，索引中的权限也要及时同步。

普通开发人员未必有权检索安全架构、生产事故或客户数据记录；客服人员可以查询产品规则，也不应因此获得客户合同价格或内部风险标记的访问权。

第四步：用证据和拒答约束生成 #

系统可使用混合检索和重排，再根据元数据过滤候选材料。问题缺少必要条件时，系统应要求用户澄清；材料相互冲突时，应展示冲突；证据不足时，应拒绝回答。

涉及正式审批、制度例外或个人权益时，系统应转交明确的人类责任主体。如果企业未来使用 RAG 回答开头的住宿问题，系统可以解释 320 澳元上限在何条件下适用，也可在权限允许的情况下查询相关业务系统，确认是否存在审批记录；但它不能在缺少批准时自行认定例外成立，更不能代替直属经理作出批准。系统应说明缺少哪些条件，并将员工引导到相应的审批流程。

评估也需拆分到检索、证据、回答、引用和拒答，而非仅给最终答案一个总分。只有这样，团队才能定位错误，并判断一次模型、索引或提示词调整改善了哪些指标，又是否损害了其他能力。

系统找不到设计决定时，应说明缺少记录；政策未覆盖客户具体情况时，应转交主管。

第五步：把 RAG 当作长期运行的组织系统 #

控制试点后的扩张节奏。 #

试点通过后，企业也不应立即扩大到所有知识领域。每次扩张都要重新检查资料质量、权限复杂度、错误后果与维护责任；一个场景的成功不能自动证明另一个场景也适合 RAG。Jöhnk 等人的访谈研究也表明，组织采用 AI 的准备程度不仅取决于技术资源，还涉及战略、数据、知识、文化和组织承诺[8]。

让员工参与系统建设。 #

项目团队可以与实际员工共同建立问题集，记录当前查找资料所需时间、易出错环节与必须核对的内容。上线后再观察员工是否更快找到正确来源、重复咨询是否减少、哪些问题经常转交人工，以及使用系统后工作流程是否真的更简单。若员工发现核对答案比原来的搜索更费时，他们很快会停止使用系统。

员工不使用系统，未必仅是“不接受新技术”。系统错误频繁、提问记录可能受到监控，或新增操作超过节省的时间，都可能降低员工的使用意愿。Raisch 和 Krakowski 将企业 AI 应用中的自动化与增强视为一种需要持续平衡的关系：AI 既可能替代部分任务，也可能改变人类完成任务的方式[9]。企业需要说明系统能处理什么、记录什么、哪些答案必须核对，以及员工如何报告错误。

明确谁有权解释、谁负责纠错。 #

RAG 开始解释制度后，权威来源、检索排序、提示词与拒答规则都会影响员工看到的答案。算法管理研究指出，算法系统会改变组织中的信息、评价和控制关系[10]。

若企业仅将 RAG 交给技术团队，工程配置就可能承担原本属于业务、HR、法务或管理层的制度判断。责任、权限和资源未对齐时，RAG 会将组织中原有的模糊边界转化为检索排序、提示词和权限配置。

项目支持者（Sponsor）可帮助试点获得初始资源与跨部门协调，但个人支持不能代替长期授权。试点结束后，企业需将临时共识转化为正式机制：谁批准知识进入系统，谁解释冲突规则，谁决定高风险问题能否自动回答，谁负责处理错误与例外。Sponsor 可以让合作开始，记录、责任分配和可交接机制才能让它继续运行。我在《在关系与规则之间：怎样在不完善的组织里做成事》中讨论过这一转换。

一套较为清楚的责任划分可以包括：

把评估和维护变成持续工作。 #

NIST AI Risk Management Framework 使用 Govern、Map、Measure 和 Manage 四项功能组织 AI 风险管理[11]。NIST 后续发布的生成式 AI Profile 又扩展了针对生成式 AI 的相关建议[12]。这些框架不会替企业决定组织结构，却强调治理、场景识别、风险衡量与持续管理需彼此衔接。

制度、权限、模型和供应商都会继续变化。机器学习运维（Machine Learning Operations，MLOps）研究强调数据、模型、部署、监测和跨团队协作的持续过程[13]。RAG 与传统机器学习系统不完全相同，但同样需要版本管理、回归测试、质量监测、故障处理与迁移方案。企业还要衡量调用、维护与知识更新成本，确认系统价值能否覆盖长期投入。

代码、产品和促销规则变化后，相关文档、权限与索引都需要同步更新；否则，一次通过验证的系统也会很快失效。

未来展望：从局部知识工具到组织基础设施 #

对于已证明价值并建立治理基础的企业 RAG，下一步可能不只是回答问题。系统可以进一步比较制度版本、发现知识冲突、提醒负责人更新文档，并在获得明确授权后协助执行业务流程。

当系统从提供答案进一步走向调用工具、查询外部系统和改变业务状态时，它已经开始接近通常所说的智能体系统（agentic systems）[14]。

然而，系统越主动，责任要求也越高。当系统仅提供信息时，用户仍可通过核对材料发现错误；若系统开始发起住宿例外审批、更新记录或执行操作，同样的错误就可能直接影响业务。企业需要更严格的授权、审计与人工批准机制，不能因为系统可以采取行动，就默认它有权采取行动。

第二章中的销售报告例子也说明，权限控制可能需从文档级走向内容和场景级。若系统只能决定用户是否有权打开整份文件，企业就只能在“全部开放”和“全部关闭”之间选择。更细的控制能减少这种两难，也会增加身份、策略、索引同步与审计系统的复杂度。

RAG 的长期价值还可能从知识检索延伸到知识治理。当系统持续记录哪些问题无法回答、哪些文件经常冲突、哪些知识依赖少数员工时，企业可以反过来发现自身的知识缺口。RAG 不仅帮助员工寻找知识，也可能让组织看见知识在哪里失效、由谁掌握，以及哪些流程仍然缺少明确责任。

上述能力仍依赖可靠的权限系统、知识元数据和组织治理。对于使用规模和治理能力有限的企业，采用成熟软件提供的标准化 RAG 能力，可能比自建系统更合理。

结语 #

企业不应先决定部署 RAG，再寻找可接入的文档。它需要从具体问题出发，比较搜索、流程改进、人工支持、成熟软件与自建系统。许多知识问题并不需要 RAG；即使企业需要 RAG 能力，也未必需要自建一套覆盖全公司的系统。

只有当问题具有足够规模、知识可以治理、权限能够控制，且长期收益可能覆盖总成本时，企业才有理由继续建设。对于这些场景，接入向量数据库仅是起点。企业最终建设的并非一个“更会回答问题”的模型，而是一套受到治理、能够追责并可持续运行的知识系统。

同样的判断也适用于智能体系统：企业应先证明业务价值，再明确系统可读取哪些信息、调用哪些工具、执行哪些操作，以及由谁为结果负责。

参考文献 #

[1] Vaswani, A., et al. Attention Is All You Need. Advances in Neural Information Processing Systems, 2017. https://papers.nips.cc/paper_files/paper/2017/hash/3f5ee243547dee91fbd053c1c4a845aa-Abstract.html

[2] Lewis, P., et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 2020. https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html

[3] Karpukhin, V., et al. Dense Passage Retrieval for Open-Domain Question Answering. EMNLP, 2020. https://aclanthology.org/2020.emnlp-main.550/

[4] Boeckl, K., and Lefkovitz, N. NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0. NIST, 2020. https://doi.org/10.6028/NIST.CSWP.01162020

[5] Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 2024. https://aclanthology.org/2024.tacl-1.9/

[6] Es, S., et al. RAGAs: Automated Evaluation of Retrieval Augmented Generation. EACL System Demonstrations, 2024. https://aclanthology.org/2024.eacl-demo.16/

[7] OWASP. Top 10 for LLM Applications 2025. 2024. https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/

[8] Jöhnk, J., Weißert, M., and Wyrtki, K. Ready or Not, AI Comes—An Interview Study of Organizational AI Readiness Factors. Business & Information Systems Engineering, 2021. https://aisel.aisnet.org/bise/vol63/iss1/2/

[9] Raisch, S., and Krakowski, S. Artificial Intelligence and Management: The Automation–Augmentation Paradox. Academy of Management Review, 2021. https://doi.org/10.5465/amr.2018.0072

[10] Kellogg, K. C., Valentine, M. A., and Christin, A. Algorithms at Work: The New Contested Terrain of Control. Academy of Management Annals, 2020. https://doi.org/10.5465/annals.2018.0174

[11] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. https://doi.org/10.6028/NIST.AI.100-1

[12] Autio, C., et al. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, 2024. https://doi.org/10.6028/NIST.AI.600-1

[13] Kreuzberger, D., Kühl, N., and Hirschl, S. Machine Learning Operations (MLOps): Overview, Definition, and Architecture. IEEE Access, 2023. https://doi.org/10.1109/ACCESS.2023.3262138

[14] NIST. Lessons Learned from the Consortium: Tool Use in Agent Systems. 2025. https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems