Привет, меня зовут Рамиль. Я пришел в LLM‑тему из инженерии качества: раньше занимался QA, автоматизацией тестирования и проверкой систем, а сейчас все больше работаю на стыке data science, LLM‑инструментов и прикладных AI‑workflow. Поэтому, когда появляется новая красивая идея, мне мало посмотреть демо. Хочется понять, где у нее границы, какие failure modes, что можно тестировать и получается ли собрать из этого рабочий процесс, а не очередное «вау, оно ответило».

Недавно я наткнулся на идею LLM Wiki, которую популяризировал Андрей Карпатый: использовать LLM не только как чат или RAG‑обертку над документами, а как агента, который постепенно строит и поддерживает личную базу знаний. Я решил проверить это руками: взял Obsidian, Codex, несколько статей с Хабра компании и собрал маленькую wiki, где модель не просто пересказывает источники, а раскладывает их по понятиям, строит связи, пишет синтезы и даже запускает lint собственной базы знаний.

Ниже — что получилось, как устроен workflow, чем это отличается от RAG и почему мне кажется, что это особенно хорошо ложится на личные заметки, ресерч и подготовку материалов.

Проблема: LLM отвечает, но не накапливает

Обычная работа с LLM и документами выглядит так: загрузили PDF, markdown или набор статей, задали вопрос, модель достала релевантные фрагменты и сгенерировала ответ. Если упростить, это RAG: retrieval augmented generation. Подход полезный, особенно когда есть приложение, пользователи, runtime‑запросы, SLA, индексы, права доступа и нормальная production‑инфраструктура.

Но в личной работе с знаниями у RAG есть неприятное свойство: он часто «ответил и забыл». Допустим, я прочитал несколько статей про LLM‑системы: одна про guardrails, другая про evaluation, третья про OCR, четвертая про AI‑агентов в BI. Я спрашиваю модель: «что между ними общего?» Она может дать хороший синтез, но если он остался только в чате, завтра его снова придется собирать с нуля.

LLM Wiki предлагает другой ход: не просто отвечать на вопросы, а компилировать знания в постоянный markdown‑слой. Источники остаются как raw data, а поверх них появляется wiki: карточки источников, понятия, связи, противоречия, сохраненные query‑ответы, synthesis‑страницы и lint‑отчеты.

Что такое LLM Wiki

В моем понимании LLM Wiki состоит из трех слоев. Первый — raw sources: статьи, PDF, заметки, транскрипты, документы. Это source of truth, их не редактируем. Второй — wiki: обработанный слой, где лежат карточки источников, страницы понятий, связи, синтезы и ответы. Третий — rules/schema: инструкции для агента, как делать ingest, как писать карточки, какие файлы обновлять и где вести лог.

В моем эксперименте raw‑слой — это статьи с Хабра, сохраненные в markdown через браузерный скрапер. Wiki‑слой — обычные markdown‑файлы в Obsidian. Правила — файл AGENTS.md, где описано, как Codex должен поддерживать базу.

Получилась простая, но рабочая метафора: Obsidian — IDE для знаний, markdown — кодовая база, Codex — агент‑maintainer.

Три операции: ingest, query, lint

Ingest — добавление нового источника. Я сохраняю статью в raw/habr/ и говорю Codex:

Выполни ingest для всех новых файлов из raw/habr по правилам AGENTS.md.

Codex читает статью, создает карточку в wiki/sources/, выделяет главную идею, тезисы, тон, ограничения, практические приемы, создает или обновляет страницы понятий в wiki/concepts/, добавляет связи в wiki/relations.md, обновляет wiki/index.md и пишет событие в wiki/log.md.

Здесь важно не обмануться простотой команды. Ingest — не бесплатный «пересказ файла», а дорогая операция чтения, анализа и записи. Если источников 5, можно экспериментировать почти без боли. Если их 50–100, да еще это многостраничные PDF, каждый плохо продуманный тег, лишняя сущность или неудачная секция в схеме начинает стоить денег и времени: модель заново читает большие куски текста, обновляет десятки страниц и иногда размножает ошибочную структуру по всей wiki. На облачных моделях это прямой счет за токены. На локальной модели счет не приходит, но нужна достаточно мощная машина, чтобы держать качество связей на больших данных и не ждать вечность.

Важная разница: summary отвечает на вопрос «о чем была статья?», а ingest — «как эта статья меняет мою базу знаний?».

