Есть особый тип AI-проекта, который выглядит потрясающе на архитектурной диаграмме и при этом не делает почти ничего такого, с чем не справилась бы простая версия. Там есть векторная база данных, граф оркестрации мультиагентов, файнтюненая модель, слой памяти, кастомные обёртки для инструментов, три ретрая с экспоненциальным бэкоффом и пара абстракций «на будущее», которыми никто не пользуется. Агент в центре всего этого простой. Собор построен вокруг него.

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

Вот семь признаков того, что вы перешли черту, что делать вместо этого, и плейбук, как не попасть в ловушку с самого начала. Посчитайте, сколько пунктов выглядят неприятно знакомыми.

Что такое переусложнение AI-приложения

Переусложнение (over-engineering) в контексте AI-приложений это добавление архитектурных слоёв, векторных баз, агентных графов, слоёв памяти, пайплайнов файнтюнинга, до того как появилась измеримая проблема, которую этот слой решает. Признак: вы не можете одним предложением ответить, какой конкретный сбой устраняет данный компонент.

1. Вы взяли векторную базу данных до того, как она понадобилась

«Сначала поднимите векторную базу» стало стандартной первой строкой почти каждого туториала по AI. Команды рефлекторно разворачивают Pinecone или Chroma ещё до того, как убедились, что у них вообще есть задача поиска, требующая эмбеддингов.

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

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

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

2. Ваш «агент» на самом деле один промпт в пальто

Мультиагентные системы завораживают. Агент-планировщик, агент-исследователь, агент-критик, агент-синтезатор, все пересылают друг другу сообщения по графу. Выглядит как настоящая инженерия.

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

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

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

3. Вы файнтюнили модель, чтобы она выучила факты

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

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

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

4. Вы добавили систему памяти, которую никто не просил

«AI, который вас запоминает» звучит убедительно в питче. Поэтому персистентные слои памяти, темпоральные графы знаний и межсессионное состояние прикручивают на ранней стадии, часто к приложениям, которые по своей природе одноразовые.

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

Вместо этого: спросите себя, правда ли задаче нужна непрерывность между ходами диалога. Если нет, не стройте. Если да, начните с самого простого: передавайте дальше саммари разговора, прежде чем тянуться за выделенным движком памяти.

5. Ваши промпты обзавелись собственным фреймворком

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

Сложность в обвязке вокруг промпта это всё равно сложность. Когда собранный промпт становится чем-то, что человек не может прочитать за один присест, вы обменяли проблему читаемости, которую видели, на проблему, которую не видите.

Вместо этого: держите промпты плоскими и читаемыми так долго, как можете. Когда динамическая сборка действительно нужна, логируйте финальный отрендеренный промпт и регулярно читайте его. Если вы не можете по нему пройтись, модели работать с ним тоже тяжелее, чем должно быть.

6. У вас нет эвалов, но зато много архитектуры

Это признак, который связывает все остальные. Команды неделями заливают время в пайплайны поиска, агентные графы и слои памяти, а качество измеряют на вайбе: покликали, посмотрели на вывод, задеплоили, когда «стало неплохо».

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

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

7. Вы оптимизируете под масштаб, которого у вас нет

Шардирование, многоуровневое кэширование, мультирегиональный фейловер, система очередей, автоскейлинг GPU-инференса. Для приложения с парой десятков пользователей в день и роадмапом, который в основном гипотетический.

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

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

Как не переусложнить с самого начала

Распознать признаки это половина дела. Вторая половина это не допускать их с первого дня. Вот рабочий плейбук, который держит AI-приложение худым, но не бессильным.

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

Сделайте «почему» обязательным полем. Заведите простое правило для команды: ни один новый слой не попадает в код без ответа в одно предложение на вопрос «какую конкретную наблюдаемую проблему это решает». «Может пригодиться потом» и «в туториале так было» не считаются. Если вы не можете назвать сбой, который это чинит, у вас нет доказательств, что слой нужен. У вас есть догадка. Догадки идут в бэклог, а не в кодовую базу.

Пишите эвал до фичи. Переверните привычный порядок. Прежде чем строить навороченный пайплайн поиска, напишите тест, который докажет, что он лучше. Если вы не можете измеримо определить, как выглядит «лучше», вы не готовы это строить. А если можете, часто обнаружится, что куда более простое изменение двигает метрику так же сильно.

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

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

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

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

Одно правило под всем этим

Если свести всё к одному принципу, он такой: начинайте с наименьшего стека, который решает задачу. Добавляйте слой только когда что-то конкретное и наблюдаемое сломалось. Не «когда слой мог бы пригодиться когда-нибудь». Не «когда в туториале такой был». Когда что-то сломалось, и вы можете назвать и измерить это сломавшееся.

Это не призыв строить небрежно или игнорировать реальную сложность. Многим AI-приложениям действительно нужны векторный поиск, агенты, память и масштаб. Это призыв зарабатывать каждый слой. Лучшие AI-приложения не те, у которых самая впечатляющая диаграмма. Это те, где каждый прямоугольник на диаграмме стоит там потому, что без него что-то сломается.

Часто задаваемые вопросы

Как понять, что векторная база действительно нужна?

Нужна, когда поиск по ключевым словам измеримо не справляется: синонимы, перефразирования, большая стабильная база знаний. Соберите бейзлайн на grep или SQL, замерьте качество на 30-50 реальных запросах и переходите на эмбеддинги, только когда цифры покажут провал.

Чем файнтюнинг отличается от RAG по назначению?

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

Сколько эвалов достаточно для старта?

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

Итог

Переусложнение AI-приложения почти никогда не выглядит как ошибка в момент принятия. Оно выглядит как тщательность. Векторная база «на всякий случай», пара лишних агентов «для надёжности», память «на будущее». Цена приходит позже: в отладке в два часа ночи, в эвалах, которых нет, в слоях, которые никто не осмеливается трогать.

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