Beyond RAG: Enterprise Search Meets Analytics Over Unstructured Data

A popular narrative has taken hold in the AI community: RAG is dead. The argument goes something like this: RAG was always a workaround for tiny context windows — for example, GPT-3.5 could read roughly six pages, GPT-4 about twelve, and now LLMs can ingest a million tokens. So the right move is to load the documents and let the model reason end-to-end without dealing with chunking, embeddings or retrieval.AI 社区中流行着一种观点：RAG 已死。其论点大致如下：RAG 始终只是针对微小上下文窗口的临时解决方案——例如，GPT-3.5 大约能阅读六页内容，GPT-4 大约能阅读十二页，而现在的 LLM 已经能够处理一百万个 token。因此，正确的做法是直接加载文档，让模型进行端到端的推理，而无需处理分块、嵌入或检索。

We think the argument is reasonably correct about "traditional" RAG but it is wrong about what is going to replace it.我们认为，这一论点对于“传统”RAG 而言在很大程度上是正确的，但对于什么将取代它，这一论点是错误的。

The biggest failure mode of RAG was not the context window. RAG was never designed to analyze (for example, aggregate or compare) across hundreds of documents at once. So while a bigger context window lets a model read more, it doesn't give it a database. As we'll show in our benchmarks, a standard RAG agent achieves just 5.6% accuracy on operational analytical tasks over unstructured data, largely because top-k retrieval is not built for corpus wide aggregation, not because the model is weak. We propose that the answer isn't "just make the context window bigger" but instead a smarter analytical execution layer.RAG 最大的失效模式并非源于上下文窗口。RAG 从未被设计用于同时分析（例如汇总或比较）数百份文档。因此，虽然更大的上下文窗口可以让模型阅读更多内容，但它并不能为模型提供数据库功能。正如我们在基准测试中所展示的，标准的 RAG 代理在针对非结构化数据的操作型分析任务中，准确率仅为 5.6%，这主要是因为 top-k 检索并非为全语料库聚合而设计，而非模型本身能力不足。我们认为，答案不是“仅仅扩大上下文窗口”，而是一个更智能的分析执行层。

Most enterprise search systems were designed to find a document. Analytical Search is designed to answer. Not surface relevant results, not retrieve the closest match, but answer — even when doing so requires reading across hundreds of documents. It does this by treating your document corpus the way a database treats a table: something you can filter, aggregate, count and compare, not just search.大多数企业搜索系统旨在查找文档。而“分析型搜索”（Analytical Search）旨在回答问题。它不是为了呈现相关结果，也不是为了检索最接近的匹配项，而是为了回答问题——即使这需要阅读数百份文档。它通过将文档语料库视为数据库处理表的方式来实现这一点：你可以对其进行过滤、聚合、计数和比较，而不仅仅是搜索。

Today, we are excited to introduce Analytical Search (in public preview), a new search paradigm designed to help Snowflake users get deep, actionable insights from unstructured data. Starting with Snowflake CoWork, Analytical Search is available today to knowledge workers who need answers, not just results. By orchestrating efficient semantic search via Snowflake Cortex Search with high-fidelity information processing via Snowflake Cortex AI Functions, Analytical Search delivers the kind of sophisticated analysis that traditional enterprise search engines simply can't facilitate.今天，我们很高兴推出“分析型搜索”（处于公开预览阶段），这是一种全新的搜索范式，旨在帮助 Snowflake 用户从非结构化数据中获取深度、可落地的洞察。从 Snowflake CoWork 开始，分析型搜索现已面向那些需要答案而非仅仅是搜索结果的知识工作者开放。通过利用 Snowflake Cortex Search 进行高效的语义搜索，并结合 Snowflake Cortex AI 函数进行高保真的信息处理，分析型搜索能够提供传统企业搜索引擎根本无法实现的复杂分析。

Cortex Agent with Analytical Search. The agent identifies analytical intent in the user's prompt and plans a retrieval-then-analysis execution path. Analytical Search gathers evidence from Cortex Search with adaptive depth, then analyzes it with AI functions and SQL before returning results and reasoning to the agent for the final response.配备分析型搜索的 Cortex Agent。该代理能够识别用户提示词中的分析意图，并规划“先检索后分析”的执行路径。分析型搜索利用 Cortex Search 以自适应深度收集证据，随后在返回结果前通过 AI 函数和 SQL 进行分析，并将推理过程反馈给代理以生成最终回复。

