Как собрать LLM Wiki: карта знаний для ИИ-агента

Минимальная архитектура LLM Wiki — три слоя. Без них агент снова превращается в «чат с файлами».

project/
  raw/          ← исходники (не переписывать моделью)
  wiki/         ← страницы, которыми владеет LLM
  AGENTS.md     ← schema: правила игры
  (или CLAUDE.md)

Что класть в raw и чего туда не тащить

raw/ — источник правды. Сюда кладут статьи, PDF, выгрузки, брифы, скриншоты текста, транскрипты. Модель только читает. Не просите её «подчистить» оригинал: иначе потеряете возможность сверить факты.

Кладите:

• утверждённые бренд-материалы;
• ссылки/копии research-статей;
• внутренние гайды и FAQ в исходном виде;
• выгрузки конкурентов и ТЗ.

Не кладите:

• пароли, ключи API, персональные данные клиентов;
• черновики «на удалить» без пометки;
• дубли одного и того же PDF в трёх версиях без даты.

Для приватных брендовых баз из России учитывайте риск: облачная модель при ingest видит содержимое raw. Если данные чувствительные — используйте локальную модель, вырезайте секреты до загрузки или держите HITL-политику (human-in-the-loop: сначала человек проверяет источники и запись в wiki, потом агент идёт дальше).

Как wiki становится «мозгом», а не копией сырья

wiki/ — Markdown, которым владеет LLM. Здесь живут:

• саммари источников;
• страницы сущностей (бренд, продукт, персона, оффер);
• концепты (GEO, tone of voice, CTA-правила);
• сравнения и синтез;
• полезные ответы на прошлые query, которые стоит сохранить.

Важно: wiki — не копия raw. Ingest должен отвечать не на вопрос «о чём статья?», а на вопрос «как эта статья меняет мою базу?». Один хороший ingest часто трогает сразу 10–15 связанных страниц: обновил бренд-карточку, добавил концепт, поправил FAQ, проставил связи.

Связи удобно делать через wikilinks — внутренние ссылки вида [[Tone of Voice]]. Это «нити» между страницами: агент и человек видят граф знаний, а не россыпь одиночных файлов.

Schema как правила игры агента (AGENTS.md / CLAUDE.md)

Без schema агент пишет что хочет и как хочет. Со schema он становится wiki-maintainer: знает структуру папок, имена файлов, шаги ingest/query/lint и запреты.

Минимальный каркас schema под контент:

1. Цель wiki (бренд + research + editorial rules).
2. Дерево папок raw/ и wiki/.
3. Типы страниц: source, brand, concept, offer, faq, exploration.
4. Правила имён файлов (латиница/кириллица — выберите одно и держитесь).
5. Workflow: ingest → обновить index/log → query только по wiki → lint.
6. Claim-policy: что нельзя утверждать без источника.
7. Когда сказать «в wiki нет покрытия» вместо фантазии.

Пошаговая сборка LLM Wiki за один вечер

Ниже — контур, который новичок может повторить без бэкграунда разработчика. Достаточно Cursor, Claude Code, Codex или другого агента с доступом к файлам проекта. Из России удобны сценарии с локальной папкой + git; облачные агенты и зарубежные API иногда требуют рабочий способ оплаты/доступа — если сервис недоступен, тот же контур собирается в локальном редакторе Markdown + агент с доступом к диску.

Признак успеха всего контура:

• в wiki есть 3+ осмысленных страницы и актуальный index;
• ответ на query ссылается на wiki-файлы, а не «из общей эрудиции»;
• lint-отчёт существует и по нему понятно, что чинить;
• raw не изменён.

Типичные ошибки новичка

1. Просят «саммари статьи» вместо ingest → в базе появляется пересказ, связи не обновляются. Решение: в промпте явно писать «как источник меняет wiki».
2. Сразу заливают 30 PDF пакетом → агент плодит шумные страницы и жжёт токены. Решение: 1 источник → проверка → следующий.
3. Нет schema → имена файлов хаотичные, типы страниц смешаны. Решение: сначала AGENTS.md, потом ingest.
4. Query к raw «на всякий случай» → снова чат с дампом. Решение: контракт «сначала index и wiki; raw только при ingest».

Что писать в log.md после каждого захода

log.md — append-only таймлайн. Удобный формат:

### [2026-07-28] ingest | Offer FAQ
- raw: raw/sources/2026-07-28-offer-faq.md
- updated: wiki/brand/offer.md, wiki/concepts/cta-rules.md
- notes: добавлен запрет обещать топ-1 без оговорки

Так вы можете grep’ом найти, когда в базу попал спорный факт.

Как не смешать сырьё и уже сжатые выводы

Золотое правило:

• raw = «что сказали источники»;
• wiki = «что мы из этого решили держать как рабочее знание»;
• если вывод гипотетический — страница типа exploration, не brand.

Не копируйте длинные цитаты в каждую карточку. Короткий тезис + ссылка на raw + дата проверки.

Без lint wiki деградирует тише, чем RAG: ошибки уже записаны красивым Markdown и выглядят убедительно.

Чеклист рассинхрона wiki ↔ raw

Прогоняйте регулярно (после серии ingest или перед важной публикацией):

1. Есть ли в wiki факты, которых больше нет в raw / на сайте?
2. Не противоречат ли brand и faq друг другу?
3. Есть ли [[ссылки]] на несуществующие страницы?
4. Есть ли страницы без входящих ссылок (orphans)?
5. Упомянуты ли концепты, у которых нет своей страницы?
6. Не дублируются ли две карточки одного оффера под разными именами?
7. Помечены ли спорные места как draft, а не verified?
8. Нужен ли sync после обновления сайта/репозитория: unchanged / corrected / uncovered?

В разборах coding-агентов для wiki иногда делают десятки автопроверок и даже отдельных «read-only» подагентов на verify. Вам на старте хватит короткого чеклиста выше + запись результата в log.md.

Когда без человека на фактах нельзя

Человек обязателен, если:

• меняются цены, гарантии, юридические формулировки;
• в wiki попадают цифры аудитории, кейсы, обещания результата;
• ingest шёл из сомнительного или рекламного источника;
• агент «достроил» страницу, хотя raw покрывал тему частично.

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

LLM Wiki особенно сильна там, где несколько ролей должны говорить одним голосом: ресёрч, копирайт, редактура, публикация.

От карточки wiki до черновика публикации

Рабочий цикл контент-завода:

1. Ingest research и бренд-обновлений в wiki.
2. Query: «собери бриф лонгрида по кластеру X» → структура H2, факты, запреты.
3. Генерация черновика строго по брифу и wiki-ссылкам.
4. Lint wiki + фактчек цифр человеком.
5. Публикация; ценные выводы query при желании возвращаются в explorations/.

Так агент не «сочиняет нишу заново», а опирается на карту, которую вы уже курируете.

Где субагенты читают одну карту, а не спорят в чате

Если у вас несколько агентов (ресёрчер, копирайтер, аудитор), дайте им одну wiki и одну schema. Иначе каждый ведёт свой чат-память и выдаёт разные tone of voice.

Практика:

• субагент A только ingest/research;
• субагент B только query→draft;
• субагент C только lint/QA по чеклисту;
• все пишут в один git-репозиторий Markdown.

Это и есть мост к MCP/агентному пайплайну без оверинжиниринга: сначала дисциплина папок и правил, потом инструменты.