AI与知识系统

• Pablo 在 Microsoft 的工作是"把 AI 和知识串起来"（他掌管 Azure AI Search / Foundry IQ，自称信息检索狂热爱好者）。他说思考 agent 与知识的关系，自然会逼你反思一个哲学问题："『知道』一件事到底意味着什么？我们究竟如何基于所知把事情做成？" → 详细
• 他把知识分成三类，这是全片骨架：Intrinsic（内生知识）= 模型自带的、用训练数据压进"参数化记忆"里的部分；Extrinsic（外部知识）= 模型之外、需要检索接入的组织数据；Learned（习得知识）= 个人和组织每天干活过程中沉淀出来的经验。三类各对应一套建设思路，后面逐一展开。→ 详细
• 关键论断：内生知识"虽然听起来最显而易见"，但正是它把我们推上今天的指数曲线——GitHub Copilot、ChatGPT 这类开启一切的体验，"很大程度上就是建立在这种内生记忆之上的"。他举了个自己的例子：前后相隔约 25 年写的两段代码，写作过程惊人地相似——都是"坐下来，靠自己已知的或查来的东西，一行行写出来"。写邮件、做文档摘要同理：AI 改变的正是这个"从所知到产出"的过程。→ 详细

• 他用一条时间线展示加速度：1996 年 Microsoft 推出 IntelliSense（不用记函数签名）→ 22 年后才走到下一步（用机器学习给候选项排序）→ 仅 3 年后 GitHub Copilot 发布（关键拐点，且在 ChatGPT 之前）→ 几年后 Cursor、Copilot X → 去年底 Opus 4.5 发布后各家模型编程能力接连快速提升 → 今年初，像 Open Claw 这样"没有一行代码是手写的"极成功软件问世。间隔从 22 年缩到 3 年再缩到按月，"这就是我们身处的指数曲线的形状"。→ 详细

• Microsoft 的 agent 平台：从 GitHub 起步（写代码的地方）+ 上下文化系统（做 grounding，即"用真实资料把 AI 的回答锚定在事实上"）+ Foundry 负责 agent 托管、可观测性与管理，模型目录里有数千个模型按任务挑选。→ 详细
• 演讲前一天刚宣布 Claude 在 Microsoft Foundry 正式 GA——可在 Foundry 统一体验里用 Claude 全部能力，"两全其美"。→ 详细

• 核心因果：厉害的模型能带你起步，但 agent 要"真正参与到一个组织、一家公司正在发生的事情里"，光靠模型内生知识是走不远的——模型不知道你的业务。行业很早意识到这点，于是 RAG（检索增强生成：先检索资料、再让模型带着资料回答）出现了。它"一开始是个技术含量不高的手段"，但很快演化成今天的 context engineering——"一套相当复杂精密的系统，用来把 agent 和它完成工作所需的知识连接起来"。→ 详细
• 复杂化发生在很多维度，他挑两条主线讲：① 数据面：从简单孤立的数据集 → 全公司范围的 grounding；② 技术面：从简单的 vector search → 相当复杂的检索系统。这两条线正好构成后面第 5、6 节。→ 详细
• 客户侧的早期洞察：每个 agent 都有两层知识需求——一层是"你为这个 agent 专门维护的知识"（自己管理），另一层是组织的"环境数据（ambient data）"：文档、邮件、聊天记录、数据仓库……agent 一旦走出自己的小圈子干活就必须接入。→ 详细

• Microsoft IQ 不是单一功能，而是一组能力，按数据类型分四块：Work IQ（SharePoint 文档、邮件、日历、聊天 + 人与人的关系网络）、Fabric IQ（分析资产：数据仓库、数据湖、Power BI 报表）、Foundry IQ（给你自己的 agent 用，推自己的数据上去做 grounding）、Web IQ（公开网络信息，"补全 agent 世界观的完整拼图"）。设计目标是给 agent 一个接入所有环境数据的统一入口。→ 详细

• 一段行业自嘲式的复盘：RAG 刚兴起时 vector database（向量数据库：把文本变成数字向量、按语义相近度找资料）率先被大量采用，确实"帮很多系统从零跑了起来"。"我觉得有那么一小段时间，整个行业都以为：只要把向量之间的余弦相似度算得足够好，检索这件事就算搞定了。结果呢，事情从来没有那么简单。" → 详细
• 实证结论：各种评测"一遍又一遍地表明"，把多种方法组合起来（向量检索 + 词法检索 + 排序等）效果就是更好；他展示了 Azure AI Search（Foundry IQ 背后的搜索技术）的评测——单一方法不如组合方法，"尤其放到真实客户场景里差距更明显"。→ 详细
• 由此引出平台的真正难题（也是他反复强调的设计观）："如何把所有这些积木组合起来，同时又不把复杂性直接甩到你面前"——需要控制力时能深入，场景清晰时保持简单。→ 详细