Why Analytical Search? Analysts and business users need more than just a list of links. Rather than merely retrieving a few semantically relevant documents for a carefully phrased query, we understand that modern users would rather depend on a search agent to handle the full spectrum of complex tasks. Data practitioners today often split this into RAG and ETL pipelines to force structure onto data. This approach rarely scales beyond well-defined sources and outcomes. Analytical search addresses this by effectively building a schema on generation, where the prompt is the contract to the data schema and output is required to provide the analysis.为什么要使用分析型搜索？分析师和业务用户需要的不仅仅是一串链接。我们理解，现代用户更希望依赖搜索代理来处理全方位的复杂任务，而不是仅仅为精心设计的查询检索几份语义相关的文档。如今的数据从业者通常将其拆分为 RAG 和 ETL 流水线，以强行赋予数据结构。这种方法在超出定义良好的来源和结果范围时，很难进行扩展。分析型搜索通过有效地在生成时构建模式（schema on generation）来解决这个问题，其中提示词即是数据模式的契约，而输出则必须提供相应的分析。

Take this prompt as an example: "Find documents focused on shipments from the Northwestern US and compare trends from Q1 to Q3."以这个提示词为例：“查找关注美国西北部发货的文档，并比较第一季度到第三季度的趋势。”

• Standard RAG (Retrieval-Augmented Generation) agents may fail here because they weren't built for analytical synthesis. The search system will provide top-k results based on relevance and a given agent will do its best to answer the prompt. The reality, however, is that the agent was subjected to that very top-k set of results. Unstructured data isn't just a collection of random web pages or text blobs; it consists of business-critical assets like orders, transactions, and research reports. At this scale, precise, document-level analytics are vital for operational success and strategic decision-making. For the above example prompt, a standard RAG response will likely be relevant, but incomplete.标准的 RAG（检索增强生成）代理在这里可能会失败，因为它们并非为分析性综合而构建。搜索系统会根据相关性提供 top-k 结果，而给定的代理将尽其所能回答提示词。然而现实情况是，代理仅受限于那组 top-k 结果。非结构化数据不仅仅是随机网页或文本块的集合；它由订单、交易和研究报告等业务关键资产组成。在这种规模下，精确的文档级分析对于运营成功和战略决策至关重要。对于上述示例提示词，标准 RAG 的回复很可能是相关的，但却是不完整的。
• Analytical Search addresses this by splitting the task into two phases: retrieval via adaptive-depth search, and computation via AI Functions and SQL operators — so the agent can pull the right slice of evidence and then aggregate it precisely instead of stuffing raw text into its context. Coding agents take the alternative route — grep through documents locally, load matches into the agent's context, and reason over the result — which is a strong agentic baseline but doesn't scale once the question demands corpus-wide aggregation. The accuracy gap follows. On our benchmarks, Analytical Search outperformed standard agentic RAG by 4 to 12 times on analytical tasks, and outperformed coding agents by up to 45% on multistep analytical questions.分析型搜索通过将任务分为两个阶段来解决这个问题：通过自适应深度搜索进行检索，以及通过 AI 函数和 SQL 运算符进行计算——这样代理就可以提取正确的证据切片，并进行精确聚合，而不是将原始文本塞入上下文。代码编写代理（Coding agents）采取了另一种路径——在本地通过 grep 遍历文档，将匹配项加载到代理的上下文中，并对结果进行推理——这是一个强大的代理基准，但一旦问题需要全语料库聚合，它就无法扩展。准确率差距随之产生。在我们的基准测试中，分析型搜索在分析任务上的表现比标准代理 RAG 高出 4 到 12 倍，在多步分析问题上比代码编写代理高出 45%。

The three stages of search搜索的三个阶段

To understand why Analytical Search changes the game, it helps to look at how enterprise search has evolved into three distinct stages:要理解为什么分析型搜索能够改变游戏规则，了解企业搜索如何演变为三个不同的阶段会有所帮助：

1. Standard RAG (The baseline)1. 标准 RAG（基准）

RAG is simple and powerful: retrieve the top-k most relevant text chunks and ask a large language model to extract an answer. This is highly effective when the answer is localized, textual, and contained within a few passages.RAG 简单而强大：检索 top-k 最相关的文本块，并要求大语言模型提取答案。当答案是局部的、文本化的，并且包含在少数段落中时，这种方法非常有效。

