Evaluations | The .NET Blog

Evals для model router — это шаг, который слишком многие команды пропускают

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Эта статья была автоматически переведена. Для оригинальной версии, нажмите здесь.

Автоматическая маршрутизация моделей звучит отлично, пока вы не понимаете, что вам всё ещё нужно доказать, что это правильный выбор для вашей workload.

Именно поэтому новый model router evaluation repo полезен.

Он даёт командам более конкретный способ ответить на вопросы, которые действительно важны:

сохраняет ли routing качество?
улучшает ли он стоимость?
что он делает с задержкой?
что меняется, если я ограничиваю подмножество моделей?

Исходная статья задаёт правильные вопросы

Одна вещь, которая мне особенно нравится в исходной публикации, — это то, что model router не рассматривается как что-то заведомо хорошее.

Вместо этого задаются неудобные, но правильные вопросы:

“На моих prompts автоматически выбранный model от model router равен или лучше single model, который я бы иначе выбрал?”
“Я действительно экономлю деньги end to end, или я просто перемещаю расходы из одного места в другое?”

Это именно правильный подход.

Потому что автоматическая маршрутизация привлекательна, но это всё равно системное решение. А системные решения нужно измерять, а не восхищаться ими.

Почему этот repo важнее, чем кажется на первый взгляд

На одном уровне это просто evaluation repo.

На другом — это признак зрелости.

Он говорит: если вы хотите внедрять автоматическую маршрутизацию, вот более дисциплинированный способ тестировать:

качество
стоимость
задержку
компромиссы подмножества
поведение распределения моделей

Это гораздо лучше, чем рассматривать routing как чёрный ящик с хорошим брендингом.

Моё мнение

Это хороший пример того, в чём AI platform нуждаются всё больше: не в большей магии, а в большем количестве способов проверять эту магию до того, как вы ей поверите.

Именно так команды избегают построения дорогого доверия на непроверенных предположениях.

Оригинальная статья: How to run evals for the model router

Сложная часть разработки ИИ уже не в доступе. Она в том, чтобы хорошо работать с правильной моделью

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Эта статья была автоматически переведена. Чтобы открыть оригинал, нажмите здесь.

Мы уже давно прошли этап, когда одного лишь доступа к мощной модели было достаточно.

Именно это новый гид Foundry по управлению моделями, стоимостью и качеством понимает правильно.

Настоящая задача теперь операционная:

выбирать правильную модель для каждой нагрузки
проверять её на собственных данных
управлять задержкой и расходами
контролировать обновления и риск регрессий

Именно в этом серьезные команды должны научиться быть хорошими.

Исходная статья правильно формулирует проблему

Одна фраза из оригинального поста очень точно передаёт этот сдвиг:

“Самая сложная часть построения AI-систем сегодня уже не в том, чтобы получить доступ к способной модели. Она в том, чтобы знать, как выбирать, проверять, оптимизировать и эксплуатировать правильную модель на всём жизненном цикле реального приложения.”

Это совершенно правильный диагноз.

Слишком многие команды до сих пор думают, что выбор модели — это главное решение.

Это не так.

Более крупная проблема — эксплуатация модели:

какая нагрузка получает какую модель?
как проверяется качество?
какая форма стоимости допустима?
что происходит, когда появляется новая модель или старая начинает дрейфовать?
как протестировать изменение, не ломая реальные workflow?

Вот где сейчас настоящая инженерная работа.

Почему этот материал Foundry полезен

Мне нравится эта статья, потому что она говорит об AI-системах так, как действительно приходится думать опытным платформенным инженерам.

Не как “выбери самую умную модель и двигайся дальше”.

А как о системах, живущих под компромиссами:

capability
latency
cost
safety
governance
давление обновлений

Это гораздо полезнее, чем оптимизм, основанный только на бенчмарках.

Самый важный сдвиг — сначала думать о критериях

В оригинальном посте рекомендуется определить критерии успеха до открытия каталога моделей.

Я думаю, что это одна из самых важных привычек, которые команды могут выработать.

Если сначала открыть каталог, вы якоритесь на репутации.

Если сначала определить критерии, вы якоритесь на реальности нагрузки.

Это более здоровый процесс.

Потому что модель, которая выигрывает бенчмарк, не обязательно выигрывает в:

ваших prompt’ах
вашем бюджете на latency
ваших cost guardrails
ваших требованиях к governance

Это различие и есть точка начала зрелой AI-инженерии.

История multi-model становится реальным преимуществом

Ещё одна вещь, которая мне нравится, — явно модель-агностичный подход.

Статья показывает Foundry не как цель для одной модели, а как операционную поверхность поверх:

моделей Microsoft
моделей партнёров
open-source моделей
post-trained вариантов
стратегий routing и optimization

Это важно, потому что гибкость моделей больше не роскошь. Это часть управления риском.

Если качество меняется, цены двигаются или квоты сжимаются, командам нужны варианты.

Контроль затрат — не второстепенная тема

Статья также права, когда рассматривает стоимость как архитектурную проблему.

Это не задача формата “потом оптимизируем”.

Если по умолчанию отправлять каждую задачу в самый тяжёлый model, в демо это может работать отлично, а в экономике production — развалиться.

Поэтому я считаю, что разделы о:

routing
batching
caching
provisioned throughput
управлении quota

важнее, чем может показаться многим.

Команды, которые воспринимают дисциплину затрат как часть системного дизайна, будут жить намного лучше, чем те, кто видит в ней позднюю уборку.

Моё мнение