Query — вопрос к уже собранной wiki. Например: «чем LLM Wiki отличается от обычного RAG?» или «что общего у этих статей по тону и инженерным выводам?». Codex сначала смотрит wiki/index.md, wiki/relations.md, source cards и concept pages, а потом отвечает по накопленному слою. Если ответ ценный, он сохраняется в wiki/queries/, то есть сам вопрос тоже становится частью базы.

Lint — проверка здоровья wiki. Codex ищет слабо связанные страницы, недостающие понятия, дубли, противоречия, устаревшие выводы и темы, которые стоит изучить следующими. Это похоже на поддержку кодовой базы, только вместо code smell появляются knowledge smell: понятие часто встречается, но у него нет страницы; source card есть, но она никуда не ведет; вывод не привязан к источнику; граф распадается на островки.

Эксперимент: четыре статьи, одна карта

Для теста я взял четыре статьи с Хабра:

• про GLiNER Guard и LLM‑гардрейлы;

• про DeepEval, GPT-4o и YandexGPT для оценки LLM‑классификатора;

• про HunyuanOCR и распознавание документов;

• про AI‑powered BI на Apache Superset и MCP.

Если просто сложить их в папку, это четыре отдельных текста. Но после ingest Codex выделил общий слой: все они про production LLM‑системы. Одна статья раскрывает safety и guardrails, вторая — evaluation и метрики, третья — ingest документов и контроль генерации, четвертая — агентную работу с инструментами, BI, MCP, правами и аудитом.

В wiki появились страницы понятий: Продакшен LLM-системы, Prompt engineering, LLM evaluation, LLM-гардрейлы, AI-агент, Информационная безопасность, MCP, Контроль генерации, Schema-driven подход, Каскадная архитектура. Это уже не набор summaries, а маленькая карта темы.

Именно здесь Obsidian начинает продавать идею лучше текста: открываешь graph view и видишь, как разные статьи сходятся на общих узлах.

Структура vault

• raw/ хранит неизменяемые источники. 

• wiki/sources/ — карточки источников. 

• wiki/concepts/ — семантический слой. 

• wiki/synthesis/ — большие обобщения. 

• wiki/queries/ — сохраненные ответы. 

• wiki/lint/ — отчеты проверки. 

• index.md нужен для навигации,

• relations.md — для явной таблицы связей, 

• log.md — для истории операций. 

• AGENTS.md дисциплинирует модель: куда писать, как называть файлы, как отделять факт от интерпретации, что обновлять после каждой операции.

Без такого файла все быстро превращается в разноформатные заметки. С ним Codex работает не как «чат, который что‑то придумал», а как агент в проекте с правилами.

Что делает Codex

В текущей версии никакой сложной инфраструктуры нет. Я просто работаю с Codex внутри папки проекта:

• Выполни ingest для новых статей.

• Сделай query по wiki.

• Запусти lint и создай отчет.

Codex читает правила, смотрит структуру, редактирует markdown и поддерживает wiki. Ключевое здесь — не просить «сделай красивый пересказ», а задавать workflow: raw не трогать, карточку создать по шаблону, понятия обновить, index/relations/log поддержать, ограничения и trade‑off зафиксировать.

По ощущениям, это разница между «спросить стажера, что он думает» и «дать инженеру репозиторий, правила проекта и задачу внести изменения».

Можно ли без Codex

Да. Codex просто удобен, потому что умеет работать с файлами и редактировать проект. Но тот же workflow можно собрать скриптами: watcher следит за raw/, находит новые markdown‑файлы, отправляет их в локальную или API LLM, получает structured output, создает source cards, обновляет concept pages, перестраивает index.md и дописывает log.md.

Дальше можно добавить human‑in‑the‑loop: агент предлагает diff, человек ревьюит, правит или принимает, после чего изменения попадают в wiki. Для личного workflow это хороший баланс: LLM делает рутину, человек сохраняет контроль над смыслом.

Не обязательно сразу строить «production платформу знаний». Можно начать с простого: папка, markdown, Obsidian, Codex, три команды.

Короткая оценка стоимости LLM Wiki на Yandex Foundation Models

Расчет для моего демо‑vault на 29 июня 2026. Считаю только то, что реально участвует в workflow: Markdown‑статьи в raw/habr/ и wiki‑слой, который получается после ingest.![][image6]

Что входит в ingest

В raw/habr/ лежат 4 исходные статьи:

Токены — оценка, не точный tokenizer Yandex. Для денег беру верхнюю границу: 23 903 input tokens и 27 494 output tokens.