• What goes wrong: If a task requires exhaustive coverage, aggregation, counting, comparison, or normalization across hundreds of documents, top-k retrieval becomes a brittle sampling strategy that misses the full picture.问题所在：如果任务需要对数百份文档进行详尽的覆盖、聚合、计数、比较或归一化，top-k 检索就会变成一种脆弱的抽样策略，从而遗漏全貌。

2. Agentic Search (The evolution)2. 代理型搜索（演进）

Agentic search introduces loops: an AI agent can search, read, reason, reformulate its query and search again. By decomposing a problem and chasing missing evidence, agents drastically improve recall and robustness for complex document QA.代理型搜索引入了循环：AI 代理可以搜索、阅读、推理、重新表述查询并再次搜索。通过分解问题并追寻缺失的证据，代理极大地提高了复杂文档问答的召回率和鲁棒性。

• What goes wrong: At its core, much of agentic search is still fundamentally search-and-summarize, but in a reasoning loop. While the agent takes more turns to find better evidence, the final answer is still synthesized from a relatively small, sampled evidence set. It cannot perform true macro-analysis.问题所在：本质上，大部分代理型搜索在根本上仍然是“搜索并总结”，只不过是在一个推理循环中进行。虽然代理通过更多轮次来寻找更好的证据，但最终答案仍然是从一个相对较小、经过抽样的证据集中合成的。它无法执行真正的宏观分析。

A natural next step is to skip retrieval entirely. With million-token context windows, why not load everything and let the model reason end-to-end? The answer is cost, reproducibility, and correctness. Loading thousands of documents into a single prompt is orders of magnitude more expensive than targeted retrieval, produces no auditable execution trace, and still doesn't give you grouping, counting, or SQL-level precision.下一个自然的步骤是完全跳过检索。有了百万 token 的上下文窗口，为什么不加载所有内容并让模型进行端到端推理呢？答案是成本、可重复性和正确性。将数千份文档加载到单个提示词中，其成本比目标检索高出几个数量级，且无法产生可审计的执行轨迹，也依然无法提供分组、计数或 SQL 级别的精度。

3. Analytical Search (The Paradigm Shift)3. 分析型搜索（范式转移）

Analytical Search treats unstructured corpora as native data sources that can be filtered, transformed, joined, grouped and aggregated. Instead of treating documents as passive text blobs, it asks: What if the documents themselves are the table? What if semantic predicates, extractions and summaries become native operators inside an analytical execution plan?分析型搜索将非结构化语料库视为原生数据源，可以对其进行过滤、转换、连接、分组和聚合。它不再将文档视为被动的文本块，而是提出了这样的问题：如果文档本身就是表呢？如果语义谓词、提取和摘要成为分析执行计划中的原生运算符会怎样？

• The Core Concept: Analytical Search brings rigorous, reproducible analytical capabilities to unstructured enterprise data in as few steps as possible. For data practitioners this brings the time-to-value to as little as a day to serve an agent with access to a search index as the only prerequisite.核心概念：分析型搜索以尽可能少的步骤，将严谨、可重复的分析能力引入非结构化企业数据。对于数据从业者而言，这使得实现价值的时间缩短至最少仅需一天，前提是代理能够访问搜索索引。

Architecture: The two-layer paradigm架构：双层范式

Analytical Search is able to handle complex analytical tasks by separating the problem into two complementary, highly efficient layers within Snowflake.分析型搜索能够通过将问题分解为 Snowflake 内两个互补且高效的层，来处理复杂的分析任务。

Layer 1: Use search to prune第 1 层：使用搜索进行剪枝

Search is excellent at narrowing a massive corpus down to a highly relevant candidate set, such as finding documents about refrigerated shipping, identifying papers discussing prompt injection, or isolating contracts containing a specific liability clause.搜索非常擅长将海量语料库缩小为高度相关的候选集，例如查找关于冷藏运输的文档、识别讨论提示词注入的论文，或隔离包含特定责任条款的合同。

