У девелопера Level Group сотни проектных документов, регламентов и инструкций, которые охватывают самые разные сферы: от стандартов строительства и IT-архитектуры до маркетинга и управляющей компании.

Объем информации постоянно растет, и стандартный поиск не всегда позволяет сотрудникам быстро находить нужные данные. Чтобы ускорить поиск информации и помочь сотрудникам быстрее получать точные ответы, мы вместе с командой Level Group запустили ИИ-ассистента.

Задача и ограничения

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

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

Например, на запрос «каков порядок действий при обнаружении дефекта» базовый поиск выдаст только шаблон акта осмотра. Графовый RAG работает иначе: захватив один текстовый вектор, он автоматически подтягивает связанные с ним регламенты по расчетам с подрядчиками, строительным ГОСТам и срокам устранения.

Чтобы ИИ-ассистент ориентировался в базе так же свободно и быстро, как опытный методолог, мы спроектировали архитектуру на базе фреймворка LightRAG. Он объединяет векторный алгоритм с графовым поиском. Решение трансформирует базу знаний в графовую структуру, связывая документы в единые смысловые кластеры.

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

Иван Лавров
Руководитель AI-направления KTS
«Целью запуска на одном источнике было проверить реальную ценность ИИ-ассистента. Важно было понять, насколько часто сотрудники будут им пользоваться и как оценят качество и время ответов. На основе этих данных предстояло решить, как развивать инструмент дальше».

Как устроена архитектура поиска

Чтобы не собирать архитектуру с нуля под каждый проект, мы реализуем такие решения на базе KTS AI Platform — единой платформы для ИИ-продуктов.

В случае с Level Group мы развернули платформу и подключили к ней корпоративную wiki заказчика. Сотрудники задают вопросы через интерфейс чата корпоративной платформы — по опыту использования это похоже на диалог с ChatGPT. К каждому ответу система автоматически прикрепляет ссылки на исходные статьи xWiki, чтобы пользователь мог в один клик проверить факты. При этом ключевая работа в этом проекте происходит на этапах подготовки данных и настройки алгоритмов поиска.

1. Подготовка данных через DataValidator: почему нельзя просто подключить базу к LLM-модели

Качество работы RAG-системы напрямую зависит от исходных данных. В базовом сценарии разработчики подключают корпоративное хранилище к поиску и сразу передают информацию языковой модели.

Однако в реальных базах знаний этот подход имеет ограничения. Корпоративную wiki наполняют разные отделы, поэтому со временем часть регламентов устаревает, документы начинают дублировать друг друга, а описание одного бизнес-процесса распределяется по десяткам статей. В таком слабоструктурированном массиве поисковый алгоритм выбирает фрагментарные сведения, и языковая модель путается в версиях документов.

Чтобы решить эту проблему, мы задействовали DataValidator — нашу собственную разработку. Поисковые алгоритмы изначально поддерживают различные варианты RAG-архитектуры, но вызовы Level Group потребовали глубокой работы с качеством самого массива данных перед тем, как настраивать поиск.

DataValidator имеет два сценария работы: поиск прямых конфликтов в регламентах и поиск смысловых дубликатов. В проекте с Level Group мы сфокусировались на втором сценарии. Инструмент автоматически сканирует всю корпоративную базу и подсвечивает статьи, которые дублируют друг друга или описывают один бизнес-процесс по частям.

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

В итоге ИИ-ассистент получает доступ только к консистентному массиву, где нет противоречий и дублирования.

2. Алгоритмы поиска: как LightRAG объединяет графовый и векторный методы

Несмотря на ограничения классического векторного поиска в сложной аналитике, мы не стали от него отказываться. В проекте для Level Group графовый поиск не заменяет векторный, а работает вместе с ним. Фреймворк LightRAG строит гибридный индекс, в котором одновременно работают два поисковых механизма:

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

Графовый поиск. Связывает документы и сущности в единое «дерево знаний». Это необходимо для сложных аналитических запросов, когда ответ разбросан по разным разделам базы или требует общего понимания структуры хранилища (мета-запросы) — например, чтобы собрать порядок действий при обнаружении дефекта на объекте.

Мета-запросы возникают, когда пользователь хочет оценить весь массив информации. Например: «По каким темам ты можешь дать консультацию?» или «Какие типы сервисов описаны в базе знаний?». Если в базе нет отдельной обобщающей статьи на эту тему, векторная модель не сможет на них ответить корректно. Она ограничена фиксированным числом фрагментов на выдачу (top-N) и вытащит лишь случайные изолированные куски текста. При графовом подходе алгоритм извлекает смысловые кластеры и видит дерево знаний целиком, поэтому собирает информацию со всех разделов.

Зоны ответственности поисковых алгоритмов в архитектуре ассистента

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

Мы проверили работу ИИ-ассистента на подготовленном массиве данных — точность ответов превысила 90%

Что дальше

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

Всеволод Нечитайленко
Директор по цифровым технологиям и операционной эффективности, Level Group
«RAG сегодня остается одним из самых результативных сценариев применения искусственного интеллекта в корпоративной среде. Знания в крупных компаниях накапливаются годами в инструкциях, регламентах и стандартах, но хранятся разрозненно: в файловых хранилищах, базах знаний, корпоративных порталах и множестве других систем. Такой подход дает сотрудникам единый доступ к этой информации и помогает быстро находить нужное в комфортном диалоговом формате.

Для нас это начало пути. Следующий этап гораздо интереснее: модели будут учитывать внутренний контекст, корпоративные правила и накопленную экспертизу компании, чтобы помогать сотрудникам решать конкретные рабочие задачи».