Что действительно произошло в кейсе

24 февраля 2026 года European Digital Innovation Hubs опубликовала кейс expert-hub.li. Заказчиком указана GB Marketing & Solutions GmbH — малое или среднее предприятие из Лихтенштейна, которое развивает цифровой маркетинг. Задача была шире обычного чат-бота: создать рынок экспертных услуг, где компания или частный клиент может сформулировать потребность, найти подходящего специалиста и пройти весь путь до оказанной и оплаченной услуги.

В опубликованном решении есть профили экспертов, описания услуг, чат, запись на встречу, обмен документами, видеосвязь, выставление счетов и оплата. ИИ используется для подбора эксперта под запрос клиента; отдельно упомянут ассистент KI-Lie, который даёт первичную консультацию по темам Лихтенштейна и направляет пользователя к подходящему советнику.

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

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

Почему «чат-бот для подбора» — слишком узкая постановка

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

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

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

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

Архитектура локального подбора

Для малого бизнеса разумна пятиступенчатая схема.

1. **Структурированный вход.** Клиент описывает задачу обычным языком, но форма отдельно запрашивает обязательные ограничения: отрасль, регион, язык, срок, формат и диапазон бюджета. Исходный текст сохраняется вместе с согласиями и каналом получения.
2. **Нормализация запроса.** Небольшая локальная LLM или классификатор превращает описание в перечень намерений, компетенций и уточняющих вопросов. Модель не принимает решение и не придумывает отсутствующие условия.
3. **Поиск кандидатов.** Система объединяет полнотекстовый поиск и векторное сходство по описаниям услуг, кейсам и компетенциям. Метаданные отсекают неподходящий язык, регион, недоступный слот или услугу вне бюджета.
4. **Ранжирование и объяснение.** Реранкер оценивает короткий список, после чего система показывает пользователю несколько вариантов с конкретными основаниями: совпавшая специализация, релевантный опыт и доступность. Человек выбирает эксперта или запрашивает уточнение.
5. **Детерминированное исполнение.** Запись в календарь, создание сделки в CRM, выдача доступа к документам, счёт и оплата проходят через обычные API с проверкой ролей, идемпотентностью и журналом действий.

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

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

Какие данные и интеграции потребуются

Профиль эксперта должен быть машиночитаемым. Одного рекламного абзаца недостаточно. Нужны:

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

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

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

Где возникают ошибки

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

Второй риск — устаревшие данные. Эксперт поменял специализацию, занят или больше не оказывает услугу, но старый профиль продолжает высоко ранжироваться. Нужны срок актуальности, автоматические напоминания и понижение профилей без подтверждения.

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

Четвёртый риск — внедрение инструкций через текст профиля или загруженный документ. Такой контент считается данными, а не командами. Модель не получает ключи платёжной системы, не меняет роль пользователя и не вызывает произвольные URL.

Подход NIST AI RMF полезен как управленческая рамка: роли и ответственность за надзор должны быть определены заранее, а результаты человеческого вмешательства — регистрироваться. Простая кнопка «проверил человек» не заменяет понятного регламента: кто проверяет подбор, по каким критериям и что происходит после отклонения.

Экономика: считать завершённую услугу

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

Допустим, компания получает 300 запросов в месяц. Сотрудник тратит в среднем 12 минут на уточнение и первичный подбор, его полная стоимость — 900 рублей в час. Если система сокращает половину этой работы, модельная экономия составит 27 000 рублей в месяц: `300 × 0,2 часа × 900 рублей × 50%`.

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

Основная метрика — стоимость одной завершённой и принятой клиентом услуги. Дополнительно стоит измерять:

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

Как провести пилот без дорогой платформы

Для проверки гипотезы не нужен сразу маркетплейс с видеосвязью и оплатой. Достаточно одного процесса, 30–100 профилей и 100–200 обезличенных исторических запросов.

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

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

Именно такая последовательность переносит главный урок expert-hub.li на российский бизнес: не начинайте с «универсального ИИ-консультанта». Сначала опишите услугу, данные и переходы процесса. Затем добавьте ИИ туда, где свободный язык действительно мешает найти подходящего человека.