Как тестировать Foundation Models Evaluations? Руководство по iOS AI 2026

Обычный тест хорошо проверяет то, что можно выразить чётким условием: функция вернула ожидаемое значение, ошибка обработана, нужная ветка кода выполнена. Для генеративной функции этого недостаточно. Два ответа могут различаться по формулировкам, но оба выполнять задачу; а внешне гладкий ответ может пропустить обязательное условие или выбрать неподходящее действие.

Apple описывает Evaluations как средство измерения качества интеллектуальных функций. В документации рамки Evaluations ключевыми элементами выступают набор данных, критерии оценки и анализ результатов. Это задаёт другой уровень проверки: не «выполнился ли код», а «какое поведение получено на представительных входах и насколько оно соответствует заданным требованиям».

Разделяйте уровни проверок:

• Детерминированный тест подтверждает конкретное условие в логике приложения. Например, после неуспешной генерации интерфейс показывает предусмотренное состояние.
• Оценка модели проверяет качество ответа или поведения на наборе примеров. Она может выявить типичный сбой, но не доказывает, что любой будущий ответ будет правильным.
• Агрегированный результат помогает увидеть общую картину по набору. Он не объясняет сам по себе, почему конкретный пример прошёл или провалился.
• Ручная проверка нужна для спорных случаев, неоднозначных требований и проверки того, что метрика действительно отражает интерес пользователя.

В видео Apple о Evaluations на WWDC26 рамка рассматривается как часть разработки и проверки интеллектуальных функций, а не как замена тестированию приложения. Практический вывод: сначала сформулируйте поведение, которое важно продукту, затем выберите подходящую оценку. Не начинайте с красивого числового показателя и не ищите ему применение постфактум.

Если вы меняете подсказку, модель или настройку генерации, оценивайте варианты на одинаковых примерах и по одинаковым правилам. Иначе различие может объясняться не изменением конфигурации, а тем, что в каждом запуске использовались разные входы или критерии. Документация Apple описывает Evaluations как способ сравнивать стратегии и отслеживать изменение качества; это не превращает единичную разницу ответа в универсальный вывод.

Перед сравнением зафиксируйте, что именно меняется. Если одновременно переписать подсказку, изменить набор данных и поменять критерий, вы не поймёте, какая причина повлияла на результат. Для первого сравнения оставьте неизменными входы и оценщик. Отдельно записывайте конфигурацию, идентификатор сборки и важные настройки, чтобы позднее воспроизвести проверку.

Не выбирайте «победителя» только по сводному баллу. Если один вариант улучшил типичные случаи, но стал чаще нарушать критичное ограничение, продуктовый риск может возрасти. Откройте примеры, повлиявшие на итог, и классифицируйте ошибки: неверное содержание, пропуск обязательной информации, неверное решение о вызове инструмента, некорректный итоговый ответ. Для каждой категории решите, является ли она блокирующей, допустимой или требующей дополнительной проверки.

Маленький и однородный набор легко даёт обманчивое ощущение стабильности. Если все примеры короткие, хорошо сформулированы и содержат ожидаемый ответ прямо в запросе, тест почти не проверяет ситуации, которые создают проблемы пользователям. Apple отдельно рассматривает проектирование наборов данных для оценки. Используйте это руководство, чтобы продумать состав данных и назначение каждого примера, а не просто увеличить их количество.

Соберите примеры из нескольких источников: реальные пользовательские формулировки, известные обращения в поддержку, внутренние сценарии команды и вручную созданные пограничные случаи. Удалите или преобразуйте чувствительные данные перед включением в набор. Для каждого примера подпишите, какое требование он проверяет и какой тип сбоя должен обнаружить. Если вы не можете объяснить назначение примера, он может не давать полезной проверки.

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

Для метрик задайте границы применимости:

• Если результат должен содержать определённые элементы, проверяйте наличие и корректность каждого важного элемента.
• Если допустимы несколько формулировок, избегайте критерия, который считает правильным только совпадение с единственной фразой.
• Если требуется безопасно отказать или запросить уточнение, включите случаи, где отказ уместен, и где он мешает выполнению обычной задачи.
• Если команда использует автоматический оценщик, проверьте его на примерах, размеченных человеком, включая ошибочные и пограничные ответы.

Ни одна метрика не становится подходящей только потому, что её просто вычислять. Оценщик должен отражать требования функции. Если он выдаёт положительную оценку ответу, который нарушает важное продуктовое правило, измените критерий или добавьте отдельную проверку. Не маскируйте этот недостаток повышением агрегированного показателя на лёгких примерах.

Функция с инструментами может успешно сформировать убедительный финальный текст после неверного выбора действия. Поэтому конечный ответ — не единственная цель оценки. В сценариях вызова инструмента отдельно проверяйте, нужно ли было вызывать инструмент, какой инструмент был выбран, какие существенные параметры переданы и соответствует ли итог результату выполненного действия.

В документации Apple по оценке поведения при вызове инструментов описан отдельный подход к проверке такого поведения. Примените его к архитектуре своей функции: укажите ожидаемое действие для каждого примера и критерии, по которым вы сочтёте траекторию допустимой. Если важны порядок действий или промежуточное решение, отразите это в оценке, а не пытайтесь вывести правильность процесса из одного финального ответа.

В набор включайте противоположные случаи: когда инструмент нужен, когда его вызывать не следует, когда вход недостаточен и когда несколько действий выглядят правдоподобно. На неоднозначных случаях определите допустимое множество поведения или предусмотрите ручную проверку. Жёсткое ожидание единственного пути может ошибочно пометить приемлемое решение как провал; слишком свободное ожидание, наоборот, пропустит опасный или бессмысленный вызов.

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