По актуальным тарифам Yandex AI Studio:

• YandexGPT Lite: 0,20 ₽ / 1000 входящих токенов и 0,20 ₽ / 1000 исходящих токенов;

• embeddings / векторизация: 0,0101 ₽ / 1000 токенов.

Сколько стоит один ingest

• input: 23 903 токена * 0,20 ₽ / 1000 = 4,78 ₽

• output: 27 494 токена * 0,20 ₽ / 1000 = 5,50 ₽

• итого: 10,28 ₽

То есть ingest четырех статей на YandexGPT Lite стоил бы примерно 10 ₽. С запасом на системные промпты, повторы и правки я бы писал честнее: 15–25 ₽.

Embeddings для этого же объема почти не влияют на бюджет:

23 903 токена * 0,0101 ₽ / 1000 = 0,24 ₽

Если векторизовать уже весь получившийся wiki‑слой вместе с raw‑источниками:

(23 903 + 27 494) токенов * 0,0101 ₽ / 1000 = 0,52 ₽

Дополню по стоимости, если масштабировать не на 4 статьи, а условно на 100 документов.

Если грубо масштабировать линейно на 100 похожих документов, получится:

• input: ~598 тыс. токенов;

• output: ~687 тыс. токенов;

• всего: ~1,28 млн токенов.

На YandexGPT Lite по текущему тарифу 0,20 ₽ за 1000 input/output tokens это примерно:

• input: 598 000 * 0,20 / 1000 = ~120 ₽

• output: 687 000 * 0,20 / 1000 = ~137 ₽

• итого: ~257 ₽

С нормальным запасом на системные промпты, повторы, правки, review и неидеальный ingest я бы закладывал примерно 400–600 ₽ на 100 документов такого размера.

Embeddings при этом почти не влияют на бюджет:

• только raw‑документы: ~6 ₽;

• raw + получившийся wiki‑слой: ~13 ₽.

Но для бизнеса важнее не сама цена токенов, а риски:

1. Если документы длиннее моих статей в 3–5 раз, стоимость растет почти линейно.

2. Если плохо продумать схему wiki, потом придется переингестить корпус, и это будет повторная стоимость.

3. Markdown/HTML надо чистить перед отправкой: картинки, base64, навигация, рекламные блоки и мусор могут резко раздуть токены.

4. Нужен review качества: модель может плодить дубли понятий, спорные связи и уверенные, но неточные обобщения.

5. Для корпоративных данных отдельно надо смотреть безопасность, доступы, логирование, хранение запросов и требования ИБ.

То есть на 100 документов сам ingest на Lite выглядит довольно дешево, но зрелый бизнесовый workflow должен считать не только токены, а еще чистку данных, контроль качества, переиндексацию, права доступа и аудит.

Важная оговорка про Markdown

Когда я скрапил статью через Obsidian/Markdown, вместе с текстом подтянулись картинки. Одна из них попала прямо в Markdown как data:image/png;base64 и раздула файл почти на мегабайт.

Такой мусор нельзя отправлять в LLM как обычный текст:

• он не добавляет смысла;

• забивает контекст;

• может резко увеличить счет за токены;

• ухудшает качество ingest, потому что модель видит длинную бессмысленную строку.

Практическое правило: перед ingest нужно чистить Markdown — выносить картинки в отдельные файлы, удалять base64, HTML‑мусор, рекламные блоки, навигацию и все, что не является полезным текстом источника.

Где это лучше RAG

Я бы формулировал аккуратно: LLM Wiki не «лучше RAG» вообще, она лучше в другом классе задач. RAG хорош, когда есть много документов, приложение, пользователи, runtime retrieval, latency, права доступа и сервисная инфраструктура. LLM Wiki хороша, когда я сам изучаю тему, готовлю статью или доклад, хочу видеть связи между источниками и возвращаться к уже собранным понятиям.

Коротко:

RAG отвечает по документам. LLM Wiki строит память поверх документов.

RAG достал чанки, ответил и забыл. LLM Wiki прочитала источник, встроила его в карту знаний, обновила понятия, сохранила связи и в следующий раз работает уже с накопленным слоем.

Именно поэтому я не стал бы продавать LLM Wiki как замену enterprise RAG. Для production нужны права доступа, индексы, мониторинг, eval pipeline, SLA, observability, политики безопасности, rollback и data governance. LLM Wiki в текущем виде решает другую задачу: помогает человеку думать, копить материал и видеть структуру темы.

