У клиента к лету 2024-го накопилась большая база документов из реестров сертификации: декларации, сертификаты, история по заявителям и продукции. Незадолго до этого мы перенесли самые тяжёлые таблицы в ClickHouse — и поиск, который раньше занимал минуты, стал отвечать за несколько секунд. Логичный следующий вопрос от заказчика: а можно ли «прикрутить сюда ИИ».
Отвечать презентацией мы не стали. Вместо этого собрали прототип и выложили его на тестовый сервер, чтобы заказчик потрогал руками. Идея простая: оператор пишет запрос человеческим языком, а модель сама превращает его в выборку из базы деклараций. Работа шла по инициативе бюро и за наш счёт — чтобы разговор о бюджете крутился вокруг живого результата, а не вокруг красивых слайдов.
Сводка
| Отрасль | Сертификация продукции, B2B-аналитика рынка |
| Конечный клиент | «Аналитика сертификатов» |
| Формат сотрудничества | R&D-прототип по инициативе бюро, за свой счёт |
| Тип проекта | Запросы к базе деклараций на естественном языке поверх существующей платформы |
| Объём работ | Сборка прототипа, обучение модели на реальных вопросах, демо на тестовом сервере, обкатка с заказчиком |
| Трудозатраты | Без согласованной сметы — исследовательская работа бюро |
| Команда | Прототип собрал Антон Херсун; исполнитель на продакшен-версию не назначался |
| Технологический стек | Laravel-платформа · ClickHouse · обучаемая LLM на отдельном GPU-сервере · веб-интерфейс запросов |
| Статус | Зависло на уровне демо: модель показала результат, заказ на доведение до продакшена не оформлен |
Запрос клиента
У заказчика была рабочая аналитическая платформа и большой массив структурированных данных. Запрос звучал расплывчато, как это обычно и бывает: «внедрить в работу компании ИИ, чат-джипити» — отдельно в отдел продаж, отдельно в технический отдел. Конкретики под этим не было, и это нормально на старте.
Мы начали с честного встречного вопроса: какую именно функциональность хочется получить и куда её встраивать — в портал аналитики, виджетом в CRM или чат-ботом в мессенджере. Для технического отдела заготовка у нас к тому моменту уже была, так что проще всего было продвинуть разговор, показав её в деле.
Что мы сделали
1. Собрали прототип и дали к нему доступ.
Выложили рабочую версию на тестовый сервер с логином для заказчика. Оператор пишет вопрос обычными словами, модель строит по нему выборку из базы деклараций и возвращает таблицу. К демо приложили PDF с примерами реальных обращений, чтобы заказчик видел границы возможного, а не отрепетированный сценарий.
2. Обучили модель на реальных вопросах.
Это не «подключили API, и заработало». Модель обучаемая: чтобы она понимала живой язык операторов, её надо дообучать на конкретных формулировках. Мы загрузили в неё то, что собрали за месяц тестирования, и доучивали прямо по ходу демо. Показательный эпизод из переписки: фразу «текущий месяц» модель сначала не понимала вовсе — встроенного знания о сегодняшней дате у неё нет. Около часа ушло на то, чтобы научить её обращаться с датами; после этого она корректно отрабатывала формулировки вроде «документы с датой больше первого июня» и сама показывала, что декларации на лифты поступают каждый день.
К концу обкатки прототип вытягивал и довольно сложные составные запросы: взять город, заявителя и число его документов, оставить только тех, кто ввозил определённую категорию товара, добавить дату последней регистрации, отсортировать по числу документов, схлопнуть «ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ» до «ООО» и привести даты к нужному формату. Всё это — одной фразой на русском, без SQL.
3. Честно показали, где модель ошибается.
Главная инженерная мысль такого продукта: модель ошибается уверенно. В демо она ставила строгое равенство там, где нужен был поиск по вхождению, путала колонки и начинала тянуть данные из адреса заявителя вместо нужного поля. Иногда с ней буквально приходилось торговаться, чтобы получить корректную выборку. Если не держать режим «модель предлагает, человек проверяет» и не дообучать её на частных случаях, такой инструмент быстро превращается в источник правдоподобной ерунды. Мы закладывали это в разговор с самого начала, а не оставляли на «потом разберёмся».
4. Очертили, что нужно для продакшена.
Демо упиралось в честные ограничения. Модели не хватало памяти между запросами: вопрос «персики, Москва», а следом «а теперь аналитику по ним» она не связывала в один контекст — это уже отдельный, более продвинутый уровень. Для боевой версии требовался отдельный мощный сервер и человек, который постоянно дообучает модель, как ученика: «даты я ему час учил». Мы честно проговорили, что здесь много исследовательской работы и экспериментов, результат заранее не гарантирован, и закладывать его в бюджет надо мелкими шагами, а не одной крупной строкой «ИИ-функционал».
Как это восприняли
Реакция шла ровно так, как и должна идти на сыром R&D. Первый прогон заказчик описал прямо: «интересная современная штука, пока выдаёт чушь конечно». Часть «чуши» оказалась несовпадением ожиданий: он спрашивал про сертификаты, а под капотом была только база деклараций. После пары итераций дообучения тон сменился: «сложные запросы решает», «прикольно получилось». Ещё через несколько недель, когда выборки довели до того, что хотелось видеть, оценка стала совсем короткой — «круто».
Заказчик даже захотел показать прототип партнёрам. Мы на время снова открыли доступ к тестовому серверу (между демо его гасили, чтобы не жёг ресурсы) и предупредили: без короткой инструкции модель и партнёрам может наговорить лишнего.
Результат
| Что получили | Значение |
|---|---|
| Рабочее демо | Запрос к базе деклараций обычными словами вместо SQL, на живых данных |
| Карта возможного | Что модель уже умеет, где уверенно ошибается, чего ей не хватает |
| Требования к продакшену | Отдельный сервер, человек-тренер, режим «ИИ предлагает — оператор подтверждает», бюджет мелкими шагами |
| Статус заказа | Зависло на уровне демо: продакшен-версию заказчик не заказал, исполнитель не назначался |
Главный итог здесь не запущенная фича, а снятые иллюзии и работающая точка отсчёта. Заказчик увидел, на что технология реально способна на его данных и за сколько это придётся доводить. Тема осталась в проработке: спустя год, в августе 2025-го, мы отдельно искали готовые решения под чат-бота к этой задаче — и честно сообщили, что ничего достаточно зрелого под их специфику не нашли. Поэтому собственный прототип так и остаётся самым близким к цели вариантом.
Для нас это нормальный режим работы: мы готовы вложить собственное время в AI-эксперимент, чтобы у клиента был не слайд, а то, что можно потрогать, и трезвое решение о бюджете.
Команда
- Антон Херсун, Xaver Pro: собрал прототип, обучал модель на реальных вопросах, провёл демо и обкатку с заказчиком
ИИ-направление остаётся на стадии прототипа: отдельный исполнитель на продакшен-версию не назначался, заказ не оформлен. R&D мы вели за свой счёт.
Скриншоты и материалы
Прототип на закрытом тестовом сервере, публичных артефактов нет.
Думаете «прикрутить ИИ» к своей базе или процессам, но не уверены, где он окупится, а где станет дорогой игрушкой? Соберём прототип на ваших данных, покажем, что реально работает, а где модель уверенно врёт, и поможем понять, сколько закладывать в бюджет. Первичный разбор бесплатный.