В статье описываю практический опыт построения корпоративного ИИ-ассистента: от структуры базы знаний и графовой модели до фильтрации контекста и контроля версий. Материал будет полезен продактам, архитекторам, маркетологам и всем, кто внедряет ИИ в бизнес-процессы.
«Garbage in – garbage out», как мусор в корпоративной Базе Знаний мешает корректной работе ИИ и как мы предлагаем это исправить.
Сегодня многие компании внедряют ИИ-агентов по упрощённому сценарию: загружают PDF-регламенты, Excel-прайсы и архивы переписок в векторную БД, после чего ожидают, что модель будет корректно отвечать на вопросы пользователей.
Такой подход, известный как Naive RAG, в большинстве случаев приводит к нестабильным результатам: несогласованные ответы, ошибки в тарифах, применение устаревших инструкций.
Причина – не в возможностях моделей: современные LLM хорошо работают с контекстом. Проблема – в структуре данных, которые подаются на вход. Если знания представлены в виде фрагментов без связей, версий и семантической целостности, то на выходе появляется то, что обычно называют «галлюцинациями».
В этой статье рассмотрен инженерный подход к подготовке корпоративной базы знаний, который обеспечивает предсказуемую работу RAG-систем.
1. Почему “сырые” данные приводят к ошибкам в RAG
Типовой RAG-пайплайн представляет собой последовательность:
Документ → Текст → Чанки → Векторы.
Критическая проблема – потеря связности и контекста.
1.1. Механическая нарезка текста (Token-based chunking)
На практике документы часто делятся на чанки фиксированной длины – например, по 500 токенов. Это приводит к разрыву семантики.
Пример:
-
Чанк 1: «…при возврате оборудования необходимо проверить уровень масла. Если он ниже нормы…»
-
Чанк 2: «…клиенту выставляется штраф. Это правило касается только генераторов серии X.»
При поиске по запросу «штраф за масло» retriever с большой вероятностью найдёт только второй чанк, в котором нет условий применения правила. LLM интерпретирует контекст неполностью и переносит правило на всю технику.
1.2. Коллизии и версии
Если в базе присутствуют документы «Типовой Договор_2022» и «Типовой Договор_2024», оба будут релевантны по смыслу. В результате модель получит несовместимые данные и попытается объединить их в единый ответ.
2. Подход “Knowledge Base (KB) as Code”
Корпоративную базу знаний можно рассматривать не как набор файлов, а как инженерную систему, в которой каждый фрагмент информации описан структурно, версионируется и снабжен метаданными.
Для хранения удобен формат Markdown с поддержкой Frontmatter (YAML), который оптимально подходит для автоматической обработки.
Один файл содержит сразу несколько слоёв:
-
YAML – метаданные, фильтры поиска, версия, тип сущности
-
Markdown – операционная логика, регламенты, процедуры
-
JSON-блоки – числовые параметры, необходимые для точного извлечения
Пример файла Экскаватор_JCB.md:
YAML (Метаданные)
---
type: asset
status: active
version: 2.1 # Версия документа
security_level: public # Права доступа (public/internal/confidential)
category: earthmoving
---JSON (Факты и цифры)
## Технические характеристики
{
"weight_kg": 8000,
"bucket_capacity_m3": 1.0,
"fuel_tank_l": 160
}Markdown (Логика и связи)
# Экскаватор-погрузчик JCB 3CX
Тип: [[Спецтехника]]
## Связанные документы
- Основной регламент: [[Регламент_Возврата]]
- Техническая карта: [[Инструкция_Гидравлика]]
- Чек-лист: [[Чеклист_Осмотра]]
## Тарифы
- [[Тариф_Стандарт]]
- [[Тариф_Премиум]]2.1. Структурный слой (сущности и факты)
Числовые параметры и статические данные помещаются в JSON для гарантированной точности извлечения.
LLM получает факты напрямую, без попытки «угадывать» значения из текста.
2.2. Операционный слой (Markdown)
Регламенты описываются в структурированном виде, используя иерархию заголовков. Разбиение на чанки происходит на этапе подготовки Базы Знаний по семантическим границам (Logical Chunking) с сохранением контекста.
2.3. Слой метаданных (YAML)
В метаданные могут включаться:
-
версия документа
-
тип сущности
-
бизнес-область
-
регион
-
статус (draft/active/deprecated)
Это позволяет использовать Metadata Filtering, который отсекает нерелевантные документы до выполнения векторного поиска.
2.4. Что хранить в корпоративной базе знаний (и чего не хранить)
KB предназначена прежде всего для структурирования текстовых знаний и операционных правил, которые трудно формализовать в виде таблиц баз данных, но критичны для корректной работы ИИ-ассистентов и внутренних сервисов.
В KB логично хранить:
-
регламенты и инструкции (процедуры, шаги, условия выполнения);
-
описания продуктов и услуг — свойства, ограничения, состав, особенности применения;
-
бизнес-правила и алгоритмы принятия решений;
-
Tone of Voice, политики компании, формальные допущения;
-
шаблоны ответов, эталонные Q&A;
-
связи между сущностями, контекстные ссылки, перекрёстные зависимости.
Эти элементы редко представлены в структурированной форме в корпоративных системах – именно они и становятся основным источником ошибок при Naive RAG, когда подаются в виде произвольного текста.
В то же время операционные данные, которые регулярно меняются, не должны превращаться в источник истины внутри KB.
К таким данным относятся:
-
цены и скидки;
-
остатки на складах;
-
статус заказа или этап выполнения работ;
-
доступность ресурсов и расписания;
-
любые показатели, которые изменяются ежедневно или час-к-часу.
Эти данные должны подгружаться динамически из основной БД компании – через REST/GraphQL API, SQL-представления, event-driven обновления или другой слой интеграции. KB хранит не сами значения, а логику их применения, условия, формулы и контекст, который нужен модели для корректного ответа.
Такой подход позволяет сохранять KB стабильной и версионируемой, избегая дублирования данных и обеспечивая актуальность операционной информации при каждом запросе.
3. Организационные аспекты: данные ≠ документы
Создание корректной базы знаний – не только техническая работа. По наблюдениям, значительная часть усилий уходит на аудит процессов и устранение коллизий. Мы в нашей компании “Комплекс Медиа” проводим обширный анализ бизнеса прежде чем приступить к технической реализации проекта.
3.1. Аудит процессов
Проводятся интервью с экспертами домена: продажи, сервис, склад, техподдержка.
Цель – выявить фактические правила работы и их отклонения от формально описанных.
3.2. Поиск противоречий
Типичные примеры:
-
разные отделы по-разному трактуют штрафы
-
устаревшие правила применяются параллельно с новыми
-
часть операций выполняется «по договоренности», а не по инструкции
Если такие фрагменты загрузить в RAG-систему, модель будет объединять несовместимую информацию.
3.3. Knowledge Mapping
Мы строим граф связей: сущности, процессы, роли, документы.
Графовая визуализация помогает выявлять:
-
Проверку логики: На схеме видно, что у Экскаватора есть прямая связь с «Регламентом возврата». Это критично: если бы этой стрелки не было, RAG-система не знала бы, какие именно правила приемки применять к этой конкретной машине.
-
«Сирот» (Orphans): Мы видим, что «Штраф за грязь» не висит в воздухе, а на него ссылается «Тариф Премиум». Это визуальное подтверждение того, что бизнес-логика (отмена штрафа в тарифе) технически реализована в базе.
-
Влияние изменений: Граф показывает, что изменение в файле «Тариф Премиум» мгновенно повлияет на условия аренды всей техники, которая ссылается на этот тариф (в данном случае – JCB 3CX).
4. Побочные эффекты, не связанные напрямую с ИИ
Структурированная база знаний улучшает процессы ещё до внедрения LLM-ассистентов.
Вот некоторые юзкейсы использования такой базы знаний вне плоскости ИИ:
-
онбординг: ускорение обучения новых сотрудников
-
масштабирование: наличие формальных стандартов позволяет быстрее открывать филиалы
-
контент-генерация: маркетинг опирается на корректные, согласованные данные
5. Валидация архитектуры: синтетический тест
Чтобы подтвердить эффективность подхода Logical Chunking, мы развернули тестовый контур (Python + LangChain + ChromaDB) и загрузили в него подготовленные Markdown-файлы. Для эмбеддинга использовалась open-source модель multilingual-e5.
Цель эксперимента — проверить работу Retriever (поискового модуля) на запросе, требующем сопоставления противоречивых данных (правило vs исключение).
Запрос пользователя:
«Какой штраф если вернул технику грязной?»
Лог работы Retriever (фрагмент):
[Результат #1]
Источник: Тариф_Премиум.md
Контекст: {'Header 1': 'Тариф "Все включено"'}
Текст:
- Бонус: Отмена санкции [[Штраф_Грязь]].
[Результат #2]
Источник: Регламент_Возврата.md
Контекст: {'Header 1': 'Процедура возврата'}
Текст:
2. **Санкции:**
- При нарушении чистоты применяется [[Штраф_Грязь]].Анализ результата:
Система корректно извлекла два критически важных фрагмента:
-
Общее правило из Регламента (штраф существует).
-
Исключение из Тарифа (штраф отменяется).
Второй сценарий проверяет способность системы находить полное описание продукта, не разрывая список его характеристик.
Запрос пользователя:
«Что входит в тариф все включено?»
Лог работы Retriever:
[Результат #1]
Источник: Тариф_Премиум.md
Контекст: {'Header 1': 'Тариф "Все включено"'}
Текст:
- Залог: Нет.
- [[Услуга_Мойка]]: Включена.
- Бонус: Отмена санкции [[Штраф_Грязь]].
[Результат #2]
Источник: Регламент_Возврата.md
🏷Контекст: {'Header 1': 'Процедура возврата'}
Текст:
1. **Осмотр:**
- Проверить чистоту (см. [[Услуга_Мойка]]).Анализ результата:
-
Целостность данных: Первый результат содержит исчерпывающий список условий тарифа. Благодаря нарезке по заголовкам (Header 1), маркированный список не был разорван на части, и LLM получила все параметры (залог, мойка, бонус) в одном контекстном окне.
-
Семантическая связь: Второй результат (Регламент) был подтянут системой, так как он семантически связан с услугами, упомянутыми в тарифе (мойка/чистота). Это дает модели необходимый контекст: она «видит» не только то, что мойка включена, но и то, какой процедуре осмотра она соответствует.
Благодаря сохранению иерархии заголовков (Header 1), LLM получает не просто вырванные из контекста фразы, а структурированные блоки знаний. Это позволяет модели сгенерировать корректный ответ: «Согласно регламенту предусмотрен штраф, однако на тарифе “Все включено” он отменяется».
При использовании механической нарезки (Token-based chunking) связь между тарифом и отменой санкции может потеряться, что приведет к галлюцинациям.
Заключение
Качество работы RAG-систем определяется не только моделью и векторной базой, но прежде всего — подготовкой данных.
Семантическая нарезка, метаданные, контроль версий и структурирование знаний существенно уменьшают вероятность ошибок и обеспечивают стабильную работу ИИ-ассистентов.
Автор: domosedoff
