Skip to content

part8-evaluation-led-development.md

Latest commit

 

History

History
293 lines (205 loc) · 17.4 KB

part8-evaluation-led-development.md

File metadata and controls

293 lines (205 loc) · 17.4 KB
Raw

Foundry Local

Часть 8: Разработка, ориентированная на оценку, с Foundry Local

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

Почему разработка на основе оценки?

При создании AI-агентов «выглядит нормально» — это недостаточно. Разработка, ориентированная на оценку, рассматривает выводы агента как код: сначала пишутся тесты, затем измеряется качество, и выпуск происходит только при достижении порога оценок.

В Zava Creative Writer (Часть 7) агент Editor уже выступает в роли лёгкого оценщика; он принимает решение ACCEPT или REVISE. Эта лабораторная работа формализует этот шаблон в воспроизводимый фреймворк оценки, который можно применять к любому агенту или пайплайну.

Проблема Решение
Изменения в подсказках тайно ухудшают качество Золотой набор данных обнаруживает регрессии
Смещение «работает на одном примере» Несколько тестовых случаев выявляют крайние случаи
Субъективная оценка качества Правила + оценка судьи на базе LLM дают числовые показатели
Нет способа сравнить варианты подсказок Параллельные прогонки с агрегированными оценками

Ключевые понятия

1. Золотые наборы данных

Золотой набор данных — это куратированный набор тестовых случаев с известными ожидаемыми результатами. Каждый тестовый случай включает:

  • Вход: Подсказка или вопрос для агента
  • Ожидаемый результат: Что должен содержать правильный или качественный ответ (ключевые слова, структура, факты)
  • Категория: Группировка для отчётности (например, «фактическая точность», «тон», «полнота»)

2. Правила проверки (Rule-Based Checks)

Быстрые, детерминированные проверки, не требующие LLM:

Проверка Что проверяет
Ограничения по длине Ответ не слишком короткий (ленивый) и не слишком длинный (болтливый)
Обязательные ключевые слова В ответе упомянуты ожидаемые термины или сущности
Валидация формата JSON парсится, присутствуют заголовки Markdown
Запрещённый контент Нет выдуманных названий брендов, нет упоминаний конкурентов

3. LLM как судья

Используйте ту же локальную модель для оценки собственных выводов (или выводов с другим вариантом подсказки). Судья получает:

  • Исходный вопрос
  • Ответ агента
  • Критерии оценки

И возвращает структурированную оценку. Это отражает шаблон Editor из Части 7, но применяется системно ко всей тестовой базе.

4. Цикл итеративной доработки на основе оценки

Eval-driven iteration loop

Требования

Требование Детали
Foundry Local CLI Установлен с загруженной моделью
Среда выполнения Python 3.9+ и/или Node.js 18+ и/или .NET 9+ SDK
Завершено Часть 5: Отдельные агенты и Часть 6: Многоагентные рабочие процессы

Лабораторные задания

Задание 1 - Запуск фреймворка оценки

В рамках воркшопа приведён полный пример оценки, который тестирует агента Foundry Local на золотом наборе вопросов, связанных с Zava DIY.

🐍 Python

Настройка:

cd python
python -m venv venv

# Windows (PowerShell):
venv\Scripts\Activate.ps1
# macOS:
source venv/bin/activate

pip install -r requirements.txt

Запуск:

python foundry-local-eval.py

Что происходит:

  1. Подключение к Foundry Local и загрузка модели
  2. Определение золотого набора из 5 тестовых случаев (вопросы о продуктах Zava)
  3. Запуск двух вариантов подсказок на каждом тестовом случае
  4. Оценка каждого ответа с помощью проверок по правилам (длина, ключевые слова, формат)
  5. Оценка каждого ответа LLM как судья (та же модель выставляет оценку качества от 1 до 5)
  6. Вывод сравнительной таблицы результатов для обоих вариантов подсказок
📦 JavaScript

Настройка:

cd javascript
npm install

Запуск:

node foundry-local-eval.mjs

Та же пайплайн оценки: золотой набор, двойной прогон подсказок, оценка по правилам + LLM, таблица результатов.

💜 C#

Настройка:

cd csharp
dotnet restore

Запуск:

dotnet run eval

Та же пайплайн оценки: золотой набор, двойной прогон подсказок, оценка по правилам + LLM, таблица результатов.

Задание 2 - Изучение золотого набора данных

Изучите тестовые случаи, определённые в примере оценки. Каждый тестовый случай содержит:

{
  "input":    "What tools do I need to build a deck?",
  "expected": ["saw", "drill", "screws", "level"],
  "category": "product-recommendation"
}

Вопросы для размышления:

  1. Почему ожидаемые значения — это ключевые слова, а не полные предложения?
  2. Сколько тестовых случаев нужно для надежной оценки?
  3. Какие категории вы бы добавили для собственного применения?

Задание 3 - Понять отличие оценки по правилам и LLM как судьи

В фреймворке используются два слоя оценки:

Проверки по правилам (быстрые, детерминированные)

