Менеджер перед звонком открывает карточку и пытается вспомнить: «что мы обещали по срокам поставки и почему клиент был недоволен в феврале?» В CRM — 40 сделок, 300 писем, несколько тысяч записей в ленте активностей. Полнотекстовый поиск по слову «срок» выдаёт двести документов и ни одного ответа. Семантический поиск по CRM-истории решает именно эту задачу: находит по смыслу, а не по совпадению строк.

Почему обычный поиск по CRM не работает

Данные о клиенте размазаны по сущностям: сделки, звонки, письма, задачи, комментарии, чаты, тикеты поддержки. Каждая сущность живёт в своей таблице, со своими полями и своим языком описания.

Люди пишут по-разному: «перенесли на март», «сдвинули на Q2», «ждём бюджет», «отложили до согласования». Ключевой поиск такие синонимы не связывает, а опечатки и транслит добивают результат. Плюс теряется контекст: фраза «согласовали скидку» без привязки к сделке и дате бесполезна.

Что даёт семантический поиск

История клиента превращается в векторное представление: каждый фрагмент — письмо, расшифровка звонка, комментарий — получает эмбеддинг и метаданные (клиент, сделка, дата, автор, канал). Запрос на естественном языке ищется по близости смыслов, а не по буквам.

На практике это гибридная схема: BM25 или полнотекст ловит точные сущности — номера договоров, артикулы, названия компаний, — а векторный поиск добирает смысловые совпадения. Реранкер пересортировывает топ-50 кандидатов, и на выходе менеджер получает 3–5 релевантных фрагментов со ссылками на источник.

Дальше это становится фундаментом для RAG-ассистента: он отвечает на вопросы вида «какие клиенты за последние полгода жаловались на интеграцию с 1С» и «что мы не выполнили из обещанного по этому договору».

Данные и подготовка

Главная работа — не в модели, а в данных. Нужен единый идентификатор клиента и сквозная связка сделок, контактов и активностей, иначе поиск будет возвращать куски чужой истории.

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

Отдельно решается дедупликация: в российской практике дубли клиентов и «ООО Ромашка» в трёх написаниях — норма, а не исключение.

Архитектура и российский контур

Типовая схема: CDC или вебхуки из CRM и почты → нормализация → чанкинг → эмбеддинги → хранилище (PostgreSQL с pgvector, Qdrant или аналог) → гибридный поиск → реранк → генерация ответа с цитатами.

Для 152-ФЗ критично, чтобы эмбеддинги и LLM работали в локальном контуре, без отправки переписки во внешние API. Приватная модель на своих GPU закрывает и требования регулятора, и внутренние политики безопасности.

Интеграции делаются через API Битрикс24, amoCRM, retailCRM, 1С:CRM или напрямую к реплике БД — важно не нагружать продакшн-контур CRM.

Практические шаги

Начните с одного отдела и одного сценария — например, подготовка к встрече или передача клиента другому менеджеру. Выгрузите историю за 12–24 месяца по этому отделу.

Соберите 50–100 реальных вопросов менеджеров с эталонными ответами: это тест-набор, без него качество не измерить. Соберите прототип за 1–2 недели и посчитайте recall@5 и долю ответов с корректной цитатой.

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

Как мы можем помочь

АПС внедряет приватные LLM, RAG-системы и ИИ-агентов: разворачиваем контур на ваших серверах, подключаем CRM, почту и телефонию, настраиваем гибридный поиск по истории клиентов и ассистента для менеджеров. Начинаем с аудита данных и пилота на одном отделе, чтобы результат измерялся, а не декларировался. Обсудить проект