• Foundry IQ 的核心设计目标是系统分层：顶层傻瓜模式——"我那边有一堆 PDF 或图片，你帮我处理掉就行"，底下自动做 chunking（把长文档切成小块）、向量化、相关性排序、agentic retrieval；专家可以下到栈底自建 vector index、指定向量量化方案、控制词法检索。关键是同一套栈，随需求变化自由上下移动，不用换系统。→ 详细
• 核心检索之上还有一层 agentic retrieval（agent 化检索）：简单场景用快速的单次检索（single-shot）就够；复杂场景则需要一个"能对数据集里的内容进行反思、在返回结果之前判断是否已满足输入所表达的信息需求"的系统——即检索本身变成一个会多轮思考、自查够不够的小 agent，而不是一问一答。→ 详细
• 他直面"这些花样真的有用吗"的质疑：从自家评测看，对困难案例，agentic retrieval 确实能带来差异——在证据召回率（evidence recall，该找的证据找没找全）、答案完整度（answer completeness）等多项追踪指标上"持续优于简单的单一组件方案"。注意限定词：是难题上有差异，不是包治百病。→ 详细

• 演示流程（电影数据集为例）：在 Foundry 创建 knowledge base → 因为是 agentic retrieval 系统，要指定一个模型驱动检索工作流，并可设置"努力程度"——本质是延迟与质量之间的权衡（多想一会儿答得更好，但更慢）→ 最关键一步是指定 grounding 数据来源，他一口气接了三种：blob storage 里的非结构化数据（PDF 等）、结构化的 parquet 统计表、Web。→ 详细
• 对建 agent 知识底座的人最有启发的一句："每个 knowledge base 本身就是一个 MCP server"——知识库是独立资产，既能直接挂到 Foundry agent 上，也能被你已有的任何 harness 直接连上，"中间不需要写任何胶水代码"。知识底座与 agent 框架解耦，靠标准协议对接。→ 详细
• 透明可下钻：切到 Azure 能看到知识库背后的 index 结构、自选量化方案与索引算法，还能浏览数据"看 chunk 是怎么组织的"——呼应分层哲学："不需要复杂性时给你高生产力环境，需要时确保能力就在那里。" → 详细

• 第三形态：习得知识是"我们作为个人和组织每天工作的产物"。根本变化在于——过去经验长在人脑里难以提取，现在是 agent 在干活，我们可以观察流程、通过反思改进每一步，并且自动化地去调优 agent。→ 详细
• 他引用 Satya（纳德拉，微软 CEO）最近的文章：人和 agent 可以在工作方式上形成复利效应，构建一个学习闭环——"有效捕捉你所在公司或组织的独特之处，并把它注入到工作中，让你做的事情形成差异化"。言下之意：模型人人都能用，组织沉淀下来的习得知识才是护城河。→ 详细

• 落地组件叫 agent optimizer，流程四步：评估 baseline → 生成候选方案 → 评测新候选 → 结果显著更好就部署上生产。演示在 VS Code + Foundry toolkit 里进行；前提只有一个——agent 的配置要外置化（instructions、工具定义、skills 等写成配置而非硬编码），"你怎么写这个 agent 都无所谓"。→ 详细
• 两条命令搞定：① eval generate——没有评测集？它会分析对这个 agent 的了解（trace、instructions 等），自动生成一套以任务遵循度（task adherence）为核心的评测（一批任务 + 问题 + 评判标准）；② optimize——本次运行约 45 分钟，对评测确立的指标做爬山优化（hill climbing，小步试探、只保留更好的版本），用"类似 GEPA 风格的循环"迭代候选组合；找到更优版本后 optimize apply 一键把旧配置换成新配置。→ 详细
• 最有画面感的结果：对比 baseline 和优化版的 instructions，优化版里"一大堆 instructions 不是人手写的，而是从爬山优化的过程中自然涌现出来的"——既基于现有 instructions/skills/工具，也基于"对用户实际使用中 agent 产生的真实 trace 的反思"。"这是一个真正落地的学习闭环。" → 详细

本期为大会演讲，无闪电问答环节。收尾行动号召：想试今天讲到或演示的任何东西，去 ai.azure.com 上手。→ 详细

视频中未给出个人联系方式；产品入口为 ai.azure.com。→ 详细