Using Snowflake Cortex Search, the agent quickly isolates the relevant region of the corpus without scanning every single token with an expensive frontier model. Crucially, the depth of this pruning layer dynamically adapts to your data; stretching when the tail of results remains relevant, and cutting off the moment relevance drops.利用 Snowflake Cortex Search，代理可以快速隔离语料库的相关区域，而无需使用昂贵的前沿模型扫描每一个 token。关键在于，这一剪枝层的深度会根据你的数据动态调整；当结果尾部仍然相关时进行扩展，一旦相关性下降则立即切断。

Layer 2: Use AI functions and SQL to analyze第 2 层：使用 AI 函数和 SQL 进行分析

Once the corpus is pruned, the system shifts from retrieval to computation. Snowflake Cortex AI functions provide high-fidelity semantic operators directly within the data layer:一旦语料库被剪枝，系统就会从检索转向计算。Snowflake Cortex AI 函数直接在数据层提供高保真的语义运算符：

• AI_FILTER: Tests whether text satisfies a specific semantic predicate.AI_FILTER：测试文本是否满足特定的语义谓词。
• AI_EXTRACT: Pulls structured, deterministic fields out of unstructured text.AI_EXTRACT：从非结构化文本中提取结构化、确定性的字段。
• AI_AGG: Summarizes and aggregates textual evidence at scale.AI_AGG：大规模汇总和聚合文本证据。

From there, SQL does exactly what it was built to do best: group, count, join, rank, trend, and calculate deltas. By marrying semantic AI operators with traditional relational algebra, the agent is no longer just reading documents. Analytical Search is executing a highly efficient, reproducible analytical workflow over them.在此基础上，SQL 执行了它最擅长的任务：分组、计数、连接、排名、趋势分析和计算差异。通过将语义 AI 运算符与传统关系代数相结合，代理不再仅仅是阅读文档。分析型搜索正在对它们执行一种高效、可重复的分析工作流。

Auto-routing: Measuring analytical intent自动路由：衡量分析意图

Analytical search is the right tool for analytical questions, but not for every prompt. A user asking:分析型搜索是处理分析问题的正确工具，但并非适用于所有提示词。用户询问：

• "What does our travel policy say about meal reimbursement?" does not need exhaustive retrieval, semantic classification, and SQL aggregation.“我们的差旅政策对餐饮报销是怎么说的？”不需要详尽的检索、语义分类和 SQL 聚合。
• Meanwhile, "How does our supply-chain risk language compare to our peers across the last two years of earnings calls?" absolutely does.与此同时，“我们的供应链风险措辞与同行在过去两年的财报电话会议相比如何？”则绝对需要。

Choosing the right engine for each question is itself a functional feature of Analytical Search and Snowflake Cortex Agents.为每个问题选择正确的引擎本身就是分析型搜索和 Snowflake Cortex Agents 的一项功能特性。

As shown in our Experiments section, getting auto-routing "right" matters. When a question has analytical shape but the agent treats it as RAG, the answer collapses. Auto-Routing handles the choice automatically. Cortex Agent classifies query intent at runtime: Simple, single-passage questions stay on the standard RAG path; corpus-wide analytical questions trigger the analytical-search loop. Users do not have to know in advance which mode their question belongs to, and you do not pay for analytical search orchestration on questions that do not need it.正如我们在实验部分所示，正确实现自动路由至关重要。当一个问题具有分析属性，但代理将其视为 RAG 处理时，答案就会崩溃。自动路由会自动处理选择。Cortex Agent 在运行时对查询意图进行分类：简单的单段问题保留在标准 RAG 路径上；全语料库分析问题触发分析型搜索循环。用户无需预先知道他们的问题属于哪种模式，你也不必为不需要分析型搜索的问题支付编排费用。

Planning mode: Multistep, not one-shot规划模式：多步，而非一次性

Answering a complex counting, ranking, or trend question isn't a one-shot retrieval task; it is a multi-step workflow. For instance, if a CFO asks to track risk frequencies across years of earnings calls compared to peers, the system must meticulously isolate the relevant corpus, extract specific semantic facts, and aggregate those trends over time.回答复杂的计数、排名或趋势问题不是一次性的检索任务；它是一个多步工作流。例如，如果首席财务官要求跟踪多年财报电话会议中的风险频率并与同行进行比较，系统必须仔细隔离相关语料库，提取特定的语义事实，并随时间推移汇总这些趋势。

