让元数据参与检索：Foundry IQ 与自建 Azure AI Search 索引的 RAG 实践

企业文档库里常有多年积累的结构化属性，例如根因类别、严重程度、负责人和密级。这些属性不一定出现在正文里。如果检索管线只处理正文，系统就无法利用它们。

微软这篇博客用事故复盘文档做例子。一份复盘的根因类别是“配置变更”，但正文只描述了 DNS 记录在迁移中被改指向，并没有出现“配置”二字。另一份复盘可能只是提到“怀疑过配置变更，后来排除了”。纯文本检索容易把后者排在前面。

我的理解是，这类问题调参解决不了。字段没有进入索引，排序再怎么优化也看不到它。

作者的思路是自己维护一个 Azure AI Search 索引，再把它作为 searchIndex 类型的知识源接入 Foundry IQ。这样既能控制元数据字段，也能保留智能体式的查询规划。

文章对比了三种方案。原生 SharePoint 知识源有查询规划，但无法控制自定义列。直接查询自建索引能控制元数据，但没有查询规划。自建索引加 Foundry IQ 两者兼得。

核心设计原则有两条：

文章列出四个方面：检索字段决定子查询搜索哪些字段；语义配置让重排序器看到重要的元数据；查询提示帮助规划器把自然语言对应到已知取值；过滤条件可以施加硬约束。

提示只是尽力而为。需要严格保证的条件，应该用基础过滤或文档级访问控制，而不能指望规划器恰好选中某条提示。这一点对有合规要求的团队尤其重要。

作者在同一个索引上建了两个知识库：基线只搜标题和正文，对照组加入结构化元数据、语义配置和查询提示。十个问题、四轮运行，基线在前五条结果中共命中 26 篇匹配文档，元数据版本为 39 到 41 篇，满分 50。

提升集中在元数据承载关键含义的问题上，例如“配置变更”类问题从 0 升到 3。正文已包含关键词的问题，两边都拿到满分。所以结论不是“元数据让搜索全面变好”，而是“元数据能补上正文没说清的那部分”。

需要注意，这是作者用合成数据集做的概念验证，样本规模小。我会把它看作方向性证据，而不是通用的效果承诺。

查询规划由 LLM 完成，偶尔会生成索引不接受的过滤表达式。文章提到两种：字符串值没加引号；把取值为 Yes/No 的字符串字段当成布尔值比较，导致检索请求返回 HTTP 502。

作者的修法是在过滤指令里写明字段类型和允许取值。我认为应用层也应当捕获检索失败并有降级路径，不要假设生成的过滤一定合法。

适合的场景是：答案取决于文档属性，而属性不在正文里，比如事故复盘、合同、工单、合规文档。如果检索词本来就出现在正文里，这套改造的收益有限。

代价同样明确。自建索引意味着要自己负责摄取，可以用带自定义列的 SharePoint 索引器、基于 Microsoft Graph 的函数，或现有的数据管线。文章还提醒，自建索引不会自动继承 SharePoint 权限，需要把 ACL 带入摄取和检索环节。分类取值变化时，查询提示也要重新生成。

原文链接见文末来源。

Microsoft Foundry Blog：When the Answer Isn’t in the Document: Metadata-Aware Agentic RAG with Foundry IQ（https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/when-the-answer-isn%E2%80%99t-in-the-document-metadata-aware-agentic-rag-with-foundry-iq/4562237）