Введение в архитектуру ИИ‑систем: как GPT‑wrapper превращается в распределённую систему

Почти все AI‑проекты начинаются одинаково. Разработчик делает небольшой сервис с одним вызовом модели, подключает FastAPI, добавляет чат и показывает демо команде. На этом этапе всё выглядит настолько просто, что возникает опасное ощущение: «Ну это же обычный API‑вызов, только ответ пишет нейросеть».

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=messages
)

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

И вот тут начинается самое интересное.

Стадия 1. «У нас просто AI‑бот»

Первая проблема в рабочей системе почти никогда не связана с «тупой моделью». Обычно всё намного прозаичнее: система начинает тормозить.

В какой‑то момент оказывается, что:

• одновременно приходит уже не 5 запросов, а 500,

• часть генераций занимает по 20–30 секунд,

• API модели начинает ограничивать запросы,

• пользователь обновляет страницу,

• интерфейс отправляет запрос повторно,

• а сервер уже генерирует второй одинаковый ответ за те же деньги.

Команда внезапно обнаруживает, что AI‑система плохо сочетается с классическим подходом «запрос → ответ». Генерация текста — дорогая и медленная операция с высокой вариативностью по времени выполнения. Один запрос может завершиться за 2 секунды, а другой — за 40, потому что внутри сработал вызов инструментов, поиск документов, повторная генерация JSON или переключение на резервную модель.

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

Стадия 2. Асинхронная обработка и очереди

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

Архитектура начинает меняться.

И это уже важный архитектурный переход. AI‑система перестаёт быть «чатом» и начинает превращаться в распределённую обработку задач.

Особенно хорошо это видно в конвейере загрузки данных. Допустим, пользователь загружает PDF на 500 страниц. Система:

• извлекает текст,

• режет его на фрагменты,

• строит векторные представления,

• обновляет индекс,

• пересчитывает связи,

• инвалидирует кеш,

• публикует события обновления.

Ни один здравомыслящий человек не станет делать это синхронно в рамках одного API‑запроса.

Поэтому рядом с LLM почти всегда появляются:

• Kafka,

• Redis Streams,

• Celery,

• Temporal,

• Prefect,

• событийная обработка,

• фоновые worker‑процессы.

AI постепенно втягивает в себя весь набор технологий распределённых систем.

Стадия 3. «Модель не знает наши данные»

Следующий этап взросления — RAG.

Почти каждая команда приходит к нему одинаково. Сначала все восхищаются тем, как хорошо модель отвечает на общие вопросы. Потом кто‑то задаёт вопрос про внутреннюю документацию компании — и бот начинает уверенно выдумывать несуществующие нормативы или политики безопасности.

Тогда появляется идея:

«Давайте подключим поиск по нашим документам».

На схемах всё выглядит очень красиво:

Но production‑RAG быстро показывает, что поиск документов — это отдельная инженерная задача со своими режимами отказа.

Например, одна команда после обновления embedding‑модели обнаружила, что точность поиска упала почти на 20%. Формально система продолжала работать: документы находились, ответы генерировались, ошибок не было. Но качество стало заметно хуже, потому что изменилась геометрия векторного пространства, а старые параметры поиска больше не подходили.

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

Потом появляются модели повторной сортировки документов, потому что обычный векторный поиск недостаточно точен. Потом выясняется, что повторная сортировка добавляет ещё 800–1200 мс задержки. Потом оказывается, что конвейер поиска уже медленнее самой LLM.

И вот в этот момент команда впервые понимает важную вещь:
современная AI‑система — это не просто «вызов GPT». Это смесь поисковой системы, backend‑сервиса и конвейера обработки данных.

Как выглядит типичная AI‑архитектура

Через несколько месяцев эволюции система обычно разделяется на два независимых потока:

1. Синхронный путь запроса — отвечает пользователю.

2. Фоновая обработка — готовит данные и обновляет индекс.

Именно это разделение обычно превращает «чатик с GPT» в полноценную распределённую систему.

Путь пользовательского запроса (слева)

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

• поиск работает дольше самой модели,

• окно контекста переполняется,

• повторная сортировка добавляет секунду задержки,

• резервная модель ухудшает качество,

• повторные попытки внезапно удваивают задержку.

Во многих системах уже на этом этапе приходится вводить:

• маршрутизацию между моделями,

• агрессивное кеширование,