Analytical Search always invokes a multistep plan. Once approved, it converts into an interactive to-do list that updates as the agent performs the subtasks.分析型搜索总是调用一个多步计划。一旦获得批准，它就会转换为一个交互式待办事项列表，并随着代理执行子任务而更新。

Because business decisions carry high stakes, Analytical Search rejects the "black box" approach. Before executing anything, the agent generates a clear, high-level execution plan mapping out its logical steps. It presents this plan to the user for explicit confirmation, allowing for quick course-corrections, like adjusting the peer set or time windows, before processing any data.由于商业决策风险很高，分析型搜索拒绝“黑盒”方法。在执行任何操作之前，代理会生成一个清晰的高级执行计划，规划其逻辑步骤。它将此计划呈现给用户以供明确确认，从而允许在处理任何数据之前进行快速的路径修正，例如调整同行集合或时间窗口。

Once approved, the plan instantly converts into an interactive to-do list. As the agent prunes the corpus and runs semantic operations, the user can track its progress in real time. This supports complete transparency and trust: you don't need to read raw code to verify the results, because you can clearly see the exact logical path the agent took to deliver the final insight.一旦获得批准，该计划会立即转换为交互式待办事项列表。当代理剪枝语料库并运行语义操作时，用户可以实时跟踪其进度。这支持了完全的透明度和信任：你不需要阅读原始代码来验证结果，因为你可以清楚地看到代理为提供最终洞察所采取的确切逻辑路径。

Adaptive depth: Search deep enough not to miss the answer自适应深度：搜索足够深以确保不会遗漏答案

Adaptive depth is the mechanism that makes analytical search behave less like sampling and more like exhaustive analysis. A fixed top-k retrieval strategy gets two things wrong.自适应深度是一种使分析型搜索的行为更像详尽分析而非抽样的机制。固定的 top-k 检索策略在两方面存在错误。

1. Too shallow. The missing item is often the specific data point that changes the answer—perhaps a contract missing a standard termination clause, a paper reporting a different benchmark, or a document that flips a quarterly trend.太浅。缺失的项目往往是改变答案的特定数据点——例如一份缺少标准终止条款的合同、一份报告了不同基准的论文，或一份扭转季度趋势的文档。
2. Too deep. The user or the LLM optimistically asks for k=1,000, but the corpus actually contains only a few dozen relevant documents, and the rest is wasted compute.太深。用户或 LLM 乐观地要求 k=1,000，但语料库实际上只包含几十份相关文档，其余的都是浪费计算资源。

Adaptive depth makes the cutoff a function of the data, not a guessed parameter, and it works in two phases.自适应深度使截止点成为数据的函数，而不是猜测的参数，它分两个阶段工作。

• Phase 1: Bound the relevant region. The system fetches an initial batch of results and uses a fast LLM to judge small samples at the head and tail of the ranked list. If even the top results are irrelevant, the search itself is bad — the tool returns nothing rather than feed AI functions material that would only generate noise. If the tail is still relevant, the cutoff lives further out: The system extends the fetch limit and rejudges the new tail, repeating until the tail goes off-topic or a hard ceiling is reached.第 1 阶段：界定相关区域。系统获取初始批次结果，并使用快速 LLM 对排序列表头部和尾部的小样本进行判断。如果连最靠前的结果都不相关，说明搜索本身就很糟糕——工具会返回空结果，而不是向 AI 函数提供只会产生噪音的材料。如果尾部仍然相关，截止点就会向后延伸：系统会扩展获取限制并重新判断新的尾部，重复此过程直到尾部偏离主题或达到硬上限。
• Phase 2: Find the exact cutoff. Once the relevant region is bounded, the system binary-searches inside it, LLM-judging a sample around the midpoint and tightening the window, to land on the precise boundary in a handful of rounds. A narrow fact question stays shallow; a trend across a broad corpus goes deep; a question against a sparse corpus stops early.第 2 阶段：找到确切的截止点。一旦相关区域被界定，系统会在内部进行二分搜索，通过 LLM 对中点附近的样本进行判断并收紧窗口，在几轮内定位到精确边界。简单的事实问题保持浅层；跨广泛语料库的趋势问题深入挖掘；针对稀疏语料库的问题则提前停止。