✓ Length: 50-500 words       → 1 point
✓ Keywords: 3/4 found        → 0.75 points  
✗ Forbidden: mentions "Home Depot" → 0 points
─────────────────────────────
Rule score: 0.58 / 1.0

LLM как судья (тонкая, качественная оценка)

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

Rate this response on a scale of 1-5:
- 1: Completely wrong or irrelevant
- 2: Partially correct but missing key information
- 3: Adequate but could be improved
- 4: Good response with minor issues
- 5: Excellent, comprehensive, well-structured

Score: 4
Reasoning: The response correctly identifies all necessary tools
and provides practical advice, but could include safety equipment.

Вопросы для размышления:

  1. Когда вы бы доверяли проверкам по правилам больше, чем LLM как судье?
  2. Может ли модель надежно оценивать собственный вывод? Каковы ограничения?
  3. Как это сравнить с паттерном Editor из Части 7?

Задание 4 - Сравнение вариантов подсказок

В примере запускаются два варианта подсказок на одних и тех же тестах:

Вариант Стиль системной подсказки
Базовый Общий: "Вы — полезный помощник"
Специализированный Детальный: "Вы — эксперт Zava DIY, который рекомендует конкретные продукты и даёт пошаговые инструкции"

После запуска вы увидите такую таблицу оценок:

╔══════════════════════════════════════════════════════════════╗
║                    EVALUATION SCORECARD                      ║
╠══════════════════════════════════════════════════════════════╣
║ Prompt Variant    │ Rule Score │ LLM Score │ Combined       ║
╠═══════════════════╪════════════╪═══════════╪════════════════╣
║ Baseline          │ 0.62       │ 3.2 / 5   │ 0.62           ║
║ Specialised       │ 0.81       │ 4.1 / 5   │ 0.81           ║
╚══════════════════════════════════════════════════════════════╝

Задания:

  1. Запустите оценку и отметьте результаты для каждого варианта
  2. Сделайте специализированную подсказку ещё более конкретной. Улучшается ли оценка?
  3. Добавьте третий вариант подсказки и сравните все три.
  4. Попробуйте поменять псевдоним модели (например, phi-4-mini против phi-3.5-mini) и сравните результаты.

Задание 5 - Примените оценку к своему агенту

Используйте фреймворк оценки как шаблон для своих агентов:

  1. Определите свой золотой набор данных: напишите 5-10 тестовых случаев с ожидаемыми ключевыми словами.
  2. Напишите системную подсказку: инструкции для агента, которые хотите проверить.
  3. Запустите оценку: получите базовые оценки.
  4. Итеративно улучшайте: корректируйте подсказку, запускайте заново и сравнивайте.
  5. Установите порог: например, «не выпускать результат с общим баллом ниже 0.75».

Задание 6 - Связь с паттерном Editor Zava

Вернитесь к агенту Editor из Zava Creative Writer (zava-creative-writer-local/src/api/agents/editor/editor.py):

# Редактор является LLM в роли судьи в продакшене:
{"decision": "accept/revise", "editorFeedback": "...", "researchFeedback": "..."}

Это тот же принцип, что и LLM как судья в Части 8, но встроенный в рабочий пайплайн, а не в оффлайн тестовый набор. Оба паттерна:

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

Отличие: Editor работает в продакшене (на каждом запросе). Фреймворк оценки работает в разработке (до выпуска).

Основные выводы

Понятие Вывод
Золотые наборы данных Создавайте тесты заранее; они — ваши регрессионные тесты для AI
Проверки по правилам Быстрые, детерминированные, ловят очевидные ошибки (длина, ключевые слова, формат)
LLM как судья Тонкая оценка качества с использованием той же локальной модели
Сравнение подсказок Запускайте несколько вариантов на одном тестовом наборе, чтобы выбрать лучший
Преимущество локального запуска Вся оценка выполняется локально: нет затрат на API, лимитов скорости, данные не покидают устройство
Оценка до выпуска Устанавливайте пороги качества и блокируйте релизы по результатам оценки

Следующие шаги

  • Масштабируйтесь: добавьте больше тестов и категорий в золотой набор.
  • Автоматизируйте: интегрируйте оценку в ваш CI/CD.
  • Продвинутые судьи: используйте крупную модель в роли судьи при тестировании вывода более маленькой.
  • Отслеживайте динамику: сохраняйте результаты оценки для сравнения между версиями подсказок и моделей.

Следующая лабораторная работа

Продолжайте с Части 9: Распознавание голоса с Whisper, чтобы изучить преобразование речи в текст локально с использованием Foundry Local SDK.

Отказ от ответственности:
Этот документ был переведен с использованием сервиса автоматического перевода Co-op Translator. Несмотря на наши усилия обеспечить точность, имейте в виду, что автоматические переводы могут содержать ошибки или неточности. Оригинальный документ на его исходном языке следует считать авторитетным источником. Для важной информации рекомендуется обращаться к профессиональному переводу, выполненному человеком. Мы не несем ответственности за любые недоразумения или неверные толкования, возникшие в результате использования этого перевода.