Вам продают ИИ. Покупать нужно не его

Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что‑то делать: все вокруг внедряют, конкуренты вон что‑то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.

Это был, кажется, пятый такой звонок за месяц.

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

Так вот, если коротко — не надо бежать.

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

---

Коротко, если совсем нет времени читать

• Локальная LLM ничего не знает про вашу компанию. Запуск на своём железе закрывает утечку данных — и только её, контекста по‑прежнему нет.

• RAG = поиск кусков в ваших документах + ответ модели с опорой на найденное. Качество определяется не моделью, а тем, что лежит на полках.

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

• Где разваливается: «помощник по всем нашим документам» в компании, где регламенты разбросаны по сетевым папкам и почте, а отвечает за корпоративные знания никто.

• Готовность к RAG видна за две минуты, без аудита. Один вопрос: есть ли у вас хотя бы одна база документов, за актуальность которой отвечает конкретный человек по имени.

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

• ИИ не наводит порядок в данных и процессах. Усиливает существующий — не создаёт из ничего.

Выпускник, которого вам прислали уже готовым

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

Локальная языковая модель (LLM, если по‑научному) — это, по сути, очень начитанный выпускник, которого вам прислали в готовом виде. Кто‑то его учил: Meta, Alibaba, Sber, DeepSeek, неважно кто именно. Прочитал он за свою «жизнь» гигантское количество текстов и научился одной штуке — вы ему даёте начало, он дописывает наиболее правдоподобное продолжение. Грамотно пишет, складно, производит хорошее впечатление при первом знакомстве.

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

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

Про железо коротко и тем более что прогресс не стоит на месте: Модель на 4–8 миллиардов параметров (та, что попроще) хочет 8–12 ГБ оперативки, базовые задачи в порядке. 13–14B — уже 16 ГБ, и это рабочий уровень для русского текста. 32B — 24–32 ГБ, желательно с GPU, иначе долго и грустно. 70B на CPU вообще нереалистично, не надо пытаться.

А теперь самое важное что нужно знать взявшись за любую LLM модель.

Чего модель не делает. Она не калькулятор, не SQL‑движок и не «база знаний», она вообще ничего не делает в смысле действий: текст на входе, текст на выходе, и всё. Когда вам показывают «ИИ, который сам работает с базой» или «сам оформляет документы», в реальности вокруг модели крутится самый обычный код, который берёт её текстовый ответ, проверяет его и сам выполняет действие.

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

Где это действительно приносит деньги

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

Почему? С цифрами модель работает плохо. Маленькие модели, те самые, что реально запускают на доступном железе, врут в арифметике — не катастрофически, но регулярно. Один и тот же вопрос даёт разные числа в разных запусках. Невоспроизводимо. Для застольной беседы это терпимо, для управленческого отчёта, где на цифру опираются в решении, — извините.

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

Но даже когда мы сделали всё правильно и модель красиво переписала точные цифры словами — получился продукт? Чаще нет, получилась просто упаковка. Если у руководителя есть толковый аналитик, осмысление цифр он получает от человека, который понимает контекст бизнеса; если такого человека нет — значит, не хватало именно его, а не словесного пересказа.

Где модель приносит деньги по‑настоящему, так это там, где никто не хочет смотреть, — на скучнейшей массовой работе с текстом.

Письма падают каждый день: в техподдержку, на info@, в общие чаты. Кто‑то их читает, понимает, разбрасывает — этому отделу, это срочное, это по такому‑то клиенту. Модель такую сортировку делает хорошо, это её родная стихия — вытащить из текста структуру. Туда же извлечение данных из однотипных документов: счета, накладные, УПД, акты, прайсы поставщиков. Если бухгалтер вручную заносит сотню‑другую в месяц, по десять‑пятнадцать минут на штуку, получите десятки часов чистой механики ежемесячно — вот эти десятки часов и есть экономия, понятная, измеримая, не маркетинговая.

Второй ряд, чуть посложнее. Черновики коммерческих предложений, ответы на типовые вопросы клиентов, письма по дебиторке — менеджер успевает в несколько раз больше касаний, но письмо всё равно уходит после того, как он сам его прочитал. Нормализация мастер‑данных: дедупликация контрагентов, причёсывание номенклатуры, матчинг товаров от разных поставщиков. Расшифровка звонков и извлечение из них сути. Везде человек в цепочке остаётся, просто переезжает с «делать руками» на «проверять».

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

