Привет! Меня зовут Антон Фролов — я ведущий менеджер продукта в Content AI. В этой статье расскажу, как мы превратили корпоративный поисковый портал Intelligent Search в платформу для создания цифровых ассистентов с поддержкой LLM.

Если у вас уже есть прототип ассистента на базе open-source компонентов, платформа может помочь оперативно разработать решение production-уровня для автоматизации различных процессов с внутренними документами.

Эволюция продукта как поискового решения

История продукта началась в 2016 году, когда в нашу компанию поступил сразу ряд запросов от разных клиентов на обеспечение возможности сквозного поиска по разным корпоративным источникам (сетевым папкам, корпоративным порталам и другим). 

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

• синонимы;

• гипонимы (более частные понятия);

• варианты перевода искомого слова на русский/английский языки.

Например, по запросу «аграрные предприятия» находился текст «птицеводческая ферма», а по запросу «увольнение руководства» — «отставка гендиректора». С одной стороны, это позволило повысить полноту поиска, а с другой — такой поиск работал более точно и прогнозируемо, чем обычный подход с векторами (embeddings). Кроме того, мы сразу интегрировали в продукт нашу собственную технологию OCR, уже проверенную многолетними продажами на мировом рынке. Это позволило включить в область поиска графические файлы в разных форматах, в частности TIFF, PDF и другие.

В качества стека технологий мы выбрали: 

• ElasticSearch как поисковый движок;

• Kibana как средство построения отчетов по обходу источников и статистики поиска;

• Apache Zookeeper для хранения состояния  поискового кластера; 

• Apache Tomcat как веб-сервер;

• Java как основной язык разработки.

Первая версия продукта вышла в 2017 году  и сразу стала тестироваться рядом клиентов. Опираясь на поступающие запросы, мы стали планомерно расширять список поддерживаемых источников и форматов. Сейчас в продукте поддержан поиск по большинству источников, актуальных для российского рынка: 

• сетевым папкам;

• 1С:Документообороту;

• Битрикс24;

• Сonfluence;

• Jira;

• MS Sharepoint;

• MS Azure DevOps (TFS);

• MS Active Directory;

• СУБД (PostgreSQL, MySQL и другим);

• почтовому серверу MS Exchange;

• сервис-деск системе HelpDeskEddy.

Интеграция с каталогом пользователей на базе Active Directory позволила решить задачу аутентификации на базе протокола Kerberos и обеспечить сквозной вход в систему (SSO). Позже мы стали использовать каталог пользователей для фильтрации найденных документов не только по имени автора, но и по его должности или отделу. Также появилась возможность перехода между документами и профилями их авторов или отделов по аналогии с переходами между постами и профилями пользователей в соцсетях. 

При необходимости на стороне клиента можно поддержать поиск по любому источнику данных, разработав модуль его обхода на основе открытого Java API и примеров исходников готовых модулей.

К обычным форматам документов MS Office, OpenOffice и изображений мы со временем добавили все виды архивов, аудио- и видео-файлов, а также чертежи в форматах DWG/DXF.

Внешне решение мы сделали похожим на интернет-поисковик, чтобы пользователи могли легче на него перестроиться. Язык запросов также был сделан близким к языку интернет-поисковика и поддержан на базе парсера ANTLR. Несмотря на кажущуюся простоту, задача корректного поиска по указанной фразе даже в режиме точного совпадения является нетривиальной. Дело в том, что искомые слова в тексте могут идти не рядом, а на расстоянии друг от друга, немного в другом порядке, не все из них нужно учитывать с одинаковым весом (например, предлоги или союзы). Также для некоторых слов или фраз нужно поддержать автоматическое раскрытие на указанные пользователем синонимы. 

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

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

Отдельным вызовом является корректный учет прав доступа в разных источниках. В некоторых источниках, например, сетевых папках или MS Sharepoint, доступ определяется на уровне доменных групп. В других источниках используется своя ролевая модель, никак не связанная с доменной, как в случае с 1С или «Битрикс24». 