Это полезный материал Foundry, потому что он говорит об AI-системах так, как их действительно приходится эксплуатировать опытным инженерам.

Не как о демо. Не как об одноразовых прототипах. И не как о туризме по лидербордам.

А как об операционных системах для нагрузок, ограничений, компромиссов и постоянных изменений.

Нам нужно продолжать поднимать разговор до этого уровня.

И если вы строите production AI systems, то именно такой mindset командам стоит усвоить как можно раньше.

Оригинальная публикация: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

История Foundry от наблюдаемости до ROI — это именно то, что нужно серьезным платформам агентов

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

Эта статья была автоматически переведена. Чтобы открыть оригинал, нажмите здесь.

Если AI-агенты должны жить в production, наблюдаемость не может заканчиваться на логах и trace’ах.

Именно поэтому новая история Foundry от наблюдаемости до ROI кажется важной.

Настоящий смысл не в том, что «мы добавили больше дашбордов».

Настоящий смысл в том, что серьезным платформам агентов нужен непрерывный операционный цикл:

отслеживать, что произошло
оценивать, было ли это хорошо
оптимизировать то, что требует доработки
связывать результат с бизнес-ценностью

Это куда более сильная история, чем обычные платформенные общие слова.

Ключевая фраза из исходной статьи говорит сама за себя

Оригинальный пост начинается с фразы, на которую, по-моему, должна обратить внимание каждая команда, создающая агентов:

“Запустить AI-агента — это легкая часть. Удержать его точным, безопасным и подотчетным в production — это то место, где команды застревают.”

Это абсолютно верно.

Мы уже прошли этап, когда главный вопрос звучал так: “могу ли я заставить агента сделать что-то классное?”

Более сложный и более ценный вопрос таков:

могу ли я управлять системой, когда она начинает взаимодействовать с реальными пользователями, реальными инструментами и реальными затратами?

Именно в эту сторону Foundry пытается сдвинуть разговор.

Почему это важнее, чем еще одна демонстрация агента

Многие объявления об AI-агентах по-прежнему сосредоточены на создании: собери агента, подключи инструменты, направляй задачи, публикуй интерфейс.

Все это нормально.

Но операционные вопросы — это то место, где большинство серьезных систем либо становятся устойчивыми, либо превращаются в дорогие эксперименты:

что агент на самом деле делает в production?
делает ли он правильные вещи?
становится ли он хуже со временем?
не слишком ли он дорог по сравнению с создаваемой ценностью?
какие изменения конфигурации действительно улучшили качество?

Поэтому я считаю, что объявление Foundry важнее обычного обзора функций. Оно пытается определить цикл Agent DevOps, а не просто историю создания агента.

Цикл из четырех частей — это и есть реальный продукт

Статья по сути организует платформу вокруг четырех возможностей:

Trace
Evaluate
Monitor
Optimize

Это правильная форма.

Я бы даже сказал, что любой платформе, которую хотят воспринимать всерьез при production workloads агентов, в итоге понадобятся все четыре.

Tracing сам по себе недостаточен.

Оценки сами по себе недостаточны.

Оптимизация без доказательств — это просто догадки.

А разговоры о ROI без telemetry обычно превращаются в театр.

Аспект совместимости особенно умен

Одно из самых сильных решений в объявлении — Foundry не делает вид, будто все агенты будут построены в одном framework.

В исходном посте прямо говорится о том, что tracing и evals распространяются на:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
кастомные frameworks через OpenTelemetry

Это важно.

Потому что platform lock-in — один из самых быстрых способов сделать изначально полезную историю эксплуатации менее привлекательной.

Если команды могут сохранить выбор framework и при этом получить telemetry и поверхности оценки уровня production, трение заметно снижается.

Rubric evaluation может оказаться важнее, чем многие ожидают

Стоит отметить и часть про rubric evaluation.

Я думаю, это одно из самых практичных дополнений во всем посте.

Почему? Потому что «хорошо» зависит от контекста.

В статье говорится, что rubric evaluation генерирует “context-aware evaluation criteria из предполагаемого поведения вашего агента”. Именно в этом направлении и должны двигаться такие системы.

Общее оценивание качества полезно.

Но в итоге командам нужно оценивать агентов по своим стандартам:

тон
выполнение задач
соблюдение политик
ожидания по задержке
границы затрат
доменные бизнес-правила

Именно здесь evaluation становится операционно значимым, а не просто академически интересным.

ROI — самая неудобная часть, и именно поэтому она важна

Я также думаю, что часть про ROI важна именно потому, что она неудобна.

Пост напрямую задает вопрос:

“стоит ли этот агент своих затрат?”

В разговорах об AI этот вопрос часто обходят.

Но это правильный вопрос.

Если платформа действительно может связать cost, task completion, сэкономленное время и production traces в одном месте, это дает engineering и leadership гораздо лучший общий язык.

И, честно говоря, такой общий язык очень нужен.

Мое мнение

Это одно из лучших platform-level объявлений в этом наборе, потому что оно фокусируется на эксплуатации агентов, а не только на их создании.

И именно с этого начинается самая трудная работа.

Самые сильные AI-платформы ближайших лет будут не просто теми, у кого есть доступ к большему числу моделей или большему числу демонстраций. Это будут те платформы, которые помогают командам отслеживать поведение, оценивать результаты, безопасно оптимизировать и обосновывать стоимость доказательствами.

Эта история Foundry пытается двигаться именно в эту сторону.

Поэтому к ней стоит отнестись серьезно.

Оригинальный пост: Build 2026: From observability to ROI for AI agents on any framework