Где этого условия нет, всё разваливается. И самый популярный запрос «сделайте нам помощника по всем нашим документам» нарушает это условие сразу целиком, поэтому про него отдельно.

Как RAG устроен, и почему ломается чаще, чем кажется

Раз модель ничего о вас не знает, придется ей вашу специфику подкладывать на каждый вопрос. Способ, который реально работает, называется RAG — Retrieval‑Augmented Generation, по‑русски примерно «генерация ответа с опорой на найденное». Расшифровка не для красоты, в ней вся суть: сначала retrieval, то есть поиск нужных кусков в ваших документах, потом generation, когда модель формулирует ответ, держа эти куски перед глазами.

Давайте представим библиотекаря. Вы задаёте вопрос, и он не отвечает по памяти, а сначала идёт к полкам, находит несколько подходящих страниц, приносит их и только потом пересказывает своими словами. Вот это и есть RAG: модель здесь не «знает», она пересказывает то, что ей принесли.

Запомните этот момент — из всех абзацев статьи он ключевой. Качество ответа определяется не моделью, а тем, что лежит на полках. И тем, насколько хорошо «библиотекарь» дотянулся до нужной страницы.

Технически это работает так. Один раз система проходит по всем вашим документам, режет каждый на чанки (куски по несколько сотен слов с перекрытием) и каждый чанк превращает в вектор — длинный набор чисел. Эта операция делается отдельной нейросетью, которую называют эмбеддинг‑моделью: на русском в 2026 берут, например, GigaEmbeddings от Sber или Qwen3-Embedding, через полгода появится что‑то новее, и выбирают актуальную на момент проекта — этот слой меняется быстро, под него подстраиваются, а не выбирают раз и навсегда. Векторы складываются в специальную базу, умеющую искать ближайшие вектора по смыслу.

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

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

Теперь правду про то, как корпоративные документы выглядят в реальной компании. Не в презентации вендора, а на самом деле. Они разбросаны по сетевым папкам, личным ноутбукам, почте, корпоративным мессенджерам. У них нет версионности, вместо неё файлы типа «договор_финал_финал_правки_v3.docx». Половина в старом.doc, четверть — сканы PDF без текстового слоя. Регламент писал сотрудник, который уволился четыре года назад. Самое актуальное знание живёт в головах двух ключевых людей, у которых нет времени его записать. И за корпоративные знания, как за актив, не отвечает вообще никто.

Что сделает RAG с таким складом? Ровно то, чем закончилась история про библиотекаря. На ваш вопрос он принесёт восемь «релевантных» кусков из противоречащих друг другу бумаг: двух регламентов 2019 года, черновика 2022-го, протокола совещания и почтовой переписки. Модель честно перескажет противоречие — гладко и уверенно. Клиент получит не помощника, а генератор путаницы с авторитетной интонацией, и это хуже, чем отсутствие бота: уверенной ошибке верят.

И вот ради чего, собственно, всё это писалось. Сработает RAG или нет у вас в компании — решено ещё до выбора любой технологии, и решает это ответ на один‑единственный вопрос: IT у вас в компании — ядро бизнеса или обслуживающая функция?

В банке IT и есть бизнес, и то же на бирже. Там по необходимости есть зрелые процессы работы с данными: версионность, владельцы, регламенты. Слово IT‑директора имеет вес, он может навести порядок и поддерживать его, и шанс, что RAG там полетит, реальный.

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

Готовность компании к RAG, кстати, можно увидеть за две минуты без всякого аудита. Я задаю один вопрос: «есть ли у вас хотя бы одна база документов, за актуальность которой отвечает конкретный человек по имени?». Если ответ «вообще‑то у нас все вместе» (читай: никто) — всё, проект провалится, и никакой бюджет, никакой стек этого не вытянут.

Где это всё‑таки работает: узкие места, где порядок уже есть

Но даже там, где с документами в целом бардак и хаос, почти всегда есть узкие участки, где порядок уже существует сам по себе. Вернёмся к ним — именно в них RAG и приносит деньги.

