Иллюзия компетентности: когда ИИ знает всё и ничего одновременно

Вы внедряете ИИ-ассистента в компанию. На тестах он блестяще отвечает на вопросы о мировых тенденциях, пишет код, генерирует SQL-запросы к стандартным базам данных. Первая неделя — восторг. Вторая — недоумение. Третья — раздражение.

Потому что он не знает, что в вашей компании «клиент» называется «партнёром». Что «отгрузка» происходит только после «акцепта счёта». Что таблица sales_2024 содержит данные только до сентября, а октябрьские записи лежат в sales_q4_temp. Что «средний чек» в отчёте для совета директоров рассчитывается иначе, чем в отчёте для отдела маркетинга.

Проблема не в том, что ИИ глупый. Проблема в том, что он знает слишком много общего и слишком мало конкретного. Это как нанять профессора лингвистики, который блестяще говорит на 20 языках, но не понимает сленг вашего офиса.

Корень всех зол: отсутствие бизнес-контекста

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

Запрос «покажи динамику продаж по регионам за последний квартал» звучит просто. Но для ИИ это:

Какой источник данных считать истинным? CRM, ERP, или Excel-файл у аналитика?
Что такое «последний квартал»? Календарный? Финансовый? Или «квартал» в вашей компании начинается 15 числа?
Какие регионы включать? Москва отдельно или в составе Центрального федерального округа?
Какие продажи? Только оплаченные? Или включая резервы? А отменённые заказы?

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

SQL-генерация: где теряется 80% точности

Тест Spider 2.0 — золотой стандарт для оценки SQL-генерации. Модели показывают там 80-90% точности. В реальной компании эта цифра падает до 30-40%. Почему?

Проблема	Пример из Spider	Реальная бизнес-среда
Имена таблиц и колонок	student, course, teacher	usr_accnt_2023_v2, prod_catg_master_tbl, fin_trans_archive_q3
Схема данных	Чистая, нормализованная	Денормализованная, с дубликатами, устаревшими колонками
Бизнес-правила	Отсутствуют	«Активные клиенты — только со статусом не 5 или 9, кроме тестовых»

Модель, обученная на чистых схемах, не понимает, что в реальном мире данные живут в хаосе. Она не знает, что колонка deleted_at со значением NULL не всегда означает активную запись — иногда это баг 2008 года, который все боятся трогать.

💡

Если ваш ИИ-ассистент генерирует SQL с JOIN по колонке customer_id, но в вашей базе связь идёт через account_ref + region_code — у вас именно эта проблема. Модель работает правильно, но в неправильном контексте.

Три инженерных подхода, которые работают (когда их правильно применяют)

1 RAG: не учите модель, дайте ей шпаргалку

Retrieval-Augmented Generation — самый модный термин 2023-2024. Идея проста: вместо того чтобы впихивать все знания в модель, мы даём ей доступ к внешней базе знаний. По запросу пользователя ищем релевантные документы и подставляем их в контекст модели.

Звучит идеально. На практике большинство реализаций RAG в бизнесе работают как поисковая система 2005 года.

Типичные ошибки:

Загружают все PDF-ки в векторную базу без предобработки. Результат: модель получает на вход обрывки текста с нумерацией страниц и колонтитулами.
Используют эмбеддинги общего назначения (OpenAI, Cohere) для специализированных терминов. «КПЭ» и «ключевой показатель эффективности» оказываются в разных частях векторного пространства.
Не настраивают ретривер. Выдают 5 самых «похожих» документов, которые все описывают одно и то же, но упускают критически важный исключительный случай из другого документа.

Как делать правильно:

Создайте онтологию бизнес-терминов. Словарь, где прописаны синонимы, аббревиатуры, устаревшие названия.
Препроцессите документы: вытащите структуру (оглавления, таблицы), очистите от мусора, разбейте на смысловые чанки с перекрытием.
Обучите или дообучите эмбеддинг-модель на ваших данных. Или используйте гибридный поиск: векторный + ключевые слова.
Добавьте реранкер — вторую модель, которая оценивает, насколько найденные документы действительно релевантны запросу.

Хороший RAG — это не просто векторный поиск. Это целый пайплайн с несколькими моделями и бизнес-логикой. Как в статье про Agent Skills — агент должен помнить инструкции, а не просто искать по ключевым словам.

2 Fine-tuning: когда нужно изменить саму модель