• потоковую выдачу ответа,

• лимиты времени,

• SLA по задержкам.

Потому что пользователь не очень интересуется красотой вашей архитектуры после 18 секунд ожидания ответа.

Фоновая обработка данных (справа)

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

• асинхронная,

• событийная,

• распределённая.

Именно здесь появляются:

• очереди,

• процессы‑обработчики,

• Kafka,

• политики повторных попыток,

• оркестрация,

• хранение событий,

• ветвление/слияние потоков.

Причём проблемы здесь обычно намного менее очевидны, чем в пути пользовательского запроса. Например:

• векторные представления обновились, а индекс ещё нет,

• поиск использует старую версию документов,

• изменилось разбиение текста и качество поиска тихо деградировало,

• задержка обработки выросла до 40 минут,

• инвалидация кеша случайно уничтожила релевантность поиска.

Снаружи система всё ещё «работает». Но качество уже съезжает. И это очень типичная история production AI.

Стадия 4. Мониторинг и наблюдаемость

На этом этапе многие команды совершают интересное открытие: классический мониторинг для AI почти бесполезен.

CPU в норме.
Память в норме.
Ошибок нет.

Но пользователи жалуются:

«Бот стал отвечать хуже».

AI‑система может быть полностью здорова технически и одновременно деградировать по качеству.

Поэтому появляются совершенно новые категории метрик:

• точность поиска,

• частота галлюцинаций,

• расход токенов,

• доля полезного контекста,

• стоимость одного запроса,

• структура задержек,

• оценка качества ответов.

Один из самых полезных инструментов здесь — распределённая трассировка запросов. Например, команда смотрит трассировку и обнаруживает:

Запрос: 11.2s

- Поиск документов: 2.1s
- Повторная сортировка: 1.8s
- Сбор контекста: 300ms
- Генерация ответа: 5.4s
- Проверка JSON + повторные попытки: 1.6s

Именно в этот момент многие впервые понимают, зачем AI‑системам OpenTelemetry и полноценная наблюдаемость. Без трассировки отладка превращается в гадание. Пользователь пишет: «бот тупит», а причин могут быть десятки — от деградации поиска до внезапного slowdown у провайдера модели.

Стадия 5. Оркестрация и агентные системы

Следующий архитектурный скачок начинается, когда одной генерации текста уже недостаточно. Нужно, чтобы система:

• вызывала инструменты,

• ходила во внешние API,

• принимала решения,

• выполняла многошаговые процессы.

Именно здесь появляются агентные workflow.

Что интересно: индустрия довольно быстро ушла от идеи «полностью автономного AI‑агента». На практике самые стабильные production‑системы обычно выглядят гораздо более прагматично.

Не:

«AI полностью управляет системой».

А:

«Workflow остаётся детерминированным, а модель принимает локальные решения внутри него».

Например:

• слой оркестрации определяет последовательность шагов,

• политика повторных попыток контролирует сбои,

• предохранитель (circuit breaker) отключает проблемный сервис,

• ограничения бюджета контролируют стоимость,

• а LLM решает, какой инструмент вызвать следующим.

То есть современные агентные системы постепенно эволюционируют в сторону управляемых workflow‑архитектур, а не «полностью свободного интеллекта».

Что происходит с индустрией

Самое интересное сейчас — наблюдать, как AI Engineering постепенно перестаёт быть отдельной «магической» областью и начинает сливаться с уже существующими инженерными дисциплинами.

Современная AI‑система — это одновременно:

• backend‑разработка,

• распределённые системы,

• поисковые системы,

• обработка данных,

• наблюдаемость,

• ML‑инфраструктура,

• и постоянные продуктовые ограничения вокруг стоимости и задержек.

По сути индустрия приходит к мысли:

LLM — это не готовый продукт. Это новый инфраструктурный компонент, вокруг которого нужно строить полноценную инженерную систему.

Именно поэтому сегодня всё больше внимания уделяется не самим моделям, а архитектуре вокруг них:

• слой координации — orchestration layer,

• конвейерам загрузки данных,

• событийной обработке,

• системам оценки качества,

• маршрутизации,

• надёжности,

• контролю стоимости.

Потому что по мере взросления AI‑систем становится всё очевиднее:

GPT‑wrapper — это не конечная архитектура, а лишь первый шаг к полноценной распределённой системе.