LLMs之AgenticAI/RAG：从 RAG 到 Context Engineering—知识图谱与语义层如何重塑企业检索—把工具、记忆和数据都纳入检索：面向多模态与治理的下一代 RAG
导读：传统的 RAG 作为填补 LLM 上下文缺口的短期技术已演化为更广泛的“上下文工程”学科——它把检索置于一个包含写入、压缩、隔离与选择的迭代推理循环中，并通过知识图谱与语义层把结构化与非结构化数据、工具、记忆与治理串联起来。要实现可解释、可信且可扩展的 agentic AI，企业应把语义化元数据、复合检索策略、重排序与 policy-as-code 作为核心工程实践，且将检索质量用更丰富的指标来衡量。总体而言，RAG 并非终点，而是向着语义化、可治理与面向 agent 的检索体系演进的起点。RAG 的价值仍在，但需要从“把更多文本丢进上下文窗”转向“精细化管理上下文”。
Context Engineering = 写（记忆） + 压缩（总结/剪枝） + 隔离（分工） + 选择（检索/路由），检索只是其中一环。
>> 背景痛点：
● 上下文窗口限制：LLM 的上下文窗口有限，无法把全部企业数据直接塞入对话，需要在查询时补充相关上下文。
● 规模与噪声问题：在真实企业环境中，从数百到数百万文档检索会引入大量无关或冗余信息，导致结果下降。
● 上下文中毒与混淆：将不相关或矛盾信息加入上下文会导致“context poisoning / context clash”，甚至“context rot”，降低模型准确性。
● 单一检索手段不足：以单次向量检索为核心的传统 RAG 在多模态、工具、记忆等复杂 agentic 工作流中显得力不从心。
● 治理与合规风险：检索时可能违反访问控制、隐私或监管规则，RAG 本身并不自动保证合规与可审计性。
● 评估缺失：仅以最终答案准确率评估不足，缺乏对检索上下文的相关性、来源可追溯性（provenance）、覆盖度和时效性的衡量。
>> 具体的解决方案：
● 知识图谱/GraphRAG：把语义实体与关系建模为图数据库，用实体-关系来驱动检索，提升语义相关性与可解释性。
● 语义层（Semantic Layer）：为结构化与非结构化数据附加统一的可机器与可人读的元数据定义，标准化数据语义与治理策略。
● 上下文工程（Context Engineering）：将检索作为更大推理循环的一部分，围绕“写（write）、压缩（compress）、隔离（isolate）、选择（select）”四类操作来管理上下文。
● 重排序器（Re-rankers）：在初步检索后用专门模型对候选上下文进行排序，决定保留哪些上下文以降低噪声与“上下文混淆”。
● 多检索策略与复合检索：结合向量检索、基于元数据的检索、全文检索、关系检索等多种检索模式，按需复合调用。
● 工具与记忆的元数据管理：把工具、API、agent 记忆等也视为可检索对象，并为其建立元数据与注册表（tool registry / MCP）。
● Policy-as-code 与访问控制：用策略引擎（如 OPA 类）和数据访问控制（行/列级）把治理规则嵌入检索与 agent 工作流。
● 评估框架：构建面向上下文的评估指标（relevance、groundedness、provenance、coverage覆盖度、时效性recency、policy），不只是最终回答准确率，并将这类指标纳入自动化评估工具链。
>> 核心思路步骤（系统性流程/方法）：
● 步骤一，元数据建模与语义化：为企业所有数据（关系表、文档、媒体、工具、记忆）定义统一语义（本体/ontology）、标签和治理规则。
● 步骤二，多模态/多源索引：对不同数据类型建立合适索引（向量索引、关系索引、全文索引、图索引），并支持复合检索。
● 步骤三，初步检索 + 候选集生成：在 agent 需要信息时，从各索引拉取候选上下文（可并行从图、向量、键值、文件系统等取）。
● 步骤四，重排序与筛选（select）：用 re-ranker / 策略器按相关性、政策合规性和时效性筛选候选上下文；必要时执行隔离或分割。
● 步骤五，压缩与摘要（compress）：对候选上下文进行摘要/融合，减少上下文体积，保留关键信息与证据链。
● 步骤六，写入/记忆管理（write）：把任务中产生的关键结果写回记忆或知识图谱，供后续步骤或其他 agent 使用。
● 步骤七，证据与可追溯性（provenance）：在返回结果时附带来源、证据片段与元数据，便于审计与信任建立。
● 步骤八，评估与反馈循环：对每轮检索与生成进行基于上下文指标的评估，反馈到重排序器、索引与语义层以持续优化。
>> 优势：
● 更高的可解释性：知识图谱与语义化元数据使得检索结果能以实体/关系和来源被解释与审计。
● 更可靠的生成（groundedness）：通过筛选与证据追踪，生成内容能提供支撑其结论的上下文片段，降低幻觉。
● 更好的可扩展性与适配性：多索引、多模式与语义层支持从小规模 demo 扩展到企业级、异构数据环境。
● 更强的合规与治理能力：policy-as-code 与基于元数据的访问控制能在检索层面预防违规数据泄露。
● 提升效率与成本控制：通过压缩与选择策略避免无谓地扩大上下文窗，从而控制延迟和成本。
● 支持复杂 agentic 工作流：上下文工程使检索成为 agent 在多步骤推理中的可控工具，而非一次性输入。
>>结论与经验性观点（含建议）：
● 演进脉络：RAG 从“单次向量检索 + prompt 拼接”的简单架构发展为面向 agent 的“上下文工程”学科；其核心是把检索嵌入到一个包含写入、压缩、隔离、选择的迭代推理循环中。
● 语义化与治理必不可少：要在企业级可扩展、可审计地使用检索，必须构建语义层（知识图谱、本体、元数据），并将 policy-as-code 与访问控制嵌入检索/agent 流程。
方法论汇总：采用混合检索策略（向量/图/关系/全文/主键等）、重排序与压缩、隔离并行子任务、工具与记忆元数据化、以及以上下文质量为核心的评估体系。
● 实践建议：分阶段、用例驱动落地；优先在高监管或高价值领域建立可追溯的语义层与评估框架；在工程化层面把治理作为默认能力。分阶段落地——先在关键用例中引入语义层与知识图谱，建立评估与治理，再横向推广至更多用例与数据源。
● 未来要点：检索将变得多模态（文本/图像/音频/地理/视频）、工具化（tool registry/MCP）、并更注重 explainability 与 trust。
● 结论一：RAG 并未死，但“天真的”单次向量检索型 RAG 基本已失效，必须进化为 agentic 的上下文工程。
● 结论二：知识图谱与语义层将成为连接关系型数据与非结构化数据的关键技术，是未来检索的“语义骨干”。语义层/知识图是企业把数据变为可治理、可解释上下文的基石。
● 结论三：检索需演变为迭代式、工具化的流程（写/压缩/隔离/选择），并作为 agent 工具链的一部分被标准化（如 MCP）。
● 结论四：检索评估需要超越“最终答案正确性”，纳入上下文相关性、来源可追溯性、覆盖与时效性等指标。
● 结论五：治理和 policy-as-code 必不可少，尤其在受监管行业（生命科学、金融等），语义技术已被实践证明行之有效。
● 建议一：不要把所有信息都丢进上下文窗口——会产生上下文中毒、混淆和准确率下降。应采用重排序、压缩与分割策略。
● 建议二：企业应把本体、标签、治理策略纳入数据准备环节，将元数据作为一等公民来管理。
● 建议三：构建工具注册表（工具元数据）、记忆可查询化，并使 agent 能按需调用多种检索手段（向量、关系、全文、图）。
● 建议四：采用或开发 RAG/检索专用的评估框架，把上下文质量评估纳入 CI/监控中。
● 建议五：在早期设计时嵌入访问控制与策略引擎，逐步把复杂治理规则编码进 agent 的检索/选择流程。
● 经验要点：结合传统数据库检索（主键、二级索引、地理索引等）与语义/向量检索，会比单纯依赖向量检索更稳健。
>> 推荐的工程路线（分阶段）
A. 快速验证（PoC）：用现有文档做 RAG demo + 基本 re-rank，记录失败用例与 context fails。指定简单评估指标：回答准确率 + 上下文相关性打分。
B. 语义/元数据准备：设计核心本体（关键实体/关系）与元数据字段（来源、时间、敏感度、权限）。对现有数据做轻量标注（provenance、分类、实体映射）。
C. 混合检索架构：构建混合检索层，向量索引（语义） + 文本索引（lexical） + 图查询（实体/关系） + 元数据过滤。在检索返回中附带元数据评分并引入 re-rank。
D. Agent 化与 Context Engineering：设计 agent 的记忆管理（短期/长期），压缩策略（摘要/抽取），并实现 isolate/parallel sub-agents。将检索作为 agent 的可调用工具（注册、带元数据的 API）。
E. 评估与治理：实施端到端评估（包括 groundedness/provenance/coverage/freshness），并把 policy-as-code 嵌入检索/执行路径。Shadow 测试并基于日志持续训练 re-rankers 与策略。
目录
《Is RAG Dead? The Rise of Context Engineering and Semantic Layers for Agentic AI》翻译与解读
3、RAG 的“衰落”与Context Engineering(上下文工程)崛起
3.2、什么是 Context Engineering（写、压缩、隔离、选择）
3.3、Context Engineering Semantic Layer(上下文工程需要语义层)
《Is RAG Dead? The Rise of Context Engineering and Semantic Layers for Agentic AI》翻译与解读
| 地址 | |
| 时间 | 2025年10月28日 |
| 作者 | towardsdatascience |
1. 引言 / TL;DR
RAG（Retrieval-Augmented Generation）曾是企业级生成式AI的关键办法，但单靠向量检索把文本塞进上下文窗并不够。随着代理化（agentic）AI兴起，检索需要可治理、可解释、能动态适配任务目的的“上下文工程（context engineering）”与（semantic layer）支撑，两者结合，以实现更可解释、可控、可扩展的 AI 推理系统。
核心要点
>> RAG 起因：RAG 最初为了解决上下文窗口限制而大受欢迎，但是LLM 的上下文窗口有限，需在查询时补充企业数据以获得相关回答。
>> 单纯向量检索不够：仅用向量检索返回文本片段，往往欠缺可解释性和上下文治理能力，有时也会引入噪声、误导甚至降低效果。
>> 演化方向：检索成为更大推理循环的一部分（写/压缩/隔离/选择），需要元数据、知识图谱、政策治理的支持。
>> 代理化工作流把检索变成工具箱的一部分：检索只是写入/压缩/隔离/选择等一系列步骤之一。语义层和知识图是把企业数据变成“AI 可理解、可治理”的关键中间层。
>> 评估维度扩展：不仅看答案准确性，还要衡量相关性、groundedness、溯源、覆盖度与时效性。
经验与技巧
>> 在战略层面：把 RAG 看作“第一代解决方案”；为长期可扩展性预留语义化与治理架构。
>> 评估时关注既往 demo 成果与现实生产的差异（规模、合规、可解释性）。
>> 短期实践：先用向量检索与简单重排序器构建 Proof-of-Concept，但同步规划知识图谱/语义层的落地路径。在项目前期就规划语义与治理需求（而非等到模型失败后再补
2. RAG 的兴起（The Rise of RAG）
2.1、什么是 RAG？
简述 RAG 的起源（源自 2020 年的研究与 2022 年 ChatGPT 爆红），以及 LangChain、LlamaIndex 等开源工具与向量数据库（Weaviate、Pinecone、Chroma）如何促成其普及。主要工具与变体（如 GraphRAG），并说明知识图谱在 2023–2025 年间重新受到重视与市场兼并整合的原因与趋势。
核心要点
>> RAG 定义：在查询时检索相关片段以扩充 LLM 的 prompt，从而提高回答质量与领域知识覆盖。
>> 快速落地：可以很快在单文档/小规模上做出 RAG demo，但生产化面临规模和治理挑战。
>> 工具生态：LangChain、LlamaIndex 等框架简化了流水线搭建，促进了 RAG 的普及；向量数据库（Weaviate、Pinecone、Chroma）成为标准组件，实现高效语义检索。
>> 企业挑战：大规模文档下检索的可扩展性、互操作与治理成为关键痛点。
经验与技巧
>> 初期验证适合用轻量 RAG demo（验证思路）；但生产化前务必做规模化测试（100→100k 文档的迁移测试）。
>> 选择向量数据库时评估：检索质量、延迟、扩展性、元数据支持与治理能力。
>> 建议在演进路径上分阶段采用：先在关键用例用向量+重排，再引入 GraphRAG 做语义联接。
>> 为企业级落地提前规划元数据与治理（例如数据目录、RBAC 与审计日志），避免 RAG 在生产中带来合规风险。
2.2、GraphRAG 与知识图的复兴
GraphRAG 把知识图/图数据库作为检索底层，使检索基于实体与关系而非纯文本块，从而提升可解释性与结构化推理能力；这一方向引发市场收购与产品整合潮（文中列举多起并购案例，显示市场对知识图的重视）。
核心要点
>> GraphRAG 概念：用知识图（RDF、图数据库）来组织上下文，为 LLM 提供实体关系导向检索。以知识图谱/图数据库作为检索底层，允许基于实体和关系进行推理，增强可解释性。
>> 市场证据：大量并购与工具（微软 GraphRAG 开源、企业并购、平台整合）说明知识图回潮。多起并购与产品发布（如 GraphRAG 框架、数据目录/元数据工具并购）显示知识图谱与元数据管理成为战略资产。
>> 知识图优势：结构化语义、可追溯的来源、利于治理与域建模（ontology/ontology-driven）。
经验与技巧
>> 若业务强依赖实体和关系（金融、生命科学、法规），优先考虑 GraphRAG。
>> 把知识图作为“语义目录”而非全部存储：混合存储策略（图 + 文本索引 + 向量）通常更实用。
>> 在构建知识图时同步设计 provenance（来源）与权限字段，方便上游的政策执行与审计。
>> 设计索引策略时考虑混合架构：向量索引负责语义相似性，图/关系索引负责实体与关系过滤，全文索引用于精确匹配。
3、RAG 的“衰落”与Context Engineering(上下文工程)崛起
3.1、RAG 的局限：衰落还是演化？
文章讨论“朴素 RAG 已死”的说法：并非完全消亡，而是被更复杂、更可控的模式取代。主要问题包括 context poisoning（中毒，错误/误导信息进入上下文）、context clash(混淆)、context rot（上下文随着规模扩大而导致准确率下降）等；为缓解出现了 re-rankers，但 re-rank 也不是终极解。
所以，作者指出传统单次向量检索式 RAG（“朴素 RAG”）在规模化与 agentic 场景下效果下降，产生“上下文中毒/混淆/rot”等问题，推动了向“上下文工程”演进。
核心要点
>> 朴素 RAG 的局限：单次 dense search → 拼接 top-k 文本到 prompt，面对海量文档会带来噪声和不相关信息。
>> 主要失败模式：
Context poisoning / clash：不相关或矛盾信息污染推理链。
Context rot / confusion：过大或不恰当的上下文降低模型表现。
>> 上下文问题分类：context poisoning（错误/误导信息）、context confusion（信息过载导致性能下降）、context rot（随时间或容量造成性能退化）。
>> 解决方向：引入重排序器（用二次模型对检索结果排序，Cohere Rerank、Voyage、Jina、BGE 等），更严格的过滤、GraphRAG 等，以及更系统的上下文管理策略。
>> Agentic 转变：随着 agent（自动化、多步）兴起，检索必须成为可迭代、可组合的工具，而不是“一锤子买卖”。
>> 代价权衡：扩大量上下文能减少某些检索需要，但会显著增加延时和成本，并非万灵药。
经验与技巧
>> 添加质量门：在检索→重排→拼接入 prompt 的环节中添加质量门（例如句级置信度、冗余检测、冲突检测）。
>> 监控“上下文失败”模式：在 CI/监控中记录检索集大小、重排得分、回答的溯源率等指标，用以识别上下文带来的故障。
>> 使用分层检索：先做粗筛（语义/关键词/元数据过滤），再做精筛（re-rank + policy filter），减少无关信息进入模型。使用 re-rankers（Cohere、Voyage、BGE 等）作为第二道把关，但同时记录它们的误判与权重偏好。
>> 做规模化实验以确定“上下文最佳窗口”与“单次检索最大文档数”的经验值；不要盲目增加 k。在测试集中模拟真实规模数据（数万/百万文档），避免只基于小规模 demo 判定方案可行性。
3.2、什么是 Context Engineering（写、压缩、隔离、选择）
将上下文管理艺术化为“Context Engineering”：为Agent 的每一步挑选“恰到好处”的上下文——而不是一次性塞入全部。Lance Martin 把其分解为四类核心操作：Write（写/记忆）、Compress（压缩/摘要）、Isolate（隔离/分工）、Select（选择/检索）。
核心要点
>> Write：Agent在多步骤任务中需要把关键信息写入记忆或知识库， 要能把中间产物或重要信息持久化为“记忆/日志”，以便后续复用（task-to-task）。
>> Compress：对历史上下文做摘要/剪枝，避免上下文体积过大导致性能下降与成本增加。通过摘要、去重、抽象化（抽取要点）把长期累积的上下文压缩，减少噪声。
>> Isolate：按子任务或子问题把上下文分割给不同 agent 或不同模型并行探索，减少“信息串扰”。把复杂问题拆成子问题并在不同 agent/模块间隔离处理，避免信息互相干扰。
>> Select：动态选择哪个记忆/工具/数据应被用于当前步骤（检索只是其中一种选择）。按需检索/调用信息（vector、graph、relational、tool）而非一次性加载全部。
>> 多工具融合：检索只是工具之一，传统数据库查主键、二级索引、地理查找等仍然重要。
经验与技巧
>> 设计 agent 流程时显式建模“上下文生命周期”：什么时候写入、何时压缩、如何隔离、何时调用（select）。设计 agent 时把“记忆层”做成可检索的实体（短期/长期记忆、事件日志），并允许基于任务上下文选择记忆窗口。
>> 压缩策略：可用层次化摘要（句子→段落→主题）与抽取式+生成式混合以保留关键事实并降低 hallucination 风险。采用可追溯的摘要（保留来源标记与关键证据段），避免信息丢失导致可信度下降。
>> 隔离实践：对互相冲突或独立的子任务使用独立环境/上下文（sandbox）并在最后合成结果以降低 context clash。把复杂工作拆成并行子任务，给每个子任务独立的检索/上下文池，最后做汇总与一致性检查。
>> 选择策略：用置信度、过期时间、来源可信度来打分并决定是否纳入当前推理窗口。优先级分层（速度敏感：主键/索引；语义相似：向量；关系推理：图），并在 agent 中实现工具调度逻辑。
3.3、Context Engineering Semantic Layer(上下文工程需要语义层)
语义层定义：为所有数据附加机器/人可读的元数据，使 AI 能一致地理解、检索、推理与治理这些数据。文章指出：只在关系型数据上做语义层不够，必须覆盖非结构化/半结构化数据、工具和记忆，结合图技术与图书情报学方法。
提出语义层为上下文工程的关键基石：以机器/人可读的元数据把企业中结构化、半结构化与非结构化数据连起来，使 Agent 能一致地理解、检索与推理。
核心要点
>> 语义层的职责：将元数据以统一、可读的方式附加到所有数据，使数据语义标准化并支持治理。标准化定义、治理策略、数据发现、可追溯性（provenance），使得Agent 能“理解”数据而非盲目相似匹配。
>> 范围扩大：不能只限于关系型数据，必须覆盖文档、媒体、工具和 agent 的记忆。语义层不仅是关系数据，而应桥接结构化与非结构化：知识图、本体（ontologies）、元数据、分类与映射同等重要。
>> 为什么必须：在复杂企业场景中，要保证检索的相关性、可解释性、合规性、覆盖度与时效性，语义层是关键中枢。
>> 历史先例：图书馆学、信息检索与 SEO 等对非结构化数据组织有长期实践；现代语义层应结合这些方法与知识图谱。
>> 知识图谱角色：作为语义层的“连接组织”：把实体、关系、本体（ontology）连接到检索与推理链路中。
>> 标准与倡议：如 Snowflake 的 Open Semantic Interchange（OSI）等推动元数据标准化（文中提及为背景）。
经验与技巧
>> 语义模型优先做哪些事—建语义层时用“轻量本体+渐进扩展”策略：先定义关键实体/关系与必需治理字段，再逐步覆盖全域。先做关键实体、本体与常用关系（“最小可用本体”），再逐步扩展细化。
>> 将语义层纳入数据目录/数据治理流程：所有数据入库时即附带语义标签与权限策略（policy metadata）。
>> 实现建议：采用混合架构（知识图 + 向量索引 + 元数据存储），并为检索/Agent 暴露统一的检索 API（包括权限检查与 provenance 返回）。
>> 元数据实践：为每个数据源定义描述性元数据（作者、时间、信任等级、用途）、访问策略与更新频率。
>> 与治理结合：把策略（policy）与访问控制（row/column level）在语义层登记，便于 agent 在检索时自动遵守。
>> 跨团队协作：让数据工程、知识管理、业务领域专家共同维护本体与语义层，减少“孤岛本体”。
4、RAG 的未来趋势（多模态、工具/记忆/评估/治理）
文章将未来 RAG 的演进概括为：检索更广（多模态）、检索成为工具注册的一部分（工具元数据、MCP）、知识图谱/语义层作为元数据枢纽、评估从“答案准确率”扩展到“上下文相关性/可溯源/覆盖/新鲜度/政策合规”。
作者对 RAG 的未来给出多个预测：RAG 将更 agentic、检索将走向多模态与多源、工具与记忆将被视为可检索对象、知识图谱将成为重要的元数据层、评估指标与治理规则将日益重要。
核心要点
>> Agentic 化：检索成为 agent 工具之一，检索/写入/压缩/隔离成为迭代式流程（MCP、工具注册表的出现是趋势）
>> 多模态检索：从文本→图像/音频/地理数据/视频的统一检索成为现实。从文本扩展到图像/音频/地理/视频等多种数据类型与检索模式。
>> 工具与记忆作为可检索对象：工具元数据（如何调用、输入输出规范）和记忆也要被索引并纳入决策。Anthropic 的 MCP 是一个示例。工具与记忆元数据：工具注册表（tool registry）、可查询记忆将使 agent 能更灵活地调用能力与历史信息。
>> 知识图谱与元数据管理的重要性：在高监管行业（生命科学、金融）已被验证；将向更多行业扩展。
>> 评估指标与度量演化：出现更复杂的评估维度，包括context relevance(上下文相关性）、groundedness（是否被上下文支撑）、provenance（出处可追溯）、coverage（检索覆盖率）、recency（新鲜度），并用工具链（如 Ragas、Databricks Mosaic、TruLens、LangSmith、Evidently 等）实现评估自动化。
>> 政策与治理：访问控制、脱敏、审计规则嵌入检索与Agent 工作流（OA P、Oso 等策略引擎的应用）。policy-as-code（如 OPA、Oso）和数据平台（Snowflake、Databricks）提供的行/列级访问控制将被嵌入 agent 流程。
经验与技巧
>> 统一：架构上把“工具/记忆/数据/模型”都视作可注册的“资源”，统一做元数据管理与权限治理。
>> 评估体系建设：不仅评估最终答案，更要在检索环节建立自动化指标（溯源率、上下文覆盖度、检索延迟、policy 拒绝率）。为每条检索结果，返回评分元数据（relevance、confidence、source、timestamp），并将这些指标纳入后续 re-ranking 与决策。
>> 多模态准备：为非文本数据建立相应的索引策略（视觉特征、音频指纹、地理索引）并在语义层登记其元数据。
>> 工具治理：为每个可调用工具维护元数据（能力声明、权限、输入/输出约束、费率限制），并在 agent 中实现安全沙箱与授权机制。
>> 行业优先级：在强监管行业优先落地语义层与知识图谱，积累可审计和可解释的实践经验后再向其他部门推广。
>> 政策实现：把合规规则编码成策略模板并挂到检索 API 层，在线或离线都进行策略模拟（shadow testing）。
5、结论：把检索放进更大的推理循环里
作者总结：RAG 只是开始；未来检索必须在代理化、语义化与治理化的大背景下被重新定位——从单次检索到迭代式、上下文感知、策略驱动的“上下文工程”。知识图、元数据管理与政策代码将成为企业可用且可审计 AI 的核心要素。
RAG 从填补上下文窗口的临时手段，正在演化为“上下文工程 + 语义层”驱动的、更大范畴的检索/推理体系。未来检索将更注重解释性、可信度与治理。
核心要点
>> RAG 不是终点：是向语义化、可治理、面向 agent 的检索体系演进的起点。RAG 并非终点，而是向“context engineering”与“agentic retrieval”进化的一步。
>> 企业级应用强调解释性、信任与合规：这需要语义层、知识图与策略引擎的协同。
>> 关键支撑：知识图谱、本体、语义层、policy-as-code、评估指标与工具注册表共同构建可控的 agentic AI。
>> 成功要素：可追溯的证据链、上下文质量评估、分层检索/重排序、压缩与隔离策略、以及治理嵌入。
经验与技巧
>> 对于企业项目，规划路线：PoC（RAG demo）→ 数据/语义建模（本体）→ 混合检索架构（图+向量+原始索引）→ 政策/评估闭环→ 代理化扩展。
>> 分阶段推进：优先小范围用例试点（高价值或高合规场景），在实践中迭代本体、语义层与评估指标。用 shadow mode（影子模式）测试策略/过滤/评估逻辑，避免直接影响生产用户。
>> 建立反馈回路：把评估指标反馈到重排序器、索引调整与元数据模型中，形成持续优化的闭环。
>> 把治理当作产品特性：在设计 agent 时默认开启 policy 检查、审计记录与权限控制，而不是事后补刀。
扫一扫
1162
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
