LLM-проекты не стали другими - они стали быстрее собираться

Архитектура LLM-продукта по-прежнему важнее свежего названия модели

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

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

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

Скорость старта не отменяет дисциплину качества - она делает отсутствие дисциплины заметнее.

Полезно отдельно разделить 2 слоя работы:

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

Главная перемена произошла в цене первого шага

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

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

Также меняется состав команды. Кейс, на который раньше требовалось 6 дней и команда с QA-специалистами, можно собрать силами 2 человек. Смысл не в том, чтобы вычеркнуть проверку качества. Наоборот, проверка остаётся. Но её подготовка и часть однообразных действий перестают требовать отдельного потока ручного труда.

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

Агент полезен в исследовании, а не в роли безнадзорного эксперта

Показательный сценарий связан с General-purpose агентом Codex GPT-6. Его использовали не только как инструмент для AI Coding. Агент подключился к архиву кейсов и подготовил исследование по извлечению данных для Heavy Duty Pressure Transducers: собрал PDF-файлы, скрипты и предварительно размеченные данные.

Дальше нужен человек. Агент запросил около 30 минут участия эксперта в ключевых точках обратной связи. После этого он может сам разметить eval dataset - набор примеров для проверки качества. Это важная граница: машина помогает развернуть черновую работу, но эксперт задаёт смысл, ловит неверные допущения и подтверждает, что именно считать ошибкой.

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

Здесь часто обжигаются на двух крайностях. Первая - ждать идеального полного решения, прежде чем дать агенту доступ к материалам. Вторая - принять предварительную разметку за готовую истину. Черновик ускоряет работу. Он не заменяет проверку.

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

Новых практически применимых задач появилось немного не потому, что технологии упёрлись в потолок. Проблема часто внутри организации. Чем крупнее и старше компания, тем медленнее она меняет процессы, распределяет ответственность и допускает эксперимент к реальным данным.

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

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

Начинать стоит с одного узкого процесса и набора ошибок

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

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

Для систематизации таких рабочих контуров можно использовать ATLAS PANEL: хранить задачи, правила проверки и решения по обратной связи в одном месте. Главное - фиксировать не только удачные ответы, но и ошибки, которые система больше не должна повторять.

Выигрывает не команда, которая первой подключила модный агент. Выигрывает команда, которая быстрее превращает его черновую работу в проверяемый процесс с ясной зоной человеческого контроля.