The cost story cuts both ways. Better coverage reduces wasted downstream, while AI calls and prevents expensive wrong answers. Better restraint avoids paying to extract and classify documents that would not have answered the question in the first place. AI functions are powerful but not free, as every unnecessary call adds latency and dollars. And adaptive depth is the layer that decides how many of those calls are worth making.成本问题是双向的。更好的覆盖范围减少了下游的浪费，同时 AI 调用也防止了昂贵的错误答案。更好的限制避免了为提取和分类那些本无法回答问题的文档而付费。AI 函数功能强大但并非免费，因为每次不必要的调用都会增加延迟和成本。而自适应深度正是决定这些调用中有多少值得进行的层级。

Experiments实验

We have benchmarked analytical search across three data sets, across four systems.我们已经在三个数据集和四个系统上对分析型搜索进行了基准测试。

The three data sets三个数据集

• OfficeQA Pro, an open public-finance benchmark over long-form financial reports, scanned tables, and historical documents. We use it to exercise the semantic search + AI_EXTRACT path: locate the right chunk via Cortex Search, pull values out of historical tables; annual totals, reported figures from scanned financials, period-over-period changes and run the arithmetic in SQL. This is per-document deep extraction rather than corpus-wide aggregation, which makes it a useful complement to the other data sets.OfficeQA Pro，一个针对长篇财务报告、扫描表格和历史文档的公开公共财政基准。我们利用它来锻炼“语义搜索 + AI_EXTRACT”路径：通过 Cortex Search 定位正确的块，从历史表格中提取数值；年度总计、扫描财务报告中的报告数字、周期性变化，并在 SQL 中进行算术运算。这是针对文档的深度提取，而非全语料库聚合，这使其成为其他数据集的有用补充。
• Logistics Documents (internal benchmark). Example questions: contracts with penalty clauses and SLA requirements grouped by carrier and value tier; emerging technologies such as automation, IoT tracking, or AI-driven routing tracked by quarter; total estimated shipment value for active purchase orders involving a given carrier and region. These are analytical workloads over operational documents.物流文档（内部基准）。示例问题：按承运人和价值层级分组的带有惩罚条款和 SLA 要求的合同；按季度跟踪的新兴技术，如自动化、物联网跟踪或 AI 驱动的路由；涉及特定承运人和地区的活跃采购订单的总预估发货价值。这些是针对操作文档的分析工作负载。
• ArXiv Papers (internal benchmark). A representative question: "How many papers from 2023–2025 evaluate LLMs on the GPQA benchmark?" Others ask how mentions of techniques like chain-of-thought, mixture-of-experts, prompt injection, watermarking, or tool use in LLM agents change over time, or whether reported values agree across papers. This is literature review as analytics: not "find a paper," but "measure a pattern across papers."ArXiv 论文（内部基准）。一个代表性问题：“2023–2025 年间有多少篇论文在 GPQA 基准上评估了 LLM？”其他问题询问思维链、专家混合、提示词注入、水印或 LLM 代理中工具使用等技术的提及频率如何随时间变化，或者报告的数值在不同论文间是否一致。这是作为分析的文献综述：不是“找一篇论文”，而是“衡量跨论文的模式”。

The four systems四个系统

• Claude Code, using grep to search documents as local files and perform analytics in context.Claude Code，使用 grep 将文档作为本地文件进行搜索并在上下文中进行分析。
• Snowflake CoCo, Snowflake's coding agent — a strong agentic baseline that can search, read, write code and execute SQL.Snowflake CoCo，Snowflake 的代码编写代理——一个强大的代理基准，可以搜索、阅读、编写代码并执行 SQL。
• RAG Agent — a conventional Cortex Agent with Cortex Search tool, but without the analytical search capabilities enabled.RAG Agent——一个带有 Cortex Search 工具的传统 Cortex Agent，但未启用分析型搜索功能。
• Cortex Agent with analytical search — adds the planning, AI-function, and adaptive-depth orchestration described above.配备分析型搜索的 Cortex Agent——添加了上述的规划、AI 函数和自适应深度编排。

Evaluation metrics评估指标

Analytical questions vary in form, so we tailor the scoring metric to the query's shape. We use correctness × fidelity for numeric and categorical types, which accounts for both direction and magnitude. For list shapes, we use the F1 score, as it inherently balances precision and recall. These shapes are determined by the golden structure rather than the agent's response, and final accuracy is the mean of per-query scores. Prompt classifications included:分析问题形式各异，因此我们根据查询的形态定制评分指标。对于数值和分类类型，我们使用“正确性 × 保真度”，它同时考虑了方向和幅度。对于列表形态，我们使用 F1 分数，因为它本身平衡了精确率和召回率。这些形态由标准结构而非代理的响应决定，最终准确率是每个查询分数的平均值。提示词分类包括：