Для обеспечения сквозного поиска с учетом прав доступа при обходе источника по каждому его элементу запрашивается набор доменных или внутренних групп, определяющих к нему доступ, и сохраняется в виде отдельного поискового поля. При входе пользователя на сайт поиска автоматически определяется набор групп, к которым он относится, как доменных, так и внутренних (для подключенных источников). Этот набор групп добавляется к запросу как ограничивающий критерий, что гарантирует выдачу в результатах поиска только тех документов, к которым у пользователя есть доступ.

Со временем по запросам клиентов в нашем решении появились: 

• группировка дублей документов;

• иерархические фильтры по источникам;

• поиск похожих документов;

• классификация документов;

• предпросмотр текста документа с сохранением форматирования;

• переход между найденными документами по атрибутивным связям;

• выборочная подсветка найденных терминов. 

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

От поискового портала к платформе цифровых ассистентов

Перечисленные в предыдущем разделе функции сделали поиск нужной информации более оперативным и удобным, но продукт стабильно оставался в нише корпоративных поисковиков. Релиз ChatGPT в 2022 году на продукт повлиял не сразу, так как он обычно использовался внутри контура организации, а вот появление общедоступных локальных языковых моделей в 2023 году все изменило. 

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

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

NLP-модули как ключевой элемент открытой архитектуры

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

Для продукта NLP-модуль — черный ящик, который он вызывает на ряде этапов своей работы. Например, при обходе источника или анализе поискового запроса: на вход в модуль передается набор полей документа или текст запроса, а на выходе модуль возвращает JSON с результатами анализа.

Внутри реализация модуля может быть произвольной — от поиска ИНН в тексте по регексу до вызова LLM для генерации ответа на вопрос или перевода документа на другой язык. Так как архитектурно NLP-модуль является плагином, он может подкладываться в каталог продукта в виде JAR-файла и далее использоваться для кастомизации нужного этапа обработки документа или запроса. Диалог настройки его параметров в административном интерфейсе продукта формируется автоматически на основе аннотаций в коде модуля. Это позволяет развивать функциональность продукта без участия нас как вендора.

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

Самым популярным сценарием использования LLM на корпоративном поисковом портале, безусловно, остается сценарий вопросно-ответного режима или RAG.

Технология RAG включает в себя ряд этапов, каждый из которых реализован в нашем продукте в виде NLP-модуля и может быть кастомизирован на стороне клиента:

• нарезка текста документа на фрагменты (chunking);

• получение вектора по каждому фрагменту (embedding);

• ранжирование и фильтрация найденных контекстов по степени релевантности запросу пользователя (re-ranking);

• генерация ответа на основе релевантных контекстов;

• валидация корректности ответа (другой LLM).

Модуль реализует общий интерфейс INlpGenericModule<I,O>, что позволяет работать с различными типами входных и выходных данных. Приведенная в примере реализация возвращает NlpEntitiesResult, но может быть адаптирована для других форматов ответов.

Созданные и настроенные под каждый этап NLP-модули указываются в настройках векторного поиска и поиска на естественном языке.

Если у вас уже есть собственная реализация RAG на open-source компонентах, и ее требуется расширить под новые источники или форматы, но ресурсов не хватает, наш продукт может выступить готовой платформой для такого масштабирования.

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

Сценарии автоматизации на базе NLP-модулей

Применяя подход с NLP-модулями, можно автоматизировать целый ряд сценариев, выходящих за рамки обычного поиска.

Ассистент по проверке документов на соответствие регламентам

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

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

• автоматический мониторинг данного источника; 

• анализ содержимого каждого регламента;

• извлечение из него атомарных (максимально кратких и простых) требований для дальнейшей проверки.

Эти требования извлекаются LLM и сохраняются в отдельный поисковый индекс. Далее проверяемые документы также поступают в некоторый источник (например, почту или СЭД) и по ним нужно оперативно подготовить отчет по проверке. Для этого на втором этапе настраивается мониторинг источника с входящими документами, и для каждого нового документа запускается проверка по всем ранее извлеченным требованиям. Таким образом, для решения задачи потребуется два NLP-модуля: первый будет извлекать базовые требования из набора регламентов, а второй — проверять их для входящего документа и формировать отчет о проверке. 

