Недостаточно внедрить AI. Нужно собрать систему, которая окупается

У нас в Mobecan AI постепенно перестал быть одним чатом в браузере.

Я сначала думал про AI довольно просто: есть ChatGPT, есть Codex, есть Claude, есть локальные модели. Ну и дальше вроде вопрос только в том, что открыть под конкретную задачу.

Но чем больше мы это внедряем у себя в Mobecan, тем больше видно, что вопрос не в выборе одного инструмента.

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

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

С кодом похожая история. Codex сам по себе очень сильная штука, но если просто дать ему проект и сказать "сделай красиво", результат может быть разный. Где-то он реально экономит часы. Где-то уверенно пишет то, что потом надо спокойно вычищать.

У нас он начинает нормально работать не сам по себе, а когда вокруг есть понятный процесс: задача, репозиторий, тесты, smoke-проверки, возможность быстро посмотреть diff и понять, что именно изменилось.

То есть ценность дает не только модель. Ценность дает связка вокруг нее.

Похожая история с продажами. Мы оцифровали кейсы, коммерческие предложения, часть базы знаний, подключаем CRM. И смысл не в том, чтобы сказать "смотрите, у нас теперь AI в продажах". Смысл в более приземленной вещи: быстрее понять входящий лид, не вспоминать руками, делали ли мы что-то похожее, подобрать нормальные кейсы и подготовить основу для ответа клиенту.

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

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

Если приходить с фразой "мы можем внедрить вам AI", человек часто слышит не пользу, а новую работу: ему надо вникнуть, сформулировать боль, согласовать бюджет, объяснить руководству, потом еще отвечать за результат.

А ему обычно нужно проще: вот здесь стало быстрее, вот здесь дешевле, вот здесь данные не ушли наружу, вот здесь меньше ручной работы, вот здесь можно проверить эффект.

Потом я наткнулся на статью Berkeley BAIR про compound AI systems и понял, что они нормальным языком описали то, к чему мы у себя приходим руками.

Не одна модель, которая все знает и все делает, а сборка под конкретный процесс.

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

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

Сейчас это ощущение прошло.

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

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

Похоже, AI-проект может не окупиться не потому, что модель плохо отвечает.

А потому что все подряд отправили в самый дорогой внешний API, не посчитали поток данных, не встроили проверку и назвали это внедрением.

Недостаточно внедрить LLM.

Нужно собрать систему, которая окупается в реальной работе.