• List queries for example, "list every paper that proposes a new long-context benchmark"列表查询，例如，“列出每一篇提出新长上下文基准的论文”
• Scalar queries for example, "what fraction of 2024–2025 quantization papers evaluate at ≤4-bit?"标量查询，例如，“2024–2025 年量化论文中有多少比例是在 ≤4-bit 下进行评估的？”
• Trend queries for example, "how has the count of HarmBench-evaluating papers changed from 2023 to 2025?"趋势查询，例如，“评估 HarmBench 的论文数量从 2023 年到 2025 年发生了怎样的变化？”
• Categorical comparison queries for example, "which has more, MedQA or PubMedQA evaluators?"分类比较查询，例如，“MedQA 和 PubMedQA 评估者哪个更多？”

For OfficeQA Pro, we follow the dataset's published convention, using a strict deterministic judge with zero error margin. For the Logistics and arXiv data sets, we use the per-shape decomposition described above.对于 OfficeQA Pro，我们遵循该数据集发布的惯例，使用零误差容限的严格确定性评判。对于物流和 arXiv 数据集，我们使用上述按形态分解的方法。

Results结果

Accuracy of four systems across three data sets, evaluated with Claude Opus 4.6. OfficeQA Pro is scored by a deterministic judge (0% error margin). The dashed line on OfficeQA Pro shows the reported comparable baseline (54.1). The four systems cluster within nine points on OfficeQA Pro, but on the analytical search data sets Cortex Agent without analytical search (RAG agent) collapses to 5.6 (Logistics) and 17.2 (arXiv), while Cortex Agent with analytical search excels at 66.7 and 71.3.四个系统在三个数据集上的准确率，使用 Claude Opus 4.6 进行评估。OfficeQA Pro 由确定性评判（0% 误差容限）打分。OfficeQA Pro 上的虚线显示了报告的可比基准（54.1）。四个系统在 OfficeQA Pro 上聚集在九分以内，但在分析型搜索数据集上，未配备分析型搜索的 Cortex Agent（RAG 代理）在物流（5.6）和 arXiv（17.2）上表现崩溃，而配备分析型搜索的 Cortex Agent 则以 66.7 和 71.3 的成绩表现优异。

Figure 3 above shows results across all three data sets for Claude Opus 4.6. Three things stand out.上图 3 显示了 Claude Opus 4.6 在所有三个数据集上的结果。有三点非常突出。

• On OfficeQA Pro, all three Cortex systems comfortably beat the reported baseline (54.1) and cluster within seven points of each other (65.0, 67.1, 71.1). This is the per-document extraction shape — locate the right chunk, pull values from a table, do the arithmetic. Analytical search wins, but it does not need to win by much; the dataset is not built around corpus-wide aggregation.在 OfficeQA Pro 上，所有三个 Cortex 系统都轻松击败了报告的基准（54.1），并且彼此聚集在七分以内（65.0, 67.1, 71.1）。这是文档级提取形态——定位正确的块，从表格中提取数值，进行算术运算。分析型搜索胜出，但它不需要赢得太多；该数据集并非围绕全语料库聚合而构建。
• On the analytical data sets, the gap opens dramatically. RAG agent collapses to 5.6% on Logistics Documents and 17.2% on arXiv Papers. These are not "weaker numbers" — the agent is failing to get the full context. The corpus has too many relevant documents for top-k retrieval to surface, and once the agent has only a handful of chunks, there is nothing left to aggregate, count, or compare. CoCo does materially better (51.2 / 59.6) because it can plan and run SQL, but it still trails Cortex Agent with analytical search (66.7 / 71.3) by 10–15 points.在分析型数据集上，差距急剧拉大。RAG 代理在物流文档上崩溃至 5.6%，在 arXiv 论文上崩溃至 17.2%。这些不是“更弱的数字”——而是代理未能获取完整的上下文。语料库中相关文档太多，top-k 检索无法呈现，一旦代理只有少数几个块，就再也没有什么可以聚合、计数或比较的了。CoCo 的表现明显更好（51.2 / 59.6），因为它能够规划并运行 SQL，但它仍然落后于配备分析型搜索的 Cortex Agent（66.7 / 71.3）10–15 分。
• The ordering holds with double-digit margins on both analytical data sets: Cortex Agent with analytical search > Snowflake CoCo > Claude Code > RAG agent. The same arrangement of components that systematizes the analytical loop; search to prune, AI functions to filter and classify and extract, SQL to aggregate, adaptive depth to right-size the work, is what closes the gap. A general agent can improvise that loop on every question and partially succeed; a system designed around it does the work more reliably and at lower cost.这种排序在两个分析型数据集上都保持着两位数的领先优势：配备分析型搜索的 Cortex Agent > Snowflake CoCo > Claude Code > RAG 代理。将分析循环系统化的组件排列组合——搜索以剪枝，AI 函数以过滤、分类和提取，SQL 以聚合，自适应深度以调整工作量——正是缩小差距的原因。通用代理可以在每个问题上即兴发挥该循环并部分成功；而围绕它设计的系统能更可靠且以更低的成本完成工作。