Целевой сценарий разбивается на следующие этапы:

• Мониторинг источника с требованиями и регламентами: через коннектор к сетевой папке или корпоративному порталу.

• Извлечение требований для проверки: для каждого регламента NLP-модуль на базе LLM определяет набор атомарных требований для последующей проверки.

• Мониторинг источника, куда поступают документы на проверку: с помощью коннектора к почтовому серверу или сетевой папке.

• Проверка входящего документа на соответствие требованиям: выполняется NLP-модулем, который проверяет соответствие документа набору ранее извлеченных требований.

• Просмотр результата проверки документа: на поисковом портале после получения уведомления по электронной почте.

Ассистент по сверке позиций в смете на закупку со справочником товаров

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

Выходом может стать отчет ассистента по каждой позиции в смете с указанием имеющихся позиций на складе или возможных аналогов.

Для этого на первом этапе с помощью коннектора к СУБД следует загрузить в продукт содержимое справочника товаров из системы складского учета, при котором каждая запись станет отдельным документом. Затем для каждой проверяемой позиции в смете найти похожие в справочнике и оценить с помощью LLM степень близости и правильную формулировку названия. В данном случае будет достаточно одного NLP-модуля, который выполнит данные действия для входящей сметы и по каждой позиции предложит соответствующие позиции в справочнике.

Целевой сценарий разбивается на следующие этапы: 

• Мониторинг справочника товаров в MDM-системе: через коннектор к СУБД или кастомный коннектор через API MDM-системы.

• Мониторинг источника, в который приходят сметы: через коннектор к почтовому серверу или сетевой папке.

• Извлечение товарных позиций и поиск соответствующих им товаров в справочнике: выполняется NLP-модулем, который на базе LLM определяет искомые товарные позиции и выполняет их поиск в справочнике.

• Просмотр результата анализа сметы: на поисковом портале после получения уведомления по электронной почте.

Ассистент по определению максимальной цены для тендера

В качестве третьего примера рассмотрим задачу определения начальной максимальной цены контракта (НМЦК) при подготовке тендерной документации. Заказчику некоторого товара нужно предварительно собрать рыночные предложения по его стоимости и далее использовать среднее значение как максимальное. Для этого ряду поставщиков отправляется запрос на предоставление коммерческого предложения, а затем полученные КП вручную сводятся в общую таблицу и анализируются. 

Этот процесс можно автоматизировать, сделав автоматическую рассылку запроса на КП по заранее определенному шаблону, а после применив LLM для извлечения товарных позиций из полученных ответов. 

Целевой сценарий разбивается на следующие этапы:

• Рассылка запросов на КП: выполняется NLP-модулем в начале обхода указанного почтового ящика (с учетом ранее отправленных писем), которому на вход передаются параметры подключения к почтовому серверу, шаблон письма и список рассылки.

• Мониторинг почтового ящика, на который приходят ответы: через коннектор к почтовому серверу.

• Анализ ответов поставщиков и выделение товарных позиций из КП: с помощью NLP-модуля в процессе мониторинга почтового ящика, который с помощью локальной LLM выделяет из ответов поставщиков товарные позиции и их стоимость в отдельный поисковый индекс.

• Фильтрация по выбранным товарным позициям и определение средней стоимости через экспорт в XLS-файл.

Таким образом, сейчас в рамках нашего продукта закрыт вопрос доступа к данным (форматы, источники и права доступа) и вопрос базовых инструментов на базе LLM — поиск, RAG, извлечение атрибутов, транскрибация, суммаризация и другие функции. 

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

Это блог компании Content AI. Мы помогаем работать с информацией умнее — автоматизировать обработку документов, извлекать данные и повышать качество бизнес-процессов с помощью технологий и AI. Здесь рассказываем, как строим собственные продукты и делимся опытом, архитектурными решениями и кейсами внедрения интеллектуальной автоматизации.

Наш Telegram-канал со всеми новостями: https://t.me/content_ai