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

«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), который оптимально подходит для автоматической обработки.

Один файл содержит сразу несколько слоёв:

1. YAML - метаданные, фильтры поиска, версия, тип сущности

2. Markdown - операционная логика, регламенты, процедуры

3. 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

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

Графовая визуализация помогает выявлять:

1. Проверку логики: На схеме видно, что у Экскаватора есть прямая связь с «Регламентом возврата». Это критично: если бы этой стрелки не было, RAG-система не знала бы, какие именно правила приемки применять к этой конкретной машине.

2. «Сирот» (Orphans): Мы видим, что «Штраф за грязь» не висит в воздухе, а на него ссылается «Тариф Премиум». Это визуальное подтверждение того, что бизнес-логика (отмена штрафа в тарифе) технически реализована в базе.

3. Влияние изменений: Граф показывает, что изменение в файле «Тариф Премиум» мгновенно повлияет на условия аренды всей техники, которая ссылается на этот тариф (в данном случае - 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. **Санкции:**
- При нарушении чистоты применяется [[Штраф_Грязь]].

Анализ результата:
Система корректно извлекла два критически важных фрагмента:

1. Общее правило из Регламента (штраф существует).

2. Исключение из Тарифа (штраф отменяется).

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

Запрос пользователя:

«Что входит в тариф все включено?»

Лог работы Retriever:

[Результат #1]
Источник: Тариф_Премиум.md
Контекст: {'Header 1': 'Тариф "Все включено"'}
Текст:
- Залог: Нет.
- [[Услуга_Мойка]]: Включена.
- Бонус: Отмена санкции [[Штраф_Грязь]].

[Результат #2]
Источник: Регламент_Возврата.md
?Контекст: {'Header 1': 'Процедура возврата'}
Текст:
1. **Осмотр:**
- Проверить чистоту (см. [[Услуга_Мойка]]).

Анализ результата:

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

2. Семантическая связь: Второй результат (Регламент) был подтянут системой, так как он семантически связан с услугами, упомянутыми в тарифе (мойка/чистота). Это дает модели необходимый контекст: она «видит» не только то, что мойка включена, но и то, какой процедуре осмотра она соответствует.

Благодаря сохранению иерархии заголовков (Header 1), LLM получает не просто вырванные из контекста фразы, а структурированные блоки знаний. Это позволяет модели сгенерировать корректный ответ: «Согласно регламенту предусмотрен штраф, однако на тарифе "Все включено" он отменяется».

При использовании механической нарезки (Token-based chunking) связь между тарифом и отменой санкции может потеряться, что приведет к галлюцинациям.

Заключение

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