Why Snowflake is a natural place for Analytical Search为什么 Snowflake 是分析型搜索的天然场所

Analytical Search is an orchestration workflow that needs an agent that can plan and tool-call, run scalable retrieval over unstructured data and execute semantic processing close to the data — all in the same governed system. Snowflake provides each piece. Cortex Agent plans the workflow and orchestrates the calls. Cortex Search retrieves over unstructured documents and applies filters on associated structured attributes. Cortex AI functions are semantic operators that compose directly with SQL. SQL provides the execution substrate. Language becomes an operator inside a single, governed query plan.分析型搜索是一种编排工作流，它需要一个能够规划和调用工具、在非结构化数据上运行可扩展检索，并在靠近数据的地方执行语义处理的代理——所有这些都在同一个受治理的系统中。Snowflake 提供了每一部分。Cortex Agent 规划工作流并编排调用。Cortex Search 在非结构化文档上进行检索，并对关联的结构化属性应用过滤器。Cortex AI 函数是直接与 SQL 组合的语义运算符。SQL 提供了执行底座。语言成为单一、受治理查询计划中的一个运算符。

That matters for trust. In enterprise settings, a plausible paragraph is not enough. Users need to understand what was searched, filtered, counted, excluded and how the final number was derived. Analytical search makes those steps explicit and inspectable, instead of hiding them inside a chain of thought.这对信任至关重要。在企业环境中，一个看似合理的段落是不够的。用户需要了解搜索、过滤、计数、排除的内容，以及最终数字是如何得出的。分析型搜索使这些步骤变得明确且可检查，而不是将它们隐藏在思维链中。

From unstructured data to value从非结构化数据到价值

The highest-value questions customers ask about unstructured data are often not answered by a single passage. They require reading across contracts, invoices, support notes, research papers, call transcripts, filings and PDFs; applying semantic judgment; and then doing real analysis. The winning systems will not be the ones that stuff more chunks into a prompt. They will be the ones that combine retrieval, semantic functions, planning, adaptive depth and database execution into one coherent loop.客户针对非结构化数据提出的最高价值问题，往往无法通过单个段落回答。它们需要阅读合同、发票、支持记录、研究论文、通话记录、备案文件和 PDF；应用语义判断；然后进行真正的分析。胜出的系统将不是那些向提示词中塞入更多块的系统。它们将是那些将检索、语义函数、规划、自适应深度和数据库执行结合到一个连贯循环中的系统。

Analytical search is our bet on that future: search for pruning, AI for semantic understanding, SQL for rigor, and Snowflake for scale and governance. Analytical search introduces the fastest path to go from unstructured data to insights.
Here is how you begin:分析型搜索是我们对未来的押注：搜索用于剪枝，AI 用于语义理解，SQL 用于严谨性，Snowflake 用于规模和治理。分析型搜索引入了从非结构化数据到洞察的最快路径。 开始方式如下：

1. Create a Search Service (or repurpose an existing one)创建搜索服务（或重新利用现有服务）
2. Add the Search Service to a Cortex Agent将搜索服务添加到 Cortex Agent
3. Start Prompting Cortex CoWork开始提示 Cortex CoWork