Чем отличается от соседней заметки Delivery Stages AI — про стадии проекта с точки зрения контракта и приёмки (Demo → PoC → MVP → Production). Эта заметка — про инженерный порядок работ внутри разработки самого агента.
Три стадии
Подготовка. До первой строки кода нужны три вещи: выписанные регламенты процесса, инструменты с нормальными описаниями (и те, что приносят контекст, и те, что выполняют действия), и посчитанный показатель, по которому проект будут оценивать.
Прототипирование. Главный риск здесь — потратить месяцы на проект, которого не должно было существовать. Поэтому запрещено думать про стоимость, скорость и оптимизации: берётся самая дорогая и сильная модель, собирается архитектура, проверяется гипотеза, что задача вообще решается. Каждое изменение прототипа проверяется метриками (Quality Metric Design). Если прототип не завёлся — гипотеза не подтвердилась, проект честно закрывается.
Разработка. Сигнал получен, теперь оптимизируется инференс (Inference Optimization), снижаются риски и сводится экономика. Здесь же сравнивается оптимизированная версия с прототипом — и вот зачем на прошлом этапе строились метрики.
Три вопроса на выходе: показатель всё ещё растёт, экономика сошлась, риск контролируем.
Почему дообучение почти всегда не тот инструмент
Главное заблуждение — что дообучением добавляют знания. Модель уже видела весь интернет на предобучении; восемь часов дообучения её картину мира не перевернут. Если она не стала юристом на всех текстах человечества, на тысяче ваших примеров тем более не станет.
Хуже того, дообучение ломает то, что работало. Модели проходят отдельную дорогую стадию выравнивания, которая учит их не нести чушь и не выдавать системный промпт по первой просьбе. Меняя веса, вы снимаете эту гарантию. Галлюцинации могут резко вырасти: если в дообучение попали факты, которых не было в предобучении, модель оказывается в положении студента, выучившего билеты за ночь (LLM Training Stages).
Что дообучение действительно может — поправить форму ответа, когда промпт раздулся настолько, что модель в нём путается. На практике до этого доходит редко и обычно на маленьких моделях.
Единственный кейс, который окупается, — дистилляция: маленькая модель обучается повторять ответы большой на ваших конкретных задачах. Она теряет универсальность, но вашу задачу решает на уровне большой и стоит на порядок дешевле (Model Selection).
Фреймворк не определяет результат
Результат определяют описание бизнес-процесса, инструменты с понятными описаниями, метрики качества и дешёвый быстрый инференс. Уберите любой пункт — агент не полетит.
На чём это собрано — низкоуровневый фреймворк, графовый оркестратор, визуальный конструктор или голый Python — не имеет значения: это разные обёртки над одной логикой «положи нужный текст в контекст и вызови модель». Выбор определяется составом команды, а не свойствами инструмента (Orchestrator Adapter).
Связано с
- Delivery Stages AI — те же работы со стороны контракта и приёмки
- Quality Metric Design — метрики, без которых прототип не проверить
- Agent Evals — оценка на этапе разработки
- LLM Training Stages — почему дообучение снимает гарантию выравнивания
- Model Selection — дистилляция как способ удешевить
- Inference Optimization — чем занимаются на третьей стадии
- Orchestrator Adapter — развязка от фреймворка
- Autonomy Risk Profit — что определяет стоимость всей этой работы