Разговор о программировании смыслов ценен тем, что смещает акцент с ручного описания алгоритма на проектирование поведения системы.
Глава показывает, как намерения, ограничения, циклы оценивания и модель вознаграждения становятся рабочим инженерным контуром AI-продукта, а не побочной настройкой вокруг модели.
Для архитектурного разбора это сильный материал, чтобы обсуждать проектирование полезности, продуктовую семантику и ту часть AI-архитектуры, которая обычно не видна на сервисной диаграмме.
Практическая польза главы
Проектирование поведения
Глава помогает обсуждать AI-продукт не только через код и модели, но и через намерения, ограничения и рабочий цикл оценивания.
Контур качества
Через этот кейс удобно разбирать, как продуктовые правила, модель вознаграждения и оценивание складываются в единый цикл улучшений.
Инженерия полезности
Материал хорошо показывает, что полезность AI-системы проектируется и измеряется, а не появляется автоматически из сильной модели.
Материал для интервью
Это сильный кейс, чтобы обсуждать продуктовую семантику, проектирование вознаграждения и наблюдаемость AI-функции.
Программирование смыслов от Алексея Гусакова (CTO Yandex)
Разбор доклада Алексея Гусакова: когда вручную прописать алгоритм уже не получается, инженер перестаёт описывать шаги и начинает задавать намерения, ограничения, циклы оценивания и границы полезного поведения системы.
Источник
Telegram: Книжный куб
Обзор доклада с инженерными и продуктово-архитектурными выводами.
Что такое «программирование смыслов»
Поведение модели нельзя дописать кодовыми ветками до конца: его задают намерениями, ограничениями, контекстом знаний, инструментами и метриками успеха. Это и есть предмет проектирования, а не побочный эффект кода.
Цена такого сдвига — отказ от единственной поставки «идеального алгоритма». Ценность набирается по шагам цикла гипотеза → прототип → измерение → дообучение → интеграция, и каждый шаг нужно уметь измерить, иначе улучшать нечего.
Как менялся подход
2022: «Гуру по товарам» и первые ошибки
Диалоговый помощник для выбора товаров быстро показал границу: «опросник под видом диалога» раздражает пользователя. Эти ошибки оказались полезнее успехов — из них стало видно, какой сценарий реально помогает человеку.
Поворот после выхода ChatGPT
Соблазн был сделать «большой магический релиз». Команда выбрала обратное: улучшать существующую выдачу маленькими проверяемыми шагами, где каждый шаг можно откатить и измерить.
Ответы с опорой на структурированные источники
Чтобы ответ можно было проверить, модель сначала планирует, какие документы взять, и собирает ответ из проверяемых фрагментов. Без этой опоры она «генерирует из воздуха» — и цена ошибки растёт.
Система ограничений вместо одной метрики
Одна метрика всегда обманывает: её можно накрутить. Качество держат набором правил и метрик сразу — фактическая точность, длина ответа, персонализация, разнообразие и запрет на вымышленные факты.
Повторяемый цикл обучения
Ответы оценивают люди и автоматические проверки, по результатам обновляют генеративную модель и модель вознаграждения, а затем снова сверяют изменения с реальной обратной связью. Контур замкнут — иначе улучшения не накапливаются.
Оркестрация нескольких моделей
Базовые веса трогать не обязательно: качество растёт за счёт контура из нескольких моделей, инструментов и дополнительных вычислений. Это дешевле полного дообучения и даёт отдачу быстрее.
Связанная глава
AI Engineering
Как провести AI-продукт через весь жизненный цикл в рабочем контуре, а не только обучить модель.
Рабочий цикл улучшения модели
1. Оценка
Ответы размечиваются и ранжируются людьми и автоматическими оценщиками.
2. Обучение
Обновляются генеративная модель и модель вознаграждения.
3. Выкатка
Изменения уходят в онлайн-эксперименты и A/B-тесты.
4. Обратная связь
Метрики и обратная связь запускают следующий цикл улучшений.
Типовые проблемы и исправления
Оптимизация под оценщик вместо пользы
Симптом: Модель учится не помогать, а нравиться проверке: удлиняет ответы, копирует источники и навешивает оговорки. Метрика растёт, польза для пользователя — нет.
Фикс: Ограничения по длине, штрафы за копипасту и канцелярит, настройка стиля и оговорки только там, где они действительно меняют решение пользователя.
Нечёткие продуктовые требования
Симптом: Инструкция уровня «будь умным и полезным» звучит хорошо, но не превращается в стабильный продуктовый результат и воспроизводимый контур — нечего проверять и нечего откатывать.
Фикс: Намерения, ограничения, тестовые наборы и метрики качества как обязательные артефакты каждого релиза, а не пожелания на словах.
Смежная тема
Observability & Monitoring Design
Откуда брать сигналы о деградации и как настроить алертинг, чтобы ловить регресс раньше пользователя.
Что это меняет в архитектуре системы
- Текст запроса, набор правил и модель вознаграждения переходят в разряд артефактов системы наравне с API-контрактами и исходным кодом — их версионируют, ревьюят и откатывают.
- Без контура наблюдаемости за качеством ответов регресс не виден до жалоб: нужны фактическая точность, длина, дублирование, кликабельность, удовлетворённость и доля эскалаций.
- Продуктовая разработка и развитие моделей перестают быть отдельными процессами и сливаются в единый цикл: гипотеза -> эксперимент -> измерение -> дообучение -> поэтапный запуск.
- Опереться на проверяемые источники ассистент сможет только при готовой ссылочной базе и контуре извлечения контекста — без них верифицируемость остаётся на словах.
Дополнительные материалы
Связанные главы
- AI в SDLC: путь от ассистентов к агентам от Александра Поломодова - Тот же сдвиг внутри разработки: от подсказок к агентным рабочим циклам и инженерным контурам в SDLC.
- AI Engineering - Дисциплина качества, релизов и управления AI-продуктом, когда модель уже работает в проде.
- Prompt Engineering for LLMs - Как из размытого «будь полезным» получить формализованное намерение, ограничения и инструкции в контуре запроса.
- Архитектура конвейеров данных: извлечение, преобразование и загрузка (ETL) и ELT - Откуда берётся контекст для проверяемых ответов: контуры данных и извлечение, без которых ответ не на что опереть.
- Observability & Monitoring Design - Метрики качества, мониторинг и контур обратной связи, чтобы регресс AI-функции был виден раньше пользователя.
- Зачем знать ML и AI инженеру - Базовый контекст AI и ML, на который опираются решения по системному и продуктовому дизайну.