Каждый день на Хабре появляются статьи и эксперименты с RAG, fine‑tuning и векторными базами. Это интересные опыты, но все они упираются в один и тот же потолок — низкую точность, отсутствие диалога с пользователем, сложность интеграции и риск утечек данных из‑за использования с облачными LLM‑моделями.
Меня зовут Кристина Бахмаер, продакт‑менеджер SL Soft AI. В сегодняшней статье расскажу, как мы побороли типичные «болячки», создавая свой промышленный продукт SL AI Search. Собрали не только свой опыт, но и ТОП-5 подводных камней, которые жду при внедрении интеллектуального поиска. А еще — список вопросов к поставщикам, он пригодится компаниям при выборе решения.
Зачем компаниям интеллектуальный поиск
В корпоративных средах сотрудники ежедневно тратят часы на ручной поиск документов, инструкций, решений или ответов в Confluence, SharePoint, Jira и сетевых хранилищах.
Интеллектуальный поиск решает эту проблему, объединяя технологии NLP, полнотекстового поиска, семантического поиска и больших языковых моделей (LLM).
В отличие от классического поиска по ключевым словам, интеллектуальный поиск понимает смысл запроса, интерпретирует естественный язык и возвращает точные ответы или документы, а не просто список ссылок. SL AI Search — промышленное решение для интеллектуального поиска, которое объединяет генеративные модели, полнотекстовый поиск, корпоративные требования (вроде ролевого доступа к документам) и стандарты безопасности.
В SL AI Search реализованы оба сценария:
поиск ответов на вопросы на основе корпоративной информации (LLM + RAG): результат — ответ на интересующий вопрос;
полнотекстовый поиск по корпоративным документам с учетом морфологии, синонимов и онтологий различных областей знаний: результат — список документов в базе знаний, содержащих подходящую информацию (на основе ключевых слов и словосочетаний).
Благодаря этому система помогает:
сокращать время поиска информации и нагрузку на экспертов;
автоматизировать функции и повышать качество клиентской и внутренней поддержки;
сохранять и масштабировать корпоративные знания;
принимать решения на основе полной картины данных компании.
RAG и не только: как устроен интеллектуальный поиск нового поколения
Сегодня RAG (Retrieval‑Augmented Generation) стал стандартом для построения интеллектуальных ассистентов, отвечающих на вопросы. Он объединяет поиск релевантных фрагментов (чанков) документов и генерацию ответа на их основе.
Однако большинство open‑source реализаций RAG работают хорошо только в лабораторных условиях. В реальных корпоративных сценариях они быстро упираются в ограничения — от низкой точности до невозможности интеграции с корпоративными хранилищами и контроля доступа.
Как работает RAG у большинства
Документы делятся на фиксированные чанки по символам (например, 1000–1500 символов), без учета структуры текста и типов документов. При этом теряется смысловая целостность текста — один абзац может быть разрезан пополам, а нужный контекст окажется в соседнем фрагменте.
Создается векторная база. Все фрагменты превращаются в векторы и загружаются в хранилище (Qdrant, FAISS и тому подобное).
Находятся близкие векторы. Система возвращает несколько фрагментов по смысловому сходству с запросом.
Фрагменты передаются LLM. Модель генерирует ответ, но не проверяет его достоверность и не объясняет, из какого документа он взят.
Типичные проблемы:
отсутствие полнотекстового поиска — система ищет фрагменты для ответа, но не умеет искать документы,
нет механизмов верификации точности ответа,
не предусмотрена возможность анализа на базе обратной связи от пользователей — качество не растет со временем,
отсутствуют встроенные коннекторы к корпоративным системам (сетевые папки, веб порталы, Confluence, Jira и тому подобное),
нет ролевой модели доступа и соблюдения compliance.
Такой вариант подходит для прототипов и тестов, но не для корпоративных систем, где важны точность, объяснимость и безопасность.
Как устроен поиск в SL AI Search
Архитектура SL AI Search включает все сильные стороны RAG и добавляет собственные уровни предобработки, постобработки и контроля качества. Это не набор технологий, ориентированный на эксперименты, а готовый к использованию продукт для стабильной работы внутри корпоративного контура.
-
Предобработка данных
Перед построением векторной базы документы проходят интеллектуальную подготовку: семантическое разбиение по смыслу, а не по символам.
• Решение анализирует структуру документа (заголовки, списки, таблицы) и выделяет логические блоки. Это повышает точность поиска в сравнении с обычным фиксированным делением на чанки на 30%.
• Извлечение метаданных (тип и автор документа, версия, дата). Это позволяет применять бизнес‑логику фильтрации.
• Очистка и нормализация данных. Система убирает дубли, устаревшие версии и нерелевантные блоки.
• Создание полнотекстового индекса. Он работает параллельно с векторным, что дает возможность искать как смысл, так и конкретные фразы. -
Интеллектуальный поиск (retrieval)
SL AI Search использует гибридный поиск:
• векторный — понимает смысл запроса;
• лексический (BM25) — ищет точные фразы и ключевые слова;
• гибридное ранжирование — объединяет оба результата и учитывает метаданные документов и роль пользователя.Результат — выдача, которая содержит не только короткие фрагменты, но и релевантные документы и разделы с контекстом.
-
Обогащение контекста (augmentation)
Перед передачей данных в LLM применяется интеллектуальная обработка:
• динамическое объединение связанных фрагментов, чтобы модель видела полный смысл;
• фильтрация по доступам и источникам;
• добавление системных подсказок — модель получает не просто текст, а структурированный контекст, что снижает риск «галлюцинаций». -
Генерация и постобработка
После ответа модели система проводит несколько этапов контроля:
• автоматическое тестирование — LLM проверяет корректность и полноту ответа;
• добавление ссылок на документы и страницы для прозрачности;
• скоринг релевантности — ответ оценивается и ему присваивается свой рейтинг.Если уверенность низкая, система может уточнить запрос или предложить пользователю дополнительные варианты. Это позволяет точнее отвечать на вопросы пользователей.
-
Автотесты и аналитика
SL AI Search собирает оценки качества ответов от пользователей и использует их для проведения автотестов. На этапе настройки поиска есть возможность проводить дополнительные тесты — создавать пары «вопрос‑ответ», чтобы проверить качество ответов после обновления системы или загрузки новых документов.Администратору поиска доступны метрики для выявления слепых зон в базе знаний, определения скорости и качества подготовленных ответов (метрики — список вопросов, оценки, точность, запросы без ответы и др.).
Что еще делает интеллектуальный поиск корпоративным продуктом?
1. Ролевая модель доступа. Когда мы говорим о решении корпоративного уровня, встает вопрос — какие сотрудники и к каким документам могут иметь доступ? В SL AI Search есть ролевая модель, позволяющая создавать группы пользователей и давать им доступ к конкретным базам знаний. Так сотрудник отдела закупок может искать по закупочным регламентам компании, а бухгалтер — не иметь доступа к этим документам, но у него будет своя база знаний.
2. Ссылки на источники и дополнительная информация для контроля правильности ответов. Помимо ответа на вопрос, SL AI Search выводит пользователю ссылку на документ(ы), с помощью которого он был подготовлен. При необходимости пользователь может открыть документ, если сомневается в правильности предоставленного комментария или чтобы ознакомиться с содержанием подробнее. Также решение оперирует не только текстом, а выводит в чат изображения и схемы, которые были в документе, если они имеют отношение к ответу и дополняют его.
3. Интеграция с источниками и поддержка огромных баз знаний. Корпоративные базы могут представлять собой десятки тысяч документов и статей, которые постоянно обновляются. И вручную поддерживать актуальность систем, то есть отслеживать изменения и загружать новые версии документов, — нереально. Как минимум, потому что нет единой системы или базы знаний, в которой хранятся все документы. Обычно бывает так: что‑то хранится в СЭД, что‑то — в сетевых папках, что‑то — на корпоративном портале, что‑то — в ServiceDesk системах. Для решения этих проблем мы предлагаем готовые решения по интеграции с хранилищами информации, если интеграция по API невозможна, то помогут проверенные временем программные роботы (RPA).
4. Возможность встраивания в корпоративные системы. Можно поставить всем сотрудникам заказчика еще один интерфейс, в который надо будет обращаться, чтобы найти информацию. Но это будет уже тридцатая система у пользователя и вероятность того, что он будет ей пользоваться, сводится к нулю. Поэтому мы предлагаем свой API для использования решения во встроенном поиске в существующих системах, например, в СЭД или корпоративном мессенджере. Представьте, как было бы круто, если бы поиск в СЭДе «поумнел» — теперь и такое возможно.
Кроме этого, мы предлагаем виджет, который можно встроить в корпоративный портал или в любую другую систему, и пользователи тоже получат доступ к поиску через уже привычные интерфейсы.
Нюансы внедрения поиска, о которых надо знать
Теперь обсудим, как правильно подходить к внедрению поиска. Ниже представлены пять важных аспектов, которые необходимо учесть, и типовые ошибки, которых возможно избежать при внедрении интеллектуального поиска. Список составлен на основе нашего собственного проектного опыта.
1. Старт без конкретной бизнес‑задачи
«Давайте внедрим крутой ИИ, а там посмотрим, что получится». Решение ищет проблему, а не наоборот. На самом деле интеллектуальный поиск — не волшебная палочка. Да, первые результаты приходят сразу после этапа загрузки документов. Но для эффективной работы системе нужны качественные данные и тонкая настройка под ваши специфические задачи. Обычно она заключается в корректировке промптов и добавлении глоссариев в базу знаний, но иногда приходится уходить еще глубже.
Как правильно: начать с пилота на конкретном и измеримом кейсе. Например, задача может звучать так: «снизить нагрузку на первую линию поддержки на 20% за 3 месяца».
2. Игнорирование качества данных (Garbage In, Garbage Out)
Когда в систему загружаются все документы подряд — устаревшие версии, сканы документов плохого качества, неструктурированные заметки — она будет выдавать неточные или нерелевантные ответы. В результате доверие пользователей и эффективность внедрения будут низкими.
Как правильно: до внедрения системы интеллектуального поиска необходимо провести аудит и очистку базы для удаления дублей, актуализации документов и структурирования данных, «прогнать» сканы через OCR/IDP для получения текстовых данных (это часть продукта SL Soft AI).
3. Недооценка вопросов безопасности и доступа
Развертывание системы без ролевой модели, когда все сотрудники получают доступ ко всем документам, повышает риск утечки конфиденциальной информации (например, зарплаты, финансовые отчеты, персональные данные) и нарушает compliance.
Как правильно: внедрять принцип минимальных привилегий с самого начала. Интегрировать систему с корпоративным LDAP/AD. On‑premise развертывание, использование локальных LLM, шифрование данных гарантируют отсутствие утечек данных в облако провайдера LLM.
4. Внедрили и забили забыли
С интеллектуальным поиском такой подход невозможен, поскольку появляются новые документы — их нужно индексировать; меняются бизнес‑процессы — требуется корректировка промтов или написание новых; выявляются пограничные и редкие случаи (edge‑cases) — в системе приходится выполнять донастройки. Если не собирать обратную связь, не обучать сотрудников, не объяснять, как ей пользоваться, то специалисты будут сопротивляться, предпочитая привычные методы работы.
Как правильно: на старте предусмотреть трудо‑ и времязатраты на развитие системы в долгосрочной перспективе. Для сотрудников разработать программу внедрения (вебинары, инструкции), использовать кнопки оценки ответа для сбора обратной связи.
5. Фокус на технологиях, а не на пользовательском опыте (UX)
Система, которая выдает идеально точные ответы, но с задержкой в 120 секунд или в неудобном интерфейсе, будет раздражать пользователей — они не захотят ждать и терпеть дискомфорт, даже если результат идеален.
Как правильно: при внедрении системы поставщик должен тестировать не только accuracy (точность), но также latency (скорость ответа) и usability (удобство). При выявлении слабых мест — оптимизировать промпты и цепочки вызовов для скорости.
Вопросы, которые надо задавать при выборе поставщика системы интеллектуального поиска
Этот раздел будет интересен тем, кому предстоит выбрать оптимальное решение — на рынке много предложений с разными технологиями «под капотом». Здесь надо держать в голове, что успешный проект — это не тот, где построили самую сложную модель, а тот, где решили бизнес‑проблему, учли все риски и встроились в процессы.
1. Стратегия борьбы с галлюцинациями
Вы должны узнать конкретные технические детали, например: «Мы используем ре‑ранкеры для точности», «Наш системный промпт явно запрещает выдумывать», «Мы предоставляем ссылки на источники для проверки».
Настораживающие ответы вендора сводятся к формулировке «наша модель сама все знает». В реальности существует много разных подходов, вендор должен рассказать о тех, что он использует. И да, гарантия 100% качества поиска — маркер того, что вас дезинформируют, потому что какими бы ни были умными современные технологии — все равно поиск дает правильный ответ в проценте случаев. На реальных проектах мы добивались 96% качества — и это считается очень высоким результатом.
2. Вопросы по безопасности и compliance
где обрабатываются данные? (Россия/другая юрисдикция)
поддерживается ли on‑premise развертывание?
-
как реализована ролевая модель доступа (RBAC)?
Для проверки можно запросить документы с описанием архитектуры безопасности и политику обработки данных.
3. Гибкость и возможности интеграции
Для работы требуется первоначальная настройка подключения к источникам данных (сетевые папки, Confluence, Jira). Часто требуется помощь ваших IT‑специалистов для предоставления доступов и настройки API.
В идеале вендор предлагает несколько вариантов: API (для разработчиков), виджеты (для быстрого старта), iframe и тому подобное
Рекомендую запросить и изучить документацию по интеграции, уточнить, какие коннекторы есть «из коробки», а какие потребуют доработки и за чей счет. Кроме того, не повредит получить демодоступ и попробовать самостоятельно пройти процесс от создания пользователя до получения ответа от системы. Это поможет оценить затраченное время и сложность.
4. Стоимость владения (ТСО)
ТСО складывается из стоимости:
лицензии/подписки,
инфраструктуры (стоимость GPU/CPU и хранения данных, если решение on‑premise, или их аренды в облаке),
интеграция (трудозатраты ваших разработчиков),
поддержка и обучение (стоимость услуг вендора).
Попросите вендора рассчитать ТСО на 1–3 года с учетом ваших объемов данных.
5. Проверка UI/UX
Удобство интерфейса для конечных пользователей (поисковая строка, чат) и, что важно, удобство админпанели для ваших администраторов. Как легко загружать документы, смотреть аналитику, настраивать права?
Для оценки попросите вендора показать, как происходит процесс загрузки нового документа и обновления индекса.
6. Запуск пилота
Вендор не должен бояться пилотных проектов с четкими измеримыми целями, работа по методологии «Timeand Materials» или за фиксированную стоимость пилота.
При выборе системы важен здоровый скептицизм и понимание, какие ограничения есть у технологии. Нужно отдавать себе отчет в том, что всегда на 100% ответы точными не будут. Интеллектуальный поиск снижает нагрузку на экспертов, но не заменяет их, особенно в сложных и чувствительных вопросах.
Самописное решение, собранное на базе open‑source, — отличный инструмент для экспериментов. Но если бизнесу нужно стабильное, управляемое и безопасное решение для поиска и работы со знаниями — стоит выбирать интеллектуальный поиск, принадлежащий вендору и им же сопровождающийся, а не просто RAG.
Пример такого промышленного решения — SL AI Search, которое сочетает технологии RAG, полнотекстовый поиск, диалоговую логику и корпоративную безопасность. Продукт готов к внедрению, встраиванию в корпоративный портал, СЭД или мессенджер — с поддержкой ролевого доступа, on‑premise и встроенным тестированием качества.
Спасибо всем, кто дочитал. А что для вас является главным препятствием в разработке или внедрении подобных систем? Технологическая сложность, стоимость или возможные организационные барьеры? Буду рада обратной связи в комментариях!