У всех рабочих случаев одно общее свойство: База, по которой ищет система, должна быть управляемой. Её границы можно описать одной фразой (что входит, что нет), документы в ней более‑менее однородны, и есть конкретный человек, который отвечает за её актуальность, не «все вместе». «Узкая» здесь не про «маленькая», а про «за неё можно ручаться»: в инженерии данных это называют доменом данных — ограниченной областью со своим владельцем, словарём и правилами. Гарантировать качество получается ровно тогда, когда понятно, что внутри такого домена и кто его поддерживает.

Как это выглядит на практике. Самый частый кейс — не «вся компания», а одно живое пространство в уже имеющейся базе знаний: раздел корпоративной вики или Confluence по конкретной теме, который команда реально ведёт. Почему он почти идеален: тема узкая, границы понятны, у пространства есть владелец (та самая команда), страницы однородны по формату, и, что важно, у вики есть API и метаданные — автор, дата, метки. По ним индексацию можно автоматизировать и отсекать устаревшее, чего в свалке из сетевых папок и почты не сделать в принципе.

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

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

1. Кто конкретно отвечает за актуальность этих документов? «Никто» или «все вместе» — СТОП.

2. Можно ли одной фразой сказать, что в этот домен входит, а что нет? Границы размыты — сужать домен данных или не браться.

3. Документы однородны или «всё подряд»? Чем разнороднее doc, xls, jpg, тем дороже работа и хуже результат.

4. Что будет, если система ответит неверно? От цены ошибки зависит, сколько нужно человеческого контроля.

5. Кто пользователь — сможет он критически оценить ответ или примет на веру?

6. Что человек делает сейчас без этой системы и в чём именно будет экономия?

Больше «да» — задача рабочая. Больше «нет» — сужать рамки или честно отказываться.

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

Цена ошибки решает, не точность модели

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

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

Второй уровень. Ошибка неприятна, но обратима. Черновик письма, предзаполненная форма — перед отправкой смотрит человек. Применять можно, но с обязательной проверкой в каждом цикле, и уже здесь начинается интересное, про которое почему‑то редко говорят.

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

Четвёртый уровень. Ошибка необратима. Финансовые операции от имени компании, любые действия с внешними последствиями. Вероятностной системе здесь не место — точка, и никакая «точность 99 процентов» не оправдывает один необратимый процент.

А теперь та самая интересная штука со второго уровня — из‑за неё даже самый безобидный сценарий с человеком в цепочке оказывается опаснее, чем кажется на демо.

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

Это не отказ техники, это предсказуемая деградация внимания, и закладывать её надо в расчёт с самого начала, а не узнавать постфактум, когда уже всплыло.

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

А теперь главное: о чём эта статья на самом деле

Сразу скажу прямо — эта статья вообще не про ИИ.

ИИ — это слово сезона, через год его место займёт следующее, а до него, между прочим, побывали и Big Data, и блокчейн, и чат‑боты в каждый магазин, вы наверняка устали от этого хоровода. Если внимательно посмотреть, под каждой новой модной аббревиатурой повторяется одна и та же история: компанию пытаются убедить, что вот эта свежая технология решит её проблему, технологию пытаются натянуть на неубранный ИТ‑ландшафт — и, как правило, ждут чуда.

Свежий пример, прошлогодний. Не буду называть компанию, не суть. Финансовый отдел сидит на Excel, CRM меняют третий раз за три года (то одна не подошла, то другая не прижилась, то ещё какие‑то «объективные обстоятельства»), единой учётной системы нет, ежемесячная отчётность собирается в финотделе из чудо‑таблиц вручную. Хотят, естественно, не разгребать этот завал, а построить хранилище данных — и когда я спрашиваю, как они собираются в нём собирать единый показатель выручки, если выручка лежит в трёх несоединимых местах, внятного ответа нет.

Это та самая компания, которой через полгода (или, я бы не удивился, уже сейчас) с тем же азартом продадут «корпоративного ИИ‑помощника по всему», и она с тем же энтузиазмом скажет «давайте».

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

Разберётесь с этим — и половина «задач для ИИ» либо решится без него вообще, либо отпадёт как неактуальная. Не разберётесь — никакая модель не спасёт, как бы её ни рекламировали.

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

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

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

Маленький словарик

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