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

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

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

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

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

Сам я не специалист по нейросетям. Много лет вожусь с базами данных в банках, в ритейле, в системной интеграции, и работа моя: смотреть, как данные живут в компаниях и решать, что из задуманного взлетит, а что разобьётся о реальность. Через этот фильтр я и предлагаю взглянуть на нынешний шум вокруг локальных 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 - 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 и метаданные - автор, дата, метки. По ним индексацию можно автоматизировать и отсекать устаревшее, чего в свалке из сетевых папок и почты не сделать в принципе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Никакой кнопки «закажите внедрение» дальше не будет ;).