Короткий ответ: LLM Wiki не заменяет RAG и не гарантирует стопроцентную точность. Но для небольшого ядра критически важных знаний — регламентов, договоров, технической документации и сложных исследований — связанная семантическая карта может быть надёжнее наивного RAG с механической нарезкой текста. Для больших и постоянно обновляемых массивов данных практичнее RAG или гибридная архитектура.
Проблема не в самом RAG, а в его упрощённой реализации: документ режут на фрагменты без учёта структуры, превращают в векторы и надеются, что поиск найдёт именно тот кусок, который нужен для ответа. Когда цена ошибки высока, одной математической близости текста может оказаться недостаточно.
Что такое RAG и почему чанки теряют контекст
RAG, или Retrieval-Augmented Generation, — это архитектура, в которой языковая модель перед ответом получает информацию из внешнего источника. Обычно процесс выглядит так:
- Документы разбиваются на фрагменты.
- Для фрагментов создаются векторные представления.
- Запрос пользователя также преобразуется в вектор.
- Поиск выбирает наиболее похожие фрагменты.
- LLM формирует ответ на основании найденного контекста.
Размер чанка не имеет универсального стандарта. Он может измеряться символами, словами или токенами и должен подбираться под документы и тип запросов. Поэтому утверждение, что RAG всегда использует фрагменты по 400–600 символов, некорректно.
Проблемы возникают, когда механическая нарезка отделяет правило от исключения, определение — от примечания, а пункт договора — от связанного приложения. Поиск может найти текст, похожий на запрос, но не тот набор положений, который необходим для правильного вывода.
Особенно опасны такие ошибки в юридических документах, внутренних регламентах, медицинских инструкциях, финансовых правилах и технических процедурах. Здесь AI-система должна не просто найти знакомые слова, а восстановить связи между несколькими источниками.
Что такое LLM Wiki и семантическая карта
LLM Wiki — предложенный Андреем Карпаты паттерн базы знаний, в которой модель не только ищет по исходным документам, но и постепенно создаёт поддерживаемую структуру связанных Markdown-страниц.
В базовой архитектуре используются три слоя:
- Raw sources — неизменяемые исходные документы.
- Wiki — созданные моделью страницы о понятиях, объектах, источниках, противоречиях и связях.
- Schema — инструкции, определяющие структуру базы, правила обработки источников и требования к ответам.
Файл index.md служит каталогом: содержит названия страниц, краткие описания и ссылки. Получив вопрос, AI-агент сначала изучает индекс, затем открывает релевантные страницы и при необходимости переходит по перекрёстным ссылкам.
Это не готовая универсальная технология и не признанный стандарт с доказанной точностью. Скорее, это практический паттерн управления знаниями, рассчитанный прежде всего на умеренные объёмы информации. Сам Карпаты описывает работу примерно со 100 источниками и сотнями Wiki-страниц, а не с миллионами документов.
RAG против LLM Wiki: ключевые различия
| Критерий | Классический RAG | LLM Wiki |
|---|---|---|
| Подготовка данных | Разбиение документов и создание поискового индекса | Чтение источников и создание связанных тематических страниц |
| Търсене | Семантический, полнотекстовый или гибридный поиск | Навигация по индексу, страницам и перекрёстным ссылкам |
| Работа со связями | Зависит от чанкинга, метаданных и архитектуры retrieval | Связи фиксируются заранее в структуре Wiki |
| Масштабирование | Подходит для больших и динамических массивов | Практичнее для умеренного объёма отобранных знаний |
| Стоимость подготовки | Относительно низкая при простой индексации | Выше из-за анализа, обобщения и связывания источников |
| Обновление | Можно автоматически переиндексировать изменённые документы | Нужно обновлять страницы, связи, выводы и индекс |
| Проверяемость | Можно показать найденный исходный фрагмент | Нужна явная связь Wiki-страницы с первоисточником |
Почему сравнение с «наивным RAG» может вводить в заблуждение
Современный RAG давно не ограничивается случайными одинаковыми чанками и поиском ближайших векторов. В production-системах применяются:
- Разбиение по заголовкам, разделам и смысловым границам.
- Родительские и дочерние фрагменты.
- Гибридный поиск по embeddings и ключевым словам.
- Фильтрация по метаданным.
- Переформулирование запроса.
- Reranking найденных фрагментов.
- Контекстуализация чанков.
- Графы знаний и многоэтапный поиск.
- Проверка ответа по первичным источникам.
Например, Anthropic показала, что добавление контекста к чанкам и последующее ранжирование снижает количество неудачных поисков в её тестах. Microsoft GraphRAG строит граф сущностей и отношений и использует иерархические сводки для вопросов, требующих анализа всего массива данных.
В тестах Microsoft GraphRAG превосходил наивный RAG по полноте и разнообразию ответов примерно в 70–80% сравнений. Но это не означает 70–80% общей точности и не доказывает превосходство графового подхода для любого запроса. Исследование оценивало определённый тип глобальных вопросов на двух наборах данных с использованием LLM-судьи.
Может ли семантическая карта устранить галлюцинации
Нет. Семантическая карта уменьшает некоторые риски потери контекста, но создаёт новые:
- Модель может неверно пересказать исходный документ.
- Важная деталь может не попасть в Wiki-страницу.
- Связь между понятиями может быть построена ошибочно.
- После обновления источника часть страниц может остаться устаревшей.
- Выводы разных источников могут быть объединены без достаточных оснований.
- Агент может выбрать неверный маршрут по индексу.
Поэтому заявления об «80% точности RAG», «10 из 10 для LLM Wiki» или «стопроцентной точности» нельзя использовать при выборе архитектуры. Без тестового набора вопросов, правильных ответов и измеримой методики эти цифры остаются рекламными формулировками.
Для процессов с высокой ценой ошибки необходимо предусмотреть цитирование источников, журналирование действий и подтверждение критических решений человеком. Подробнее эти меры разобраны в материале о безопасности AI-агентов и ограничении доступа к данным.
Когда выбирать RAG
RAG обычно лучше подходит, если:
- Документов много и они регулярно обновляются.
- Нужен быстрый поиск по каталогу, переписке или базе обращений.
- Большинство вопросов относится к отдельным фактам или документам.
- Важна автоматическая синхронизация с CRM, облачным хранилищем или сайтом.
- Нужно обслуживать большое количество запросов.
- Есть возможность создать набор тестов и настроить retrieval под реальные вопросы.
Такая архитектура подходит для поддержки клиентов, поиска по базе знаний, разбора документов и других сценариев AI-автоматизации бизнеса.
Когда полезна LLM Wiki
Связанная Wiki может оказаться полезнее, если:
- Источников относительно немного, но каждый из них важен.
- Ответ требует сопоставления нескольких документов.
- Нужно накапливать выводы, а не заново собирать их при каждом запросе.
- Важны противоречия, зависимости, версии и история изменений.
- Базу знаний должен регулярно проверять эксперт.
- Результат требуется хранить в понятном человеку формате.
Примеры — нормативная база проекта, техническая документация сложного продукта, материалы due diligence, исследовательская база или внутренние правила компании.
Гибридная архитектура: практичный вариант для бизнеса
В большинстве корпоративных проектов выбирать только один подход необязательно. Надёжнее разделить знания на два уровня:
- RAG-слой индексирует большой массив документов, писем, обращений и обновляемых данных.
- Wiki-слой хранит проверенные определения, правила, связи, противоречия и выводы по критически важным темам.
- Маршрутизатор определяет, какой источник использовать для конкретного вопроса.
- Модель формирует ответ с указанием исходных документов.
- Контрольный слой проверяет наличие доказательств и передаёт спорные случаи специалисту.
Такой workflow можно включить в более широкую систему: источник запроса → классификация → поиск по RAG и Wiki → проверка доказательств → ответ → запись результата в CRM или передача менеджеру. Это один из вариантов реализации AI-ассистента или корпоративного чат-бота.
С какого MVP начать
Не стоит сразу индексировать всю корпоративную информацию. Для проверки архитектуры достаточно:
- Выбрать один процесс и 20–50 реальных документов.
- Собрать 30–100 вопросов, которые действительно задают сотрудники или клиенты.
- Зафиксировать правильные ответы и обязательные источники.
- Создать базовый RAG с осмысленным чанкингом и reranking.
- Отдельно сформировать Wiki для наиболее связанных и критичных правил.
- Сравнить полноту ответа, точность цитирования, задержку и стоимость.
- Проверить обновление и удаление устаревших данных.
- Оставить человеку подтверждение для критических действий.
Такой пилот соответствует подходу «разбор процесса → план → MVP → тестирование → запуск», описанному в процессе разработки CenterAI.
Главный вывод
Семантическая карта действительно может быть надёжнее наивной нарезки документов, когда ответ зависит от связей, исключений и нескольких источников. Но LLM Wiki не является универсальной заменой RAG и не устраняет ошибки модели.
Практический выбор делается не по модному названию архитектуры, а по результатам тестирования на реальных вопросах. Для больших динамических массивов обычно нужен развитый RAG. Для критического ядра знаний полезна поддерживаемая Wiki. В сложных проектах оптимальным решением часто становится их комбинация.
Чтобы определить подходящую архитектуру и объём пилота, можно обсудить процесс и оценить MVP с CenterAI.
FAQ
Нужна ли RAG-системе векторная база данных?
Не всегда. Retrieval может использовать полнотекстовый, векторный или гибридный поиск. Для небольшого проекта достаточно локального индекса, а для масштабной системы могут применяться специализированные базы или поисковые платформы.
Можно ли построить LLM Wiki без Claude Code?
Да. Это архитектурный паттерн, а не функция одного продукта. Его можно реализовать с помощью Codex, Claude Code, собственного AI-агента или другого инструмента, способного читать и изменять файлы по установленным правилам.
Что дешевле: RAG или LLM Wiki?
Ответ зависит от числа документов, частоты обновлений, количества запросов и используемых моделей. Wiki требует затрат на предварительный анализ и поддержку структуры. RAG требует расходов на индексацию, поиск, reranking и обработку контекста. Стоимость необходимо измерять на конкретном MVP.
Подходит ли LLM Wiki для юридической базы?
Она может использоваться как навигационный и аналитический слой, но не должна заменять оригинальные нормативные документы. Каждый вывод должен быть связан с первоисточником, датой его действия и проверяемой цитатой.
Източници и проверка
Дата последней проверки: 20.08.2026
- https://arxiv.org/abs/2005.11401 — первоначальная научная работа о Retrieval-Augmented Generation.
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f — описание паттерна LLM Wiki Андреем Карпаты.
- https://github.com/microsoft/llmwiki — открытая реализация LLM Wiki от Microsoft.
- https://www.anthropic.com/engineering/contextual-retrieval — исследование Anthropic о контекстуализации чанков и reranking.
- https://www.microsoft.com/en-us/research/project/graphrag/ — проект Microsoft GraphRAG.
- https://www.microsoft.com/en-us/research/blog/graphrag-new-tool-for-complex-data-discovery-now-on-github/ — описание оценки GraphRAG в сравнении с наивным RAG.