ARTICLE · 1272366
第五回:给AI接了知识库,为什么反而引用错了文件?
AI江湖那些事儿
第五回：给AI接了知识库，为什么反而引用错了文件？
RAG技术进化史：从机器搜索知识，到企业拥有自己的AI知识系统
技术史·从专业方法到外部知识｜第五篇
一、腾讯ima能读懂你的资料，AI为什么还需要重新学习知识？
这几年，AI产品发生了一个很有意思的变化。
早期使用ChatGPT时，我们习惯直接向模型提问。
比如：“帮我解释一下虚拟电厂的发展趋势。”
模型会根据训练形成的知识进行回答，可能很流畅，也可能缺少最新政策和具体依据。
如果我们换一种方式，把收集的政策、论文、行业报告和历史研究资料放进腾讯ima这样的知识库产品，再提出相同问题，体验就不同了。
它可以围绕这些资料回答问题，引用相关来源，帮助用户整理和撰写内容。
更重要的是，这些资料不必全部重新训练进大模型。
腾讯ima的公开产品资料显示，它以知识库为核心，支持导入文件、网页、公众号文章、图片和音频等内容，提供知识检索、问答溯源和内容创作等能力。后续还引入了知识Agent和Skill相关功能。
对普通用户来说，这带来一种很直接的感受：过去是自己到处找资料，再拿着资料问AI。现在可以先把资料积累起来，再让AI围绕这些资料工作。
但这里很容易产生一个误解。
AI能够查询自己的知识库，并不意味着它真正理解了知识库里全部内容，更不意味着它一定使用了正确的依据。
例如，上回我们介绍的投标审核Skill，知道应该先检查招标文件和正式澄清。
假设知识库里有两份材料。原公告写着截止时间为6月18日。正式澄清将同一事项调整为6月20日。
用户问：“当前有效的截止时间是什么？”
如果知识库系统只找回原公告，AI就可能非常认真地回答“6月18日”，甚至附上一条真实引用。
问题不在于原公告是假的，而在于它没有找到，或者没有正确采用后来的有效修改依据。
这便是本回真正要研究的技术问题：
AI究竟怎样从外部知识中找到有用信息？为什么检索到了真实资料，仍可能生成错误答案？
这个问题涉及一项已经走出实验室、进入大量实际产品的技术路线。
它叫RAG，Retrieval-Augmented Generation，检索增强生成。
二、RAG的技术起点：大模型的参数并不是一座能够随时更新的图书馆
大语言模型经过预训练，获得了丰富的语言能力和一定的世界知识。
但训练形成的知识分布在模型参数中，并不是按照一份份文档逐条保存。模型无法像查询数据库一样，直接从参数中定位某份文件的具体页码。
更重要的是，模型完成训练以后，外部世界仍在变化。新的政策发布，企业制度修订，客户资料更新，项目形成新的会议纪要。
如果每次知识发生变化，都要重新训练模型，成本和维护难度都非常高。
因此，AI研究长期存在一个问题：
能否保留模型已经获得的通用理解能力，同时让它在回答时读取外部可更新的知识？
这个想法并不是2020年才出现。
早在大语言模型普及之前，信息检索领域就已经研究如何从大量文件中寻找与问题相关的内容。
BM25等经典方法，主要根据词项匹配及统计特征对文档进行排序。
例如，用户查询“投标截止日期”，搜索系统可以寻找包含相关词项的文件。
但传统词项匹配存在局限。用户说“最晚递交时间”，文件写“投标文件提交截止时点”，两者词语不同，含义却可能十分接近。
神经检索研究试图通过向量表示解决这类问题。
2020年出现了几个重要节点。
这里必须区分技术原型与今天的产品实现。
Patrick Lewis等人在2020年提出的RAG，包含检索器和生成器的联合建模思想，研究不同检索文档对生成答案的概率贡献。
而今天许多企业知识库采用的是另一种常见工程形式：先用现成检索组件找到相关资料，再将资料放入大模型上下文，让模型生成回答。
这两种方式遵循相近思想，但不是完全相同的算法实现。
它们共同完成的转变是：
模型不必把所有知识永久储存在参数中，可以在执行任务时访问外部知识。
这就是RAG最重要的技术意义。
三、RAG到底怎样工作？实际上存在两条不同的处理流程
理解RAG，首先要把“建立知识库”和“查询知识库”分开。这两件事经常被放在同一张流程图里，但它们处理的问题不同。
第一条是知识入库流程。
原始资料 ↓PDF / Word / 网页 / 图片解析 ↓提取标题、正文、表格和来源信息 ↓切块（Chunking） ↓计算文本向量（Embedding） ↓建立关键词及向量索引 ↓形成可检索知识库为什么不直接把整份文件交给模型？
因为企业可能拥有几十万份文件，每次查询都让模型从头阅读，不现实，也不经济。
切块能够将长文件拆成相对独立的检索单元。例如，一份几十页的政策文件，可能被切成许多包含具体条款的片段。系统可以只取与当前问题相关的部分。
但是，切块有代价。
假设原文写着：“本次澄清将投标截止时间调整为6月20日。此前规定与本通知不一致的，以本通知为准。”
如果机械切块，把修改日期与优先适用说明拆散，就可能丢失关键语境。
所以，成熟的知识库不能只保存一段文本，还需要保留文档标题、来源、版本、页码以及必要的上下文。
第二条是用户查询流程。
用户问题 ↓查询理解与改写 ↓关键词、向量或混合检索 ↓获得候选证据 ↓重排及业务条件过滤 ↓组织模型上下文 ↓LLM生成答案 ↓引用与事实核验这条链中，每个环节都可能单独出错。
入库时表格解析错误，后面的模型可能永远拿不到正确数据。检索时没有召回正式澄清，生成模型就缺少关键依据。即使检索正确，模型仍可能错误解释文件之间的关系。
因此，一项重要的技术认识是：
RAG不是“一个向量数据库加一个大模型”，而是一条从原始资料到最终可信回答的知识处理链。
四、为什么向量检索能够理解相似意思，却不能保证事实正确？
这是RAG最核心、也最容易被误解的技术机制之一。
神经检索通常先把用户问题和文档片段变成向量。
假设问题向量为：
(q=(1,0))
两份资料的向量分别为：
(a=(0.96,0.28))
(b=(0.80,0.60))
这些是为了教学构造的二维单位向量示例。
如果采用点积作为相似度：
[ q\cdot a=0.96 ]
[ q\cdot b=0.80 ]
系统可能优先选择a。
但假设a是原招标公告，b是后续正式澄清，那么a的向量相似度更高，并不代表a更适合作为当前有效规定的依据。
为什么会发生这种情况？
因为向量模型通常通过大量问题与文本配对样本，学习怎样识别语义相关性。它学习的是：哪些文字更可能与用户的问题有关。
而不是天然学习：哪份政策具有法律效力；哪项规定已被废止；哪个客户有权查阅某份资料。
更不能把0.96这样的向量相似分数，直接解释成“答案96%正确”。
因此，现代RAG不断引入新的检索机制。
混合检索（Hybrid Search）把关键词检索与语义检索组合起来。精确项目编号、设备型号和条款号可以依靠词项匹配；不同措辞的语义内容则可以通过向量检索补充。
重排（Reranking）在初步召回候选后，利用更精细的模型判断问题与文档之间的相关性。例如Cross-Encoder可以让问题与候选段落共同进入模型，计算更加细致的匹配分数。
上下文恢复则尝试在切块时保留片段所处的文档背景。
2024年，Anthropic介绍的Contextual Retrieval就尝试为文档片段补充上下文，再建立检索索引。在其公布的特定实验中，这种处理显著降低了检索失败率。
但这些技术仍然主要改善“找得准不准”。它们不会自动解决所有专业判断。
尤其对于合同、制度和政策，文件的时间、效力、发布主体以及修改关系，需要另外的业务规则和元数据治理。
这也解释了RAG为什么不能只依赖Embedding模型不断升级。
五、从2020到2026年，RAG真正发生了哪些技术变化？
如果按照技术责任来看，RAG的演进大致可以分成四个阶段。
第一阶段：让外部知识参与生成。
代表研究是REALM、RAG和FiD。核心问题是模型怎样利用外部检索记忆，以及怎样融合多个检索片段。
第二阶段：让知识检索更加准确、完整。
关键词与向量混合检索、重排、长文档结构解析、上下文补全等方法逐渐受到重视。
例如RAPTOR研究利用聚类和摘要建立层次化检索结构，使系统能够根据问题访问不同抽象层级的信息。这主要解决普通短段落检索不易捕捉全局信息的问题。
第三阶段：让系统判断是否应该检索，以及检索结果是否值得相信。
2024年的Self-RAG通过训练模型生成检索与评价相关的特殊Token，研究何时检索、怎样评价证据和生成内容。
CRAG则研究如何判断检索质量，以及在检索结果不足时触发纠错。这些工作让检索不再只是固定执行一次的前置动作。
第四阶段：让检索与推理反复协作。
到了2025—2026年，Search-R1、RAG-R1等研究，以及Azure AI Search中的Agentic Retrieval工程实践，都开始探索更复杂的查询规划和多轮检索。
例如，用户问：“近三年的新能源政策变化，可能形成哪些新的项目机会？”
系统未必能通过一个关键词直接取得答案。
它可能需要把问题拆成：政策有哪些变化？涉及哪些经营主体？这些主体有哪些现实业务需求？哪些需求已经存在对应项目或产品？再将多次检索结果组织起来。
微软Azure AI Search的Agentic Retrieval公开文档中，就介绍了使用语言模型进行查询拆解，并行执行子查询、语义重排和结果合成的机制。
不过，其中部分查询规划和答案合成能力仍有预览状态要求，不能简单当作所有生产环境已经成熟的统一标准。
这一阶段最重要的变化是：
知识检索开始从一次性的资料查找，走向可以根据任务需要进行规划、反馈和多步查询的系统能力。
但技术越复杂，也越需要验证收益。
对于一个简单的制度条款查询，一次准确的检索可能比多轮Agent搜索更加经济、可靠。
六、从技术到产品：为什么腾讯ima、NotebookLM等工具开始受到关注？
如果前面讲的是研究和算法，那么这里可以看看这些技术怎样进入普通人的工作。
今天的AI知识产品并不完全相同。
有些面向个人知识整理，有些强调围绕指定资料进行研究，有些为开发者提供完整的RAG引擎，还有一些直接嵌入企业协同软件与权限体系。
它们的共同价值，是把原来需要使用者自己完成的文档整理、检索和阅读工作，转化为自然语言交互。
腾讯ima：从个人资料收藏，走向可问答、可协作的知识资产。
腾讯ima的产品特色，是围绕个人和共享知识库组织工作学习资料。
例如，一位研究人员平时看到大量公众号文章、PDF报告、行业政策和研究论文。过去，这些内容可能散落在浏览器收藏夹、微信聊天和电脑文件夹里。
通过ima，可以把相应资料导入知识库，后续使用自然语言搜索、阅读和整合资料，并回溯引用来源。
2026年的腾讯公开资料还介绍了ima copilot和Skill扩展能力，意味着产品体验开始从知识问答延伸到结合知识完成任务。
但要注意，公开产品介绍并没有完整披露其每个查询场景所使用的切块算法、Embedding、重排模型及内部执行策略。
因此，我们能够确认的是它具有相应的知识管理与问答能力，不能据此推断其内部一定使用了某一种具体RAG算法。
适用场景包括个人研究资料库、课程学习、公众号素材整理和小团队共享资料。
它解决的核心问题是：资料原来分散、难找、难复用，现在可以围绕知识库进行持续工作。
产品入口：腾讯ima
Google NotebookLM：围绕指定来源开展研究，强调可回溯引用。
NotebookLM提供了一种略有不同的体验。
用户先为一个研究主题建立笔记本，加入PDF、网页、文档、视频等来源，再围绕这些来源提问。
例如，准备研究一项AI技术，可以导入原始论文、技术报告和会议材料。
之后询问：“这三份论文对检索与生成的结合，有哪些不同假设？”
系统可以围绕已选择的来源生成回答，并提供对应的引用。它还可以把资料转化为音频概览等便于学习的形式。
但引用并不是正确性的担保。谷歌官方也提醒，NotebookLM依然可能生成不准确内容。
它比较适合边界清晰的研究任务，不应将其与具有完整企业审批、权限和业务操作能力的系统等同。
参考：NotebookLM官方帮助
RAGFlow：把RAG从一个聊天功能，变成可以配置和部署的知识引擎。
RAGFlow是一套开源RAG引擎，更强调文档解析、切块、检索、重排、引用以及与Agent系统的集成。
它适合帮助技术人员理解：为什么建设企业知识库不仅是上传文件，还涉及文档处理、检索配置、运行环境及后续维护。
RAGFlow支持自部署路线，这为需要更强数据环境控制的组织提供了选择。
但自部署并不意味着自动符合全部安全合规要求。企业仍需要设计身份管理、权限、密钥、日志、数据保留和模型服务的安全措施。
参考：RAGFlow官方文档
Microsoft 365 Copilot：企业知识问答为什么离不开原有权限体系。
Microsoft 365 Copilot的价值，不只是能够阅读Word和邮件。
更重要的是，它能够结合Microsoft Graph及组织已有的工作数据，在身份和权限约束下生成与当前用户有关的回答。
例如，市场部门员工查询客户项目资料，与财务部门员工查询同一项目，不应天然获得完全相同的敏感内容。
微软官方架构文档强调，Copilot对组织数据的访问应遵守用户原有权限。
这一点对于企业知识库尤其重要。因为企业不能把所有员工的资料复制进一个向全员开放的向量库，然后仅靠提示词要求AI“注意保密”。
参考：Microsoft 365 Copilot架构
这几类产品放在一起，我们可以看出一条非常清晰的技术演化路径：
知识库正在从“存放文件的地方”，变成“AI获取外部知识和执行专业任务的基础能力”。
但个人知识产品、企业协同产品和自部署RAG引擎解决的问题并不完全相同。企业选择时，应先判断要解决哪一类问题，而不是简单比较谁的聊天界面更聪明。
七、RAG为什么特别适合企业？因为企业的知识问题具有共性
企业为什么需要自己的AI知识库？
原因并不是每家企业都想训练一个专属大模型。恰恰相反，很多企业没有必要重新训练一套基础模型。
因为其工作中的大量差异，并不来自语言理解能力，而来自企业自己的知识和业务资料。
例如：客户服务部门有产品说明、服务规范和历史工单；人力资源部门有制度、流程和员工服务指南；技术部门有产品手册、故障案例和运维文档；经营部门有客户资料、经营报告和项目历史。
这些资料不断变化，却大多具备可读取、可检索、可追溯的文件形式。
RAG的优势就在这里。它可以让企业使用已有的大语言模型，同时建设自己的知识获取系统。
不过，企业能够使用RAG，不代表所有企业都应当采用同一种RAG方案。
成熟的企业知识系统通常需要六方面能力。
这里有一个容易被忽视的问题：
RAG不只是AI工程，也是企业知识治理工程。
如果企业原有的文档管理就很混乱，正式版本和历史草稿混在一起，权限不清晰，业务资料也没有责任人，那么RAG可能只是让员工更快地找到这些混乱资料。
它不能自动把错误的制度变成正确制度，也不能自动判断一份没有正式发布的内部讨论稿是否具有管理效力。
特别是权限问题，必须在资料检索阶段就加以控制。
如果检索器已经把无权访问的敏感资料放进模型上下文，再在提示词里要求“不准泄露”，并不是可靠的权限隔离方法。
微软Azure AI Search的文档级访问控制机制，就介绍了结合用户身份、文档ACL及检索时过滤来限制结果范围的方法，同时也提醒权限元数据需要保持同步。
这说明企业级RAG真正重要的，不只是回答能力，而是能否进入已有的业务治理体系。
八、哪些实际工作适合RAG？不是所有场景都需要复杂知识库
RAG的适用范围很广，但它并不是所有任务的默认答案。
例如，客服人员经常需要查询最新售后政策。如果公司已经有较完整的政策文件，但员工难以快速定位，那么知识检索问答就具有价值。
又如，技术人员处理设备故障，需要跨越多个型号、版本和历史案例寻找处理依据。RAG可以帮助定位相关手册和案例，再由人员结合设备状态判断。
而在咨询研究中，RAG可以帮助研究人员从大量政策、历史报告和研究资料中找到有依据的材料，减少重复检索。
我们可以区分几类典型场景。
但如果任务仅仅是计算财务指标，且指标数据已经存放在结构化数据库中，那么使用受控SQL或指标API通常更合适。
如果任务是执行严格的多级审批，那么应由确定性Workflow和业务系统管理权限与状态。
RAG更擅长让模型获取大量非结构化、半结构化资料中的相关信息，而不是代替所有计算与业务系统。
它能显著降低人工查找资料的成本，但不能因此宣称任何采用RAG的业务都能自动提升固定比例的效率。真正的收益应当通过具体任务测试得到。
九、知识库与Skill怎样配合？这才是企业AI真正值得沉淀的能力
现在，终于可以把第五回与上一回连接起来。
第四回讲Skill，强调的是专业工作方法。第五回讲RAG，强调的是外部知识和事实依据。
两者的职责不同，却非常适合组合。
最简单的理解是：
知识库告诉AI可以依据什么，Skill告诉AI应该怎样运用这些依据完成工作。
但要讲清楚两者怎样结合，我们不妨换一个更有代表性的业务任务。
例如：“根据近期能源政策变化，分析哪些政策任务可能形成新的业务机会，并给出重点客户和项目建议。”
如果只有知识库，AI可能找到一批能源政策、行业报告和已有项目材料。它能够摘要，列出主要观点。但这未必是一份合格的商机研究成果。
因为真正的商机分析，需要解决一条更长的判断链。
政策要求了什么？政策作用于哪些经营主体？哪些主体可能产生新的业务需求？这些需求是否已经有成熟产品或项目能够承接？哪些判断有证据，哪些还只是经营假设？下一步应该找谁验证？
这些就是专业工作方法。它们适合整理成一个Skill。
例如：
policy-opportunity/│├── SKILL.md│├── references/│ └── 商机分析判断规则.md│├── scripts/│ └── 政策信息整理.py│└── assets/ └── 项目机会卡模板.md其中，SKILL.md并不是存放全部政策原文。它主要规定如何分析。
例如：
任务目标：识别政策驱动的潜在项目机会。步骤：1. 获取当前有效的政策原文。2. 提取政策任务、对象、期限和要求。3. 检索相关客户及历史项目资料。4. 分析可能形成的业务需求。5. 判断现有产品与交付能力。6. 形成经营假设与项目机会卡。证据要求：政策事实必须提供原文出处。经营推断必须与政策事实分层。未经客户验证的需求标记为假设。在实际任务中，Agent读取这套Skill后，就知道应当按照什么步骤工作。但要取得当前政策和客户信息，它还需要调用知识库检索能力。
于是，整个过程变成：
用户提出商机研究任务 ↓Agent识别并加载商机发现Skill ↓Skill规定研究方法和证据要求 ↓调用RAG或其他检索工具获取政策、案例、客户与历史项目信息 ↓核验来源、版本、适用对象 ↓模型按照Skill方法开展分析 ↓必要时调用脚本整理字段 ↓填写项目机会卡模板 ↓检验证据、推断和假设是否分层 ↓专业人员复核并形成下一步行动这条链里各部分承担不同责任。
RAG检索资料。Skill组织判断方法。脚本处理可重复计算或结构化工作。模板统一成果格式。Agent协调这些动作。模型处理语言分析与推理。专业人员负责需要业务经验和组织授权的最终判断。
它们可以相互配合，但不能互相代替。
尤其要避免两种误用。
一种是把整套政策知识全部塞进Skill正文，让Skill越来越庞大，且很快过时。
另一种是把所有经验文件都上传到知识库，就期待模型自动掌握成熟的政策商机分析方法。
前者混淆了方法与知识，后者混淆了资料与专业能力。
更合理的做法是：
相对稳定的工作程序沉淀成Skill，频繁变化的事实和业务资料由知识库维护，确定性操作通过脚本或工具执行。
不过，这只是一个可行的系统组织模式，并不意味着每个知识库产品都能自动读取标准SKILL.md。
如果某个平台支持Agent Skills或等效机制，可以直接利用其能力。如果只提供问答API，也可以由外部Agent加载Skill，再通过该API调用知识库。
例如，OpenAI关于Skills的开发者文档就明确把Skill定位为可复用的工作流程，而MCP服务器提供受控的信息与动作接口。
腾讯ima在2026年也已经公布知识Agent与Skill扩展相关功能，体现了知识与方法逐渐结合的产品方向。
但产品层面的Skill生态，与开放Agent Skills文件规范是否完全兼容，仍应以具体产品版本和技术文档为准。
十、Skill加知识库，是不是就能形成真正的企业专家？
答案仍然不能简单说是。
因为企业专家拥有的不只是知识和流程，还有对业务环境、风险、责任和例外情况的判断能力。
假设我们已经把政策商机分析流程整理成Skill，又把近三年的政策文件放进RAG知识库。
系统也能够形成一份看上去完整的机会卡。这是否意味着它已经具备专业咨询顾问的能力？
未必。
它可能把一份征求意见稿当成正式政策。也可能把某个行业的发展趋势，推断成某家客户已经具备采购意向。还可能找到相似的历史项目，却忽略客户组织、预算、项目周期和实施条件已经变化。
如果Skill要求“每条机会都必须给出证据”，模型也可能只是在报告后面机械附上一条引用。
引用存在，不代表真正支持经营判断。
因此，要评价Skill与RAG的组合，至少需要三层测试。
第一层：知识是否准确。
是否找到正确政策？是否存在过期版本？引用是否真实？
第二层：方法是否执行。
是否按照Skill规定完成政策任务提取、目标客户分析、已有能力匹配和假设验证？
第三层：业务结果是否有价值。
形成的机会卡是否具有可行动性？是否减少专家返工？是否帮助发现值得验证的项目机会？
这三层不能混为一谈。
RAG召回率很高，不代表经营判断就正确。Skill触发率很高，也不代表客户一定存在相应需求。即使一份报告通过了模板检查，也不意味着业务机会已经成立。
所以，企业真正需要的，不是简单统计建设了多少知识库、安装了多少Skill。
而是建立一个能够持续运行的闭环：
资料更新、方法复用、结果验证、专家纠错、知识与Skill迭代。
在这样的系统中，知识库与Skill才可能从两个孤立功能，进一步形成组织的专业能力资产。
十一、RAG发展到今天，最重要的优势和局限到底是什么？
回顾这项技术的发展，我们可以作出一个相对清晰的判断。
RAG的优势并不在于大模型突然获得了无限记忆。
而在于将知识从模型参数中部分解耦出来，让知识能够独立更新、检索、追溯和治理。
对于企业而言，这尤其重要。因为企业有大量自己的、不断变化的资料，这些资料并不适合全部通过基础模型训练来解决。
但RAG也存在无法回避的局限。
检索存在遗漏。 正确资料可能存在，却没有被召回。
文档结构可能丢失。 切块、OCR和表格解析可能破坏原始语境。
相关性不等于有效性。 向量相似度高，不代表文件适用于当前业务。
模型不一定正确使用证据。 检索正确以后，仍可能发生误读、错误引用与无依据推断。
知识质量依赖治理。 错误、重复、过时和权限混乱的原始资料，不会因为进入知识库就变得可信。
复杂检索也存在成本。 多轮搜索、重排、长上下文处理和模型评价，都会增加计算开销与延迟。
因此，RAG不是一项已经彻底解决的技术。
从2020年的检索增强生成，到2024年的Self-RAG、CRAG，再到2025—2026年的检索增强推理，研究人员一直在解决检索什么时候发生、怎样提高相关性、如何利用证据以及如何验证生成结果等问题。
而企业级实践又进一步增加了身份权限、知识更新、运营成本和业务责任等要求。
真正成熟的RAG系统，不应该只追求“回答得更像专家”。
它应当让知识具有可信的来源、明确的适用边界，并能在实际任务中被正确使用。
十二、从拥有知识库，到让组织真正拥有可复用的知识能力
到这里，我们已经能够把前面几回的技术联系起来。
第一回，大模型通过训练获得通用语言能力。
第二回，MCP等技术让AI能够连接外部工具。
第三回，ReAct让模型能够根据外部反馈调整行动。
第四回，Skill为Agent提供可复用的专业工作方法。
这一回，RAG让模型能够在执行任务时访问外部知识。
但真正的企业应用，不是把五项技术依次堆起来，而是明确每项技术在解决什么问题。
需要查询资料时，用可靠的知识检索。需要专业分析时，用经过验证的Skill组织工作方法。需要访问实时业务数据时，使用受控API或MCP工具。需要严格流程控制时，采用Workflow和确定性程序。需要对外产生业务结论时，建立证据核验、权限和人工复核机制。
从腾讯ima这样的个人知识产品，到NotebookLM的来源型研究助手，再到RAGFlow和Microsoft 365 Copilot所代表的知识引擎与企业工作场景，我们已经看到外部知识正在成为AI系统的重要组成部分。
但技术成熟真正带来的变化，不只是让人们少搜索几次文件。
更重要的是：
企业开始有机会把过去分散在文档、人员和历史项目中的知识，转化为可以被AI访问、被专业方法利用、被结果验证并持续更新的组织资产。
而这条道路还有一个没有解决的问题。
知识库可以找到文件。Skill可以规定工作方法。
但如果AI不知道某个客户属于哪个集团、某项政策适用于哪些主体、哪个系统承载哪项业务，那么仅靠文本相似度，仍然容易把对象与关系弄错。
这便引出下一项技术研究。
知识已经可以检索，为什么AI还是弄错了业务关系？
下一回，我们从一份份文档走向知识图谱与本体，继续研究机器怎样理解业务对象之间真正的关系。
主要研究资料
RAG技术起源与检索原理
Patrick Lewis等，2020，《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。 Kelvin Guu等，2020，《REALM: Retrieval-Augmented Language Model Pre-Training》。 Vladimir Karpukhin等，2020，《Dense Passage Retrieval for Open-Domain Question Answering》。 Gautier Izacard、Edouard Grave，2021，《Leveraging Passage Retrieval with Generative Models》。
RAG机制改进与发展
Akari Asai等，2024，《Self-RAG》。 Shi-Qi Yan等，2024，《Corrective Retrieval Augmented Generation》。 Parth Sarthi等，2024，《RAPTOR》。 Anthropic，2024，《Introducing Contextual Retrieval》。 Microsoft，《Azure AI Search Agentic Retrieval》。