Если RAG — это шпаргалка, то fine-tuning — это переучивание студента. Вы берёте базовую модель (Llama, Qwen, Mistral) и дообучаете её на своих данных.

Когда это нужно:

У вас специфический стиль коммуникации (технические отчёты, юридические документы).
Модель должна использовать определённую структуру ответов.
Бизнес-логика слишком сложна для описания в промпте.

Главная ловушка fine-tuning: качество данных. Если вы накормите модель кривыми SQL-запросами из продовой базы, она научится генерировать такие же кривые запросы.

Правильный подход: создайте «золотой датасет». Возьмите реальные бизнес-вопросы, попросите экспертов написать идеальные ответы (SQL + объяснение). Очистите от ошибок. Добавьте разнообразия — разные формулировки одних и тех же вопросов. Только потом обучайте.

Технически fine-tuning стал доступнее. Инструменты вроде Unsloth, Axolotl, PEFT позволяют дообучить модель на одной видеокарте за разумные деньги. Но не ожидайте чудес от LoRA на 100 примерах — для серьёзных изменений нужны тысячи качественных пар «вопрос-ответ».

3 Онтологии и графы знаний: структурирование хаоса

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

В бизнесе это выглядит так:

Сущность: Клиент
Свойства: ID, название, регион, сегмент, менеджер
Связи: заключает Договор, создаёт Заявку, участвует в Акции
Правила: Клиент может быть в статусе «активный» только если есть хотя бы одна оплаченная Заявка за последние 90 дней

Зачем это ИИ? Онтология даёт модель структурированный контекст. Вместо того чтобы гадать, что значит «показать самых активных клиентов», модель обращается к онтологии и видит формальное определение «активности».

Реализация сложнее, чем RAG или fine-tuning. Нужны эксперты предметной области, время на построение графа, интеграция с ИИ. Но результат — модель, которая действительно понимает бизнес, а не угадывает.

Интеграция: как не убить продакшен на старте

Даже с идеально настроенным ИИ-ассистентом можно провалиться на этапе внедрения. Потому что бизнес — это не только технологии, но и люди, процессы, ограничения.

Ошибка номер один: дать ИИ прямой доступ к продовой базе данных. Первый же ошибочный DELETE или бесконечный JOIN уронит сервис.

Решение: песочница. Создайте отдельную схему БД с:

Копией структуры продовых таблиц (без реальных данных)
Синтетическими данными, отражающими реальные распределения
Лимитами на время выполнения запросов, потребление памяти
Автоматической проверкой запросов перед выполнением

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

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

Измеряйте не точность, а полезность

Академические метрики (BLEU, ROUGE, точность на Spider) почти бесполезны в бизнесе. SQL-запрос может быть синтаксически правильным, семантически верным, но выдавать не те данные, которые нужны бизнесу.

Вместо этого измеряйте:

Время, которое сотрудник экономит с помощью ИИ
Процент запросов, после которых пользователь не обращается к эксперту
Количество ошибок, которые ИИ помог предотвратить
Удовлетворённость пользователей (простая бинарная оценка «помогло / не помогло»)

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

💡

Лучшая метрика: сколько раз в день сотрудник говорит «спасибо, именно это я и хотел». Если этого не происходит — ваш ИИ бесполезен, независимо от технических показателей.

Что делать прямо сейчас (если вы только начинаете)

Не гонитесь за сложными архитектурами. Начните с простого RAG на документации вашей компании. Используйте готовые инструменты вроде LlamaIndex или LangChain.
Соберите датасет реальных вопросов, которые задают сотрудники. 100 вопросов с правильными ответами лучше, чем 1000 синтетических.
Создайте прототип с человеческим в цикле. ИИ предлагает ответ, человек проверяет и исправляет. Так вы накопите данные для fine-tuning.
Начните строить онтологию с самых критичных областей — там, где ошибки ИИ стоят дороже всего.
Читайте статьи про реальный опыт: DevOps для ИИ, ИИ в бизнес-процессах.

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

Проблема не в технологиях. Проблема в том, что мы пытаемся использовать общие модели для решения частных задач. Бизнес — это всегда частные задачи. ИИ должен знать не только SQL, но и то, как ваша компания называет клиентов, считает прибыль, принимает решения.

Контекст — это всё. Без него ИИ просто болтает. С ним — становится стратегическим активом. Выбор за вами.

Почему ИИ-ассистенты ломаются в бизнес-среде: анализ проблемы контекста и инженерные решения