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

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

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

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

user request ⭢ RAG retrieval ⭢ LLM ⭢ answer

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

Пару слов о моем запросе. Ищу разработчиков мидл+ (фулстаки, бэкендеры, фронты и особенно техлиды, способные управлять небольшими командами разработки) для подключения в команды стартапов. Есть стартапы на РФ, и есть на глобал. Шлака нет, все проекты достойные. Я более 20 лет занимаюсь разработкой и выводом на рынок новых продуктов. Последние 6 лет ментор в Сколково. Напиши мне, если интересно поучаствовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема №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-движки, только вместо сервисов в них работают модели и агенты.

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

Буду рад поработать с вами в одной команде. У нас все на парт-тайме, коммуникация в основном асинхронная. Пишите, если есть интерес участия в командах разработки новых стартапов.