LLM и эмбеддинги в бизнесе: как дата-инженеры заменили рутины на приоритетные задачи

# Когда ИИ влетает в бизнес с двух ног

Менеджер крупной строительной компании начинает утро со списка на обзвон, который кажется бесконечным. Каждая регистрация требует пяти минут: нужно проверить номер, страну, не платный ли он. Если трубку не берут — звонить еще трижды. Рутина съедает время, а риск нарваться на платный номер или мошенника высок. Именно с этой проблемы начал доклад на третьем занятии «Вечерней школы Слёрма» дата-инженер Дмитрий Дунаев.

Он показал, как обычный список превратился в приоритизированный благодаря LLM, и как команда справилась с задачей сопоставления 209 тысяч наименований товаров в полутора сотнях представительств, где обычный SQL-join охватывал лишь 1% совпадений.

Качество данных как фундамент

Дата-инженер — это роль, находящаяся между DevOps и аналитиком. Его задача — собрать, структурировать и очистить данные из различных источников. В контексте работы с большими языковыми моделями это критически важно. Принцип *garbage in, garbage out* (мусор на входе — мусор на выходе) действует здесь в полной мере.

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

Кейс №1: Антифрод и приоритизация звонков

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

Решение на базе LLM Команда внедрила классификатор на основе LLM, который анализирует множество признаков: типичность имени и фамилии для конкретной страны, географию по IP, наличие признаков подмены и т.д. Модель выдает один из трех вердиктов: * Зеленые: Высокая вероятность реальности — звонят в первую очередь. * Желтые: Спорные случаи — решение принимает менеджер. * Красные: Высокий риск мошенничества — блокируются или требуют глубокой ручной проверки.

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

Выбор модели и безопасность Работа с персональными данными подпадает под требования 152-ФЗ, что исключает передачу данных в облачные сервисы. Команда тестирует около 15 моделей, оценивая их по шести критериям: детерминизм, компактность (до 12 ГБ для локального развертывания), работа с менталитетом СНГ, логическая корректность, безопасность и способность выдавать структурированный вывод.

Из теста выделилась модель YandexGPT 5 Lite. Она показала лучший баланс стабильности, работы с русским языком и безопасности, несмотря на то, что другие модели (например, Gemma 3 или T-lite от Т-Банка) были либо слабее в лингвистике, либо менее безопасны. Модель развернута локально на защищенном контуре.

Кейс №2: Унификация номенклатуры товаров

Хаос в справочниках Компания с полусотней представительств имеет около 209 тысяч наименований товаров. Из-за опечаток, сокращений (например, «полиэт» вместо «полиэтилен»), разных единиц измерения (дюймы vs мм) и формата записи («3х2,5» против «3*2,5») один и тот же товар в разных филиалах записывается по-разному.

Прямой JOIN таблиц сопоставляет менее 1% записей. Fuzzy-поиск (поиск похожих строк) находит часть совпадений, а ручная верификация экспертов дорого и медленно обходится, так как концентрация человека падает уже после нескольких часов монотонной работы.

Архитектура гибридного решения Комбинация одного метода не дала приемлемого результата, поэтому была построена гибридная система: 1. Классификация: Данные разбиваются на классы и атрибуты. 2. Эмбеддинги: Текст преобразуется в векторное представление, позволяющее искать смысловые близости. 3. Fuzzy-поиск: Поиск схожих, но не идентичных строк. 4. Ручная верификация: Найденные совпадения и новые кандидаты попадают к эксперту.

Для самых сложных случаев с большим количеством расхождений показала высокую эффективность модель GPT-5.6 Sol с максимальным уровнем рассуждений, хотя она и потребляет много токенов.

Чек-лист: стоит ли строить агента?

Дмитрий Дунаев выделил пять условий, при которых имеет смысл внедрять агентную систему:

1. Повторяемость решений: Задача должна решаться регулярно. 2. Достаточность данных: Нужно есть достаточно данных для обучения и валидации, при этом экспертности для разбора не хватает. 3. Оценка цены ошибки: Должны быть заранее оценены риски ложноположительных и ложноотрицательных суждений. 4. Человеческий фактор: Наличие экспертов для проверки результатов агента. 5. Fallback-процесс: Наличие плана действий на случай сбоя агента.

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

Инструментарий Для тестирования команды используются графические интерфейсы вроде Cherry Studio, позволяющие управлять множеством моделей и агентов, а также прокси-шлюзы для работы с локальными решениями (NVIDIA, Ollama). Важно: репутация провайдера не гарантирует качество — единственная верификация должна быть на собственном тестовом датасете.

*Авторский штрих: Внедрение ИИ в бизнес — это не магия, а строгая инженерия данных, где подготовка входной информации важнее самого алгоритма распознавания.*