Is Enterprise AI Effective? Why Can’t We Just Look at the Rankings?

Take the same model, for example: in a demo, it can read long articles and write polished reports, but once integrated with the company’s cloud storage and business systems, it might mistake old policies for new regulations or say “prepared to send” instead of “already sent.” Such discrepancies aren’t necessarily solved simply by switching to a model that ranks higher on a leaderboard.

Companies purchase a working system, while the rankings primarily show how the model performs on specific test questions. Although the two are related, they are not directly equivalent.

On October 30, Microsoft Research introduced a synthetic enterprise evaluation data platform for Copilot: without using customer data, it constructs simulated enterprises based on publicly available occupational and organizational information, and generates test questions that closely resemble real-world work scenarios. The platform has been added to Microsoft’s internal shared directory for teams to reuse; it is not a new tool announced for public release.Official Microsoft Description

What makes this noteworthy is not that there is yet another set of test questions, but that the unit of evaluation for enterprise AI is shifting: from a single answer to a task that involves context, boundaries, and consequences.

A numerical answer to “Will it happen?”; the business side also needs to ask, “Can it be delivered?”

Imagine a procurement assistant. When an employee asks, “Can we place an order for this batch of equipment right away?” the AI must identify the applicable policies, recognize the amount and procurement category, determine the asker’s authorization level, and then distinguish between “can be requested” and “already approved.” Even though each step on its own isn’t complicated, errors can still occur when they’re linked together.

If a test simply asks, “What are the typical steps in the procurement process?” a fluent answer is likely to earn a high score; but if the same question is rephrased as, “According to our company’s current policies, who should this request be submitted to next?” the model must process the relationships between specific documents. If the model is then allowed to submit the request, the focus shifts from the accuracy of knowledge to the correctness of the procedure.

Therefore, when selecting a solution, companies must at least break down the process into three distinct aspects: what the model can understand, what the system can identify, and what the tool ultimately changes. If these three aspects are lumped together into a single overall score, it becomes easy to attribute implementation flaws to the model and to mistake elegant formulation for reliable execution.

First Report Card: Are the Sources I Found Accurate?

Knowledge base projects often focus on whether an answer “looks like” the correct one, but even a fully quoted response may still be based on incorrect information. Outdated versions, duplicates, broken links, and attachments that cannot be retrieved can all cause the model to provide a wrong answer in good faith.

Microsoft Foundry's evaluation documentation separates the retrieval process from the final response: the retrieval process assesses whether relevant information was found, while the response is evaluated to determine whether it is well-founded, on-topic, and whether any key content was omitted.“No fabrication” and “complete answers” are two different requirements.RAG Evaluation Guidelines

For businesses, this distinction has direct value in troubleshooting. If the correct material has not been included in the context at all, you should first address the index, classification, version, or scope of access; if the material has been identified correctly but the answer omits exception conditions, then examine the prompts, models, and output checks. Otherwise, constantly switching models may simply result in the same set of erroneous material being restated more fluently.

The Second Report Card: Did We Actually Get It Done?

Just because the AI says “The work order has been created” doesn’t mean there’s actually a record in the work order system. If you try again after the API times out, the status might change from “Task not completed” to “Two duplicate work orders were created.” These failures are hard to spot if you only read the last paragraph of the conversation.

anthropicintelligent body评测指南强调，要区分运行过程记录和环境中的最终结果，并通过多次尝试观察表现，而不是只看一次成功演示。Agent Evaluation Guide

Therefore, the test can include several conditions that are less “demonstration-friendly”: the tool returns an empty result, the write operation succeeds but the response is lost, the user changes their mind midway, or the data is contradictory. A good system doesn’t necessarily have to continue every time; it should also know when to stop, when to check the original result, and when to clearly indicate that the process is not yet complete.

For AI systems that operate on an operating system, reliably acknowledging failure is often more valuable than confidently adding the phrase “Done.”

Simulated testing is useful, but it cannot replace actual acceptance testing.

The advantage of setting up a test company is that you can control the conditions. The team can simulate an expiration policy, a departmental reorganization, or an ambiguous request, and then observe whether the system responds as expected; they can also repeat the same set of tasks before and after an upgrade, thereby reducing debates over whether the system “seems to have gotten smarter.”

However, the simulated data may be too uniform, and simulated employees may be more likely than real employees to finish their sentences. Models used to generate test questions and grading criteria may also favor certain types of expressions.

A 2025 RAG study found that, across four datasets, synthetic tests were more reliable for comparing different retrieval configurations, but did not consistently yield reliable rankings when comparing different generative model architectures. While these are the results of a specific experiment, they serve as a reminder that:Whether a test is suitable for answering a particular type of question also needs to be verified.Research Paper

A reasonable approach is to have synthetic testing handle repeatable boundary checks, use authorized and appropriately anonymized real-world test cases to verify business applicability, and then fill in any gaps with post-deployment error logs. These three methods cross-validate one another, which is more important than simply pursuing a larger test case library on its own.

Small teams don't need to set up a testing platform right away.

Here’s a lightweight approach to get started—this is not a step-by-step guide for the Microsoft platform: First, choose a common scenario, such as looking up policies, organizing meeting agenda items, or generating internal work orders. Collect a dozen to several dozen representative tasks, and clearly define for each one “what you should find, what the output should be, and what is not allowed.”

The test set can be divided into four groups:

• Regular Tasks: With all the information provided, can you give us a result that’s ready to use?
• Border Mission: If there are files with the same name, different versions, or missing conditions, can you distinguish between them or ask for clarification?
• Decline the task: If there is no authority, no evidence, or if the action exceeds one’s duties, can it be properly halted?
• Faulty Tasks: In the event of a retrieval failure, API timeout, or partial success, can the actual status be indicated to prevent duplicate operations?

Scoring doesn’t have to be complicated from the start. Recording “Completed,” “Requires Manual Correction,” or “Failed”—along with the time taken, cost, and cause of the error—is more useful than simply saving screenshots of successful runs. Important tasks should be rerun; failures involving permissions, commitments, or writes should be listed separately as release blockers so that high scores from easier tasks don’t skew the average.

Every time you switch models, modify prompts, or adjust retrieval rules, rerun this set of tasks. Turn any newly discovered genuine failures into a reproducible test case. In this way, the test suite becomes a continuously growing repository of business experience, rather than just an attachment to a one-time model selection presentation.

What we should really be comparing is “the cost of completing a single task.”

Ultimately, what companies care about is usually not how fast a single response is or how cheap it is per thousand tokens, but rather the total cost of completing a deliverable: AI calls, employee verification, retries in case of failure, and any necessary manual intervention.

This is also a more pragmatic approach to selecting a model: first, determine whether it can maintain business boundaries; second, assess the quality of task completion; and finally, compare speed and cost. Different roles may require different configurations, and there is no need to make all tasks conform to a single, comprehensive ranking.

Rankings are still valuable; they help teams narrow down the pool of candidates. However, when it comes to the final stage of onboarding—the final offer—it should be based on the candidate’s actual work samples.