Официальная документация EvaluationTrait описывает интеграцию оценок с Swift Testing. Используйте актуальный пример Apple для своей версии Xcode и проверьте, что оценочная цель включена в тот тестовый процесс, который команда действительно запускает. Это помогает хранить оценочные сценарии рядом с тестами приложения и просматривать результаты в привычном цикле разработки.

До интеграции проверьте совместимость проекта и инструментов. Apple выпустила Xcode 27.1 15 октября 2026 года — сверьте фактическую версию среды с официальными требованиями Xcode, а не переносите инструкцию из другого набора SDK без проверки. Требования и доступность возможностей зависят от используемой версии инструментов и целевой системы. Не делайте вывод о поддержке только по тому, что проект открывается или компилируется.

Используйте такой порядок внедрения:

• Сформулируйте требование. Запишите, что должен получить пользователь и какие ошибки недопустимы. Разделите требования к содержанию, формату, инструментам и обработке отказов.
• Создайте небольшой начальный набор. Возьмите разнообразные входы и обозначьте, что каждый из них проверяет. Не принимайте искусственно лёгкий набор за представительную выборку.
• Определите оценщик. Выберите критерии для каждого требования. Для неоднозначных результатов обозначьте необходимость ручной проверки.
• Подключите оценку к тестовой цели. Следуйте документации Evaluations и примерам Swift Testing для используемой среды. Сохраните команду или схему запуска вместе с проектной документацией.
• Выполните проверку и разберите детали. Сопоставьте отчёт и агрегированный результат с отдельными примерами. Зафиксируйте, какие случаи требуют исправления или пересмотра критерия.
• Сравните изменения на тех же данных. При смене подсказки или конфигурации оставьте неизменными набор и правила оценки. Новые примеры добавляйте отдельно, чтобы понимать причину изменения результата.
• Проверьте воспроизводимость. Сохраните данные, настройки и контекст запуска так, чтобы команда могла повторить оценку и объяснить расхождения.

Не вводите универсальный порог прохождения для всех приложений. Порог должен вытекать из риска конкретной функции и значимости ошибки. Для функции, где неверный ответ нарушает критичное требование, среднего хорошего результата может быть недостаточно. Для функции с вариативными формулировками единичное отличие от образца не обязательно означает провал. Запишите правило принятия решения и подтвердите его на примерах, которые важны продукту.

Как запустить оценочную проверку в проекте

Подключите Evaluations к Swift Testing по официальной документации и примерам для используемой версии Xcode. Затем убедитесь, что тестовая цель собирается и выполняется в подходящей macOS-среде. Читайте отчёт на двух уровнях: отдельные примеры показывают конкретные сбои, а агрегированные данные помогают отслеживать общую динамику. Обычные утверждения теста остаются отдельным инструментом для логики приложения.

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

Начните с продуктового требования, а не с доступного оценщика. Проверьте, отличает ли критерий приемлемые варианты от существенных ошибок, особенно на пограничных входах. Сопоставьте автоматическую оценку с ручной разметкой на репрезентативных случаях. Если критерий принимает некорректное поведение, пересмотрите его; общий показатель не компенсирует метрику, которая не соответствует задаче.

Как сравнивать подсказки без ложного вывода о регрессии

Используйте одинаковые входы, оценщики и правила интерпретации. Зафиксируйте конфигурацию и результаты исходного запуска, а затем повторите проверку после изменения. Разбирайте примеры с изменившимся результатом отдельно от общей сводки. Одна разница не доказывает системный эффект; вывод о регрессии должен опираться на повторяемое изменение в значимых сценариях и проверку причин.

Какие случаи добавить для агента с инструментами

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

Фактический запуск оценок требует Xcode и совместимой среды macOS. Если вы уже регулярно запускаете тесты на собственном Mac и команда может повторять проверку в стабильном окружении, отдельная удалённая машина может не дать достаточной пользы. Если же локального Mac нет, устройство занято повседневной работой или вы хотите держать доступную среду для регулярных запусков, сравните локальную схему с удалённой.

Перед переносом проекта проверьте не обещания окружения, а собственный процесс. Убедитесь, что тестовая цель доступна, входные данные и конфигурация сохранены, а отчёт можно связать с конкретным запуском. Сделайте пробный запуск на реальном проекте и проверьте, что результат можно разобрать и повторить. Требования к версии Xcode и системе сверяйте с официальной страницей системных требований; не переносите неподтверждённые ожидания на любой удалённый хост.

Локальный Mac даёт прямой контроль над устройством и не зависит от сетевого подключения, но требует наличия подходящего оборудования и его обслуживания. Удалённая среда позволяет не покупать Mac специально для периодической работы с Xcode, однако добавляет зависимость от сети и условий доступа. Если вы выбираете такой вариант, сравните условия и стоимость удалённого Mac, а затем заранее проверьте сценарий доступа и запуска тестов в своём проекте. Здесь не следует обещать конкретную конфигурацию или результат оценки без фактической проверки именно вашей задачи.

Для воспроизведения оценок важны не только доступ к Xcode, но и контроль тестового набора, параметров, тестовой цели и отчёта. Если эти элементы невозможно сохранить или повторно проверить, смена компьютера не решит проблему воспроизводимости. Начните с локального запуска и документируйте его; затем переносите тот же сценарий, а не упрощённую демонстрацию.

Главный компромисс — между покупкой и обслуживанием собственного Mac, зависимостью от сетевого доступа к удалённой среде и ограничениями локальной машины по доступности для регулярных запусков. Для разовой проверки может хватить уже имеющегося компьютера. Если Mac нужен временно для Xcode и повторных проверок, аренда Mac через CALMVPS позволяет получить macOS-среду без покупки отдельного устройства; перед выбором изучите доступные варианты CALMVPS и подтвердите на своём проекте, что тестовый цикл действительно воспроизводится.