Как ИИ-агент за выходные вычистил CRM, накопленную с 2017 года

Вечер пятницы. Коммерческий директор одного из наших заказчиков — дистрибьютора промышленного оборудования — открывает отчёт по клиентской базе. В понедельник у него стратегическая сессия, и нужна свежая сегментация. На экране — карточки компаний, накопленные с 2017 года. У большинства из них ключевые поля — «Отрасль», «Численность», «Роль контактного лица» — пустые. Меньше половины. У «Годового оборота» и «Основной боли клиента» — вообще единицы процентов.

Разослать спецпредложение «производствам от 200 человек» физически не по кому. В базе такие карточки, конечно, есть, но в поле «Численность» у них прочерк. Утверждённая маркетинговая кампания повисает в воздухе.

Ситуация знакомая. Восемь лет менеджеры вносили клиентов на бегу: имя, телефон, что купил. Поля-справочники заполнялись «когда будет время». Времени, естественно, не было никогда. К концу пятилетки CRM превращается в свалку: данные есть, работать с ними нельзя.

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

Что мы обнаружили при инвентаризации

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

ИНН заполнен почти везде — без него не выставишь счёт. Отрасль — меньше чем у половины, потому что справочник из 34 значений, и никто не помнит, где какое выбирать. Численность — у трети, не больше. Годовой оборот и грейд компании — единичные карточки. Роль контактного лица — тоже мало. «Основная боль» — свободное поле, куда за восемь лет почти никто ничего не написал.

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

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

Первая попытка: «дай LLM всё, разберётся»

Соблазн понятен: собрать по каждой карточке всю доступную историю — письма, звонки, документы — запихнуть в промпт и попросить GigaChat Pro заполнить 27 полей одним махом. Мы попробовали именно так. Классическая ошибка, когда думаешь: «мощная модель — умная, справится».

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

Хуже другого: качество плавало. LLM восстанавливала «Отрасль» как «производство» вместо канонического значения справочника «Промышленное производство / Металлообработка». Формально не ошибка — практически поле не заполнено, потому что не матчится со справочником и не участвует в сегментации. Модель честно старалась, но у неё в промпте не было жёсткого списка допустимых значений, а сам справочник был слишком длинным, чтобы просто перечислить его в тексте.

К вечеру субботы я остановил пайплайн, налил кофе и пересобрал задачу с нуля.

Правильный подход: три уровня маршрутизации

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

Слой 1. Правила и справочники (ноль вызовов LLM)

Из ИНН вычисляется восемь полей автоматически: форма собственности, регион регистрации, ОКВЭД, дата регистрации, статус (действующее / ликвидировано), учредитель, размер по государственному критерию (микро / малое / среднее / крупное), система налогообложения. Всё это отдаёт открытый API справочника юрлиц. Пишется на SQL и Python за час.

Из ОКВЭД правилами получается канонический код нашего справочника «Отрасль». Не всегда однозначно, но в большинстве случаев — идеально. Там, где ОКВЭД у компании двусмысленный (условно, «оптовая торговля прочими товарами»), карточка помечалась флагом и уезжала на следующий слой.

Итого без единого обращения к LLM закрыли больше половины пустых ячеек. Это заняло, кажется, часов пять с учётом отладки — включая тот момент, когда я понял, что справочник по ИНН иногда возвращает сокращённое название региона, а иногда полное, и это ломает мой lookup.

Слой 2. Лёгкая модель на классификацию

Осталось то, что нельзя восстановить справочником: «Роль контактного лица», «Тип боли», «Уровень зрелости в закупках». Эти поля требуют понимания текста — писем, транскриптов звонков, комментариев менеджера.

Но задача-то узкая: классификация в фиксированный список. Не нужен GigaChat Pro — хватает лёгкой модели с function calling и строгой JSON-схемой. Мы прогнали основной массив карточек через YandexGPT Lite с промптом на несколько сотен токенов и списком допустимых значений. Стоимость этого этапа в разы ниже, чем у Pro, скорость — пара секунд на карточку. Это как раз тот случай, когда цена ИИ-агента считается не за час работы, а за поле в базе — и её надо считать заранее.

Ключевой приём: не давали модели свободу текста. Только enum с пятью-восемью значениями. Confidence-score моделировали через self-consistency: три параллельных прогона с температурой 0.2. Если три ответа совпали — уверенность высокая, поле заполняем. Если два из трёх — заполняем с флагом needs_review. Если разнобой — уходит в очередь на человека.

def classify_with_confidence(payload, field_schema, runs=3, temperature=0.2):
    results = [call_llm(payload, field_schema, temperature) for _ in range(runs)]
    top = Counter(results).most_common(1)[0]
    value, votes = top
    if votes == runs:
        return {"value": value, "status": "confident"}
    if votes >= 2:
        return {"value": value, "status": "needs_review"}
    return {"value": None, "status": "manual"}

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

Слой 3. GigaChat Pro — для сложных карточек с богатой историей

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

Вот тут GigaChat Pro отработал именно то, за что за него платят. Мы собирали для каждой карточки короткий брифинг: последние 15 писем, последние три транскрипта звонков, суммарные объёмы закупок по кварталам. Промпт — около пяти тысяч токенов, ответ — структурированный JSON с семью полями и обязательным reasoning под каждым значением.

reasoning — это не для LLM, это для менеджера. Когда через месяц менеджер открывает карточку и видит: «размер: крупное, обоснование: в переписке за 2024 год фигурирует тендерная документация на крупный объём» — он верит цифре. А без обоснования начинается тихий саботаж в духе «эту базу опять ваш ИИ-агент напортачил, я лучше по-старому позвоню и уточню».

Этот момент я недооценивал, пока не увидел его собственными глазами на первом внедрении полгода назад. Люди готовы работать с решениями машины ровно настолько, насколько могут проверить эти решения за минуту. Иначе — не доверяют.

Что случилось в понедельник

К утру понедельника заполненность 27 ключевых полей поднялась с плачевных цифр до состояния, когда с базой действительно можно работать. Пустых ячеек осталось меньше, чем на порядок — и это были в основном честные пропуски, где данных для восстановления просто нет: компании, с которыми одна сделка десять лет назад и с тех пор тишина. Такие карточки мы пометили флагом not_enough_evidence и оставили в покое.

Стратегическая сессия прошла на живой сегментации. Кампания «производствам от 200 человек в Приволжском ФО, покупавшим у нас в 2023 году» дала осмысленный список — примерно вдвое больше, чем нашлось бы по грязной базе. Директор был доволен, что в целом уже хороший результат.

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

Что стоит унести с собой

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

Второе. Для классификации в закрытый список берите лёгкую модель и строгую JSON-схему с enum. Confidence через self-consistency (несколько прогонов с ненулевой температурой) стоит копейки и режет процент ручной верификации в разы. Плюс это единственный дешёвый способ понять, где модель «плавает», а где действительно уверена.

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

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

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

Вопрос, который стоит задать себе: какой процент решений в вашем бизнесе принимается на данных, которых в CRM формально нет — а на самом деле они лежат в старых письмах и записях звонков и ждут, когда их достанут?

Похожие статьи

• Как мы научили ИИ-агента на GigaChat Pro не путать живого клиента с ночным батчем
• Как мы настроили ИИ-агента для поиска в 1С: MCP-сервер вместо метаний между окнами
• Один вопрос — три темы: как мы научили ИИ-агента разбирать составные запросы
• Text2SQL для 340 таблиц: как мы собирали ИИ-агента для анализа корпоративных данных на GigaChat Pro