4-уровневая архитектура базы знаний для повышения точности ИИ-агентов

Разработчик на r/openclaw подробно описал архитектуру структурированной базы знаний, предназначенной для превращения универсальных LLM-агентов в экспертов в предметной области путем предоставления конкретного контекста об инструментах, рабочих процессах и политиках.
Проблема с распространенными подходами RAG
Источник указывает на несколько проблем типичных реализаций RAG: отсутствие классификации запросов (каждый вопрос проходит через один и тот же конвейер извлечения), отсутствие уровней (документы управления обрабатываются так же, как и посты в блоге), отсутствие бюджета (контекстное окно агента забито нерелевантными фрагментами) и отсутствие самовосстановления (устаревшие/сломанные документы остаются сломанными навсегда).
4-уровневый конвейер базы знаний
Система использует четыре различных уровня:
- Уровень управления — Всегда загружен. Содержит идентичность агента, политики и правила как не подлежащий обсуждению контекст.
- Уровень агента — Документация для каждого агента. Например, голосовой агент по имени Люси получает документацию по обработке звонков, а агент по имени Бинки (CRO) получает документацию по конверсиям.
- Релевантный уровень — Динамическое извлечение для каждого запроса с сопоставлением заголовка/содержимого, ограниченное максимум 5 документами и бюджетом в 12K символов на документ.
- Уровень вики — 200+ справочных статей, доступных для поиска через файловый мост, охватывающих историю ИИ, определения инструментов, шаблоны рабочих процессов и сравнения платформ.
Классификация запросов как секретное оружие
Перед любым извлечением классификатор на основе регулярных выражений определяет, сколько контекста требуется вопросу:
- ПРЯМОЙ — Для задач вроде «Обобщи этот текст», где база знаний не нужна.
- ТОЛЬКО_НАВЫК — Для задач вроде «Напиши мне твит», где достаточно документации по навыкам агента.
- ГОРЯЧИЙ_КЭШ — Для вопросов вроде «Кто занимается выставлением счетов?», на которые можно ответить из документов управления и агента в кэше памяти.
- ПОЛНЫЙ_RAG — Для сложных запросов вроде «Сравни цены n8n и Zapier», требующих полного векторного поиска и файлового моста.
Сообщается, что только эта классификация сократила расход токенов примерно на 40%, потому что большинству вопросов не нужен полный RAG.
Структура и организация базы знаний
Каждая из 200+ статей следует единому формату: четкий заголовок с областью охвата, практическое содержание (таблицы, примеры кода, схемы принятия решений), 2+ цитируемых источника с реальными URL, 5 описаний ссылок на изображения и 2 ссылки на видео.
Содержание организовано по конкретным областям:
- Основы ИИ/МО (18 статей) — история, трансформеры, эмбеддинги, агенты
- Инструменты (16 статей) — определения, безопасность, таксономия, обработка ошибок, аудит
- Рабочие процессы (18 статей) — типы, платформы, анализ стоимости, шаблоны HIL
- Генерация изображений (115 файлов) — 16 провайдеров, сравнения, фреймворки промптов
- Генерация видео (109 файлов) — обработки, конвейеры, руководства по платформам
- Поддержка (60 статей) — контент центра помощи клиентам
Система самовосстановления
Архитектура включает систему оценки, которая оценивает состояние базы знаний по шкале от 0 до 100 и автоматически решает проблемы: отсутствующие эмбеддинги запускают повторное встраивание, устаревший контент помечается для обновления, а сломанные ссылки исправляются или удаляются. Сообщается, что показатель состояния улучшился с 71 до 89 после первого прохода восстановления.
Результаты и ключевые выводы
До внедрения базы знаний агенты могли галлюцинировать определения инструментов, выдумывать цены и давать общие советы по рабочим процессам. После внедрения агенты цитируют конкретные документы, предоставляют точные сравнения платформ с реальными ценами и знают, когда сказать: «У меня нет актуальных данных по этому вопросу».
Ключевые выводы от реализации:
- Классифицируйте перед извлечением — не каждому вопросу нужен RAG.
- Бюджетируйте свое контекстное окно — 60K символов всего, с жестким лимитом на документ.
- Структура важнее объема — 200 хорошо организованных статей лучше, чем 10 000 случайных фрагментов.
- Самовосстановление не опционально — базы знаний деградируют, поэтому стройте мониторинг с первого дня.
- Пишите для агентов, а не для людей — отдавайте приоритет таблицам перед абзацами, схемам принятия решений перед прозой, и конкретным примерам перед абстрактными объяснениями.
📖 Read the full source: r/openclaw
👀 Смотрите также

Statespace: Создавайте интерактивные веб-приложения для агентов OpenClaw с помощью Markdown
Statespace — это бесплатный, открытый фреймворк для создания и обмена веб-приложениями, совместимыми с ИИ, которыми агенты OpenClaw могут управлять и взаимодействовать с ними, используя чистый Markdown. Он позволяет определять инструменты, компоненты и инструкции в Markdown-файлах, к которым агенты получают доступ через HTTP.

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

О, Моя Русалка: Навык Клода для Автоматического Создания Архитектурных Диаграмм
Oh-My-Mermaid — это навык Claude Code, который анализирует кодовые базы и автоматически генерирует архитектурные диаграммы Mermaid и документацию. Устанавливается через npm и используется с командой /omm-scan в Claude Code.

Отладка логики проверки сборки Claude Code: почему поиск по имени не работает и как поиск по структурному слепку это исправляет
Claude Code сказал пользователю «функция не встроена» четыре раза за одну сессию — и каждый раз ошибался. Решение: заменить поиск по названию на поиск по структурному следу (маршруты, схемы, зарегистрированные инструменты). Практическое правило опубликовано.