Простые проблемы, которые мы решали в ИИ-стартапе

Предыстория. Ну как ИИ-стартап, в общем-то обычный SaaS но с ключевыми задачками в бизнес-процессах для LLM.

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

На первом этапе архитектура ИИ-слоя выглядела очень просто и типично:

user request ⭢ RAG retrieval ⭢ LLM ⭢ answer

В прототипе все работало отлично. Но после запуска в реальном продукте начались первые проблемы. Именно тогда этот стартап и попал ко мне.

Итак, вот с какими проблемами мы столкнулись. При грамотном планировании архитектуры их можно было изначально миновать.

Проблема №1. Слишком разные типы запросов

Пользовательские запросы оказались совершенно разными:

1. простые справочные вопросы

2. аналитические вопросы

3. задачи принятия решений

4. задачи с длинным контекстом

Одна модель начинала вести себя нестабильно. Где-то давала слишком длинные ответы, где-то не хватало reasoning, а где-то стоимость inference становилась слишком высокой.

Стало понятно, что одна модель для всех задач это очень плохая идея.

Проблема №2. Retrieval создавал шум

RAG тоже оказался не таким простым, как казалось.

В реальных данных retrieval часто возвращал:

• частично релевантные документы

• устаревшую информацию

• противоречащие источники

В результате LLM начинал галлюцинировать, смешивая несколько контекстов.

Проблема №3. Отсутствие проверки результата

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

Как изменилась архитектура?

После нескольких итераций архитектура системы стала выглядеть иначе.

user request ⭢ intent classification ⭢ model router ⭢ context builder ⭢ LLM execution ⭢ verification ⭢ response synthesis

Появилось несколько новых компонентов.

1. Intent classification

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

Ну к примеру:

information query

analysis request

decision support

long-context question

Это позволяет системе выбрать правильную стратегию.

2. Роутинг моделей

После классификации система выбирает модель.

Пример простой логики (в кейсе было сложнее):

simple question → cheap model

complex reasoning → stronger model

long context → long-context model

Все это дало сразу три эффекта:

• снизилась стоимость

• уменьшилась latency

• повысилось качество ответов

3. Контекстом надо управлять

Вместо прямого RAG появился слой подготовки контекста который

• фильтрует документы

• ранжирует источники

• ограничивает шум

Иногда используется гибридный поиск:

• embeddings

• keyword search

• метаданные
  

4. Верификация

Последний шаг любого когнитивного пайплайна это проверка результата.

Она может включать:

• self-critique модели

• вторую модель-проверяющую

• rule-based проверки

Иногда достаточно простой схемы:

model → critic model → final answer

Что в итоге стало ясно

Самая сложная часть системы оказалась не там, где ее ожидал основатель стартапа.

Основная инженерная сложность возникла в трех местах:

• роутинг моделей по критериям

• управление контекстом

• верификация

Другими словами, оркестрация системы.

Если убрать оркестрацию, архитектура снова становится очень простой, но в реальном продукте такая схема почти никогда не работает устойчиво.

Потому что реальные пользовательские задачи:

• слишком разные

• слишком шумные

• слишком неоднозначные

Чтобы их решать, система должна:

• понимать тип задачи

• выбирать модель

• собирать контекст

• управлять инструментами

• проверять результат

То есть делать то, что раньше в бизнес-процессах обычно делал человек.

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

LLM в этих системах играет просто роль вычислительного блока.

Но поведение всей системы определяется тем, как устроен когнитивный пайплайн:

• как формируется контекст

• как принимаются решения

• как проверяются результаты

Именно поэтому архитектура таких систем начинает напоминать распределенные системы, orchestration и workflow-движки, только вместо сервисов в них работают модели и агенты.

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