Если RAG — это backend‑компонент приложения, то LLM Wiki — усилитель личного мышления.

Что понравилось

Первое: хорошие ответы перестают исчезать. В обычном чате сильный синтез остается где‑то в истории диалога. Здесь его можно сохранить как страницу, и он становится частью базы.

Второе: понятия отделяются от источников. После четырех статей у меня появилась страница Продакшен LLM-системы, хотя ни одна статья не была только про это. Вместе они раскрыли тему через guardrails, evaluation, ingest документов, агентов, ИБ и контроль генерации.

Третье: lint оказался полезнее, чем я ожидал. Он сразу показал, каких понятий не хватает для следующего шага: RAG, Knowledge graph, Failure modes LLM-систем, Наблюдаемость LLM-систем, Human approval. То есть wiki сама начала подсказывать план дальнейшего чтения.

Четвертое: graph view хорошо показывает результат. Текстом можно долго объяснять, что база стала связанной, но когда четыре статьи сходятся на общих узлах, идея считывается быстрее.

Где риски

LLM может уверенно ошибаться, поэтому raw‑источники должны оставаться рядом. Wiki — не замена источникам, а слой над ними. Связи тоже могут быть слишком творческими: модель любит находить паттерны даже там, где их лучше не раздувать. Поэтому нужны ссылки на источники, уровень уверенности, ручной review, lint и явное разделение факта и интерпретации.

Еще один риск — мусорная структура. Если просить «сделай красиво», получится набор заметок без дисциплины. Нужны правила именования, обязательные секции, index, relations и log. Для меня неожиданным выводом стало то, что AGENTS.md важнее, чем кажется: именно он превращает LLM из генератора текста в maintainer wiki.

На масштабе тоже появятся проблемы. На 4–10 источниках хватает markdown и index. На 50–100 источниках, особенно если внутри длинные PDF и документы на десятки страниц, главной проблемой становится не только поиск, но и цена изменения схемы. Если в начале плохо придумать теги, типы страниц, правила именования или критерии «когда создавать новое понятие», потом придется переингестить корпус или долго чистить руками. Это уже может быть дорого: облачная модель будет жечь токены на повторном чтении и обновлении, локальная модель потребует хорошего железа и все равно может хуже держать длинный контекст, связи и дедупликацию.

Поэтому зрелый workflow должен начинаться не с «залить всю папку и пусть агент разберется», а с маленького пилота: 5–10 разных источников, review diff, проверка получившихся тегов и страниц, потом фиксация схемы. Только после этого имеет смысл масштабировать ingest. И уже там понадобятся поиск, проверка битых ссылок, дедупликация понятий, лимиты на стоимость операции, dry‑run перед записью, возможно embeddings или hybrid search. Но это нормальная эволюция инструмента, а не причина не начинать.

Как бы я развивал это дальше

Следующий шаг — добавить статьи про RAG и knowledge graphs, чтобы сравнение стало честнее. Потом я бы сделал маленький CLI:

• llm‑wiki ingest raw/habr/new‑article.md

• llm‑wiki query «чем LLM Wiki отличается от RAG?»

• llm‑wiki lint

Под капотом это может быть обычный набор промптов и файловых операций. Более зрелая версия добавил бы локальный индекс, review diff перед записью, проверку битых ссылок, список orphan pages, оценку стоимости ingest до запуска и evaluation для качества summaries.

Главное, что я понял

До эксперимента я воспринимал LLM Wiki как красивую идею. После эксперимента — как рабочий паттерн. Не как замену RAG, не как «новую базу данных» и не как универсальную production‑архитектуру, а как способ сделать так, чтобы чтение и вопросы к LLM накапливались в устойчивую структуру.

Для меня это особенно ценно в исследовательской работе. Когда читаешь много материалов, готовишь статью или доклад, хочется видеть не только отдельные summaries, но и общую карту. LLM Wiki хорошо ложится на эту задачу: превращает «я поговорил с моделью» в «я пополнил базу знаний».

Если совсем коротко:

LLM Wiki — это когда LLM не просто отвечает на вопросы, а помогает поддерживать живую базу знаний, которая становится полезнее с каждым новым источником.

RAG помогает найти ответ. LLM Wiki помогает накопить понимание.

Если вы уже пробовали собирать личные базы знаний с LLM, Obsidian, RAG, агентами или локальными моделями, будет интересно сравнить опыт. Делитесь в комментариях своими workflow, лайфхаками, ошибками в схемах и приемами, которые реально помогли не утонуть в документах.