Разговор о программировании смыслов ценен тем, что смещает акцент с ручного описания алгоритма на проектирование поведения системы.
Глава показывает, как намерения, ограничения, циклы оценивания и модель вознаграждения становятся рабочим инженерным контуром AI-продукта, а не побочной настройкой вокруг модели.
Для архитектурного разбора это сильный материал, чтобы обсуждать проектирование полезности, продуктовую семантику и ту часть AI-архитектуры, которая обычно не видна на сервисной диаграмме.
Практическая польза главы
Проектирование поведения
Глава помогает обсуждать AI-продукт не только через код и модели, но и через намерения, ограничения и рабочий цикл оценивания.
Контур качества
Через этот кейс удобно разбирать, как продуктовые правила, модель вознаграждения и оценивание складываются в единый цикл улучшений.
Инженерия полезности
Материал хорошо показывает, что полезность AI-системы проектируется и измеряется, а не появляется автоматически из сильной модели.
Материал для интервью
Это сильный кейс, чтобы обсуждать продуктовую семантику, проектирование вознаграждения и наблюдаемость AI-функции.
Программирование смыслов от Алексея Гусакова (CTO Yandex)
Разбор доклада Алексея Гусакова о том, как AI-продукты смещаются от ручного описания алгоритма к проектированию намерений, ограничений, циклов оценивания и полезного поведения системы.
Источник
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 для системного и продуктового дизайна.