Понял, спасибо! Я подумаю, как продемонстрировать работу системы на реальных примерах. Может быть, удастся описать использование при реализации следующего пет-проекта.
Что касается
оценить целесообразность подхода из расчета пользы на трудозатраты
Трудозатраты тут минимальны: открыть кодового агента и воспользоваться логикой, аналогичной той, что реализована в репозитории из статьи. Как раз удобство подхода, что не нужно поднимать отдельно компоненты, как в RAG с векторным поиском.
Все, что нужно - это кодовый агент, правила для него и ваши данные. Затем воспользоваться результатом при работе с проектом, релевантным созданной LLM-Wiki.
На сколько система лучше работает рага и на каких доменах?
Для сравнения векторного поиска и LLM-Wiki (+ еще гибридный подход) по-хорошему нужно собирать метрики качества ответов, иначе это будет субъективной оценкой. Работа трудоемкая.
И не понятно качество системы на разных моделях. Если использовать облачные модели, то стоит вопрос в безопасности.
Я для своих баз знаний использую топовые модели типа GPT-5.5/Opus-4.7, т.к. создание и поддержка базы знаний съедает относительно небольшое количество токенов и конфиденциальных данных у меня нет. Итоговое качество баз знаний меня устраивает.
Как это будет работать на локальных моделях я не знаю, нужно тестировать.
Я бы сказал стоит вопрос даже не столько в качестве, сколько в разрешении. Если собрать большой индекс, указать пути до файлов с краткими описаниями, то близкие по смыслу описания модель уже будет с трудом различать.
В статье действительно явно не рассматривается вопрос применимости на большом объеме данных и проблема поиска информации в большом индексе есть.
Косвенно про это говорится в двух местах:
1. В блоке сравнения LLM-Wiki и классического RAG
LLM‑Wiki — структурированные markdown‑страницы + [[wikilinks]] + индекс + LLM‑навигация (при росте базы поверх можно добавить тот же гибридный поиск, например через qmd).
2. В части "Сравнение по основным параметрам" отдельной строкой указан масштаб. Там говорится, что LLM-Wiki применяется для "~100 источников и сотни страниц, индекс умещается в контекст", т.е. для относительно небольших индексов. Для тысяч-миллионов документов нужно использовать RAG или гибридный подход LLM-Wiki с qmd, как указано выше.
Спасибо за комментарий! Вопросы и опасения по делу.
В большинстве случаев сценарии применения аналогичны классическому RAG. Разница в том, насколько качественно организованы данные и выполняется поиск информации.
Один из примеров использования: при решении задачи в Cursor указывается путь до нужного vault'а и выполняется планирование решения или исследование определенной темы.
Примером vault'а может быть LLM-wiki по документации pet-проекта и релевантной ему информации (наборы статей, идей и заметок по итогам личного исследования). Ровно так был реализован репозиторий с примером vault'а из статьи.
Без доступа к документации агент решит задачу, но не будет учитывать, например, особенности системы, ее ограничения и ваше видение. С доступом к базе знаний решение будет персонализированным конкретно для этой системы.
P.S. если документация состоит из нескольких .md документов, то ее достаточно сложить в репозиторий проекта, например в папку /docs, и все. LLM-Wiki в таком случае будет излишним.
Согласен. Подобные подходы уже популярны и не только в кодовых агентах.
Если заглянуть в комментарии оригинальной публикации идеи от Karpathy, то можно найти что-то типа "Последнее время я пытался реализовать что-то подобное". Иногда исследователям не хватает именно формализации и популяризации их идей.
Под верификацией тут понимается именно проверка написанного агентом кода. Так агент может убедиться, что написанный код отрабатывает верно и в случае необходимости исправить ошибки.
Смысл верификации один, но реализована она может быть с помощью разных инструментов. Набор из оригинального поста "Конфуция":
Запуск bash команды
Прогон тестов
Тестирования приложения в браузере или мобильном симуляторе
Таким образом, верификация имеется в виду как концепт, инструменты - как способ реализации верификации.
Системный промпт на серверах производителя тоже может внедряться непосредственно перед попаданием полного промпта в модель. Это нужно, например, для соблюдения политик компании и ввода ограничений на поведение модели. Он как раз может быть одним для всех агентов, которые ее используют.
Однако за разное поведение одной и той же модели в разных агентах в частности отвечают системные промпты агента для этой модели.
Спасибо, буду знать! Хабы обновил
Понял, спасибо! Я подумаю, как продемонстрировать работу системы на реальных примерах. Может быть, удастся описать использование при реализации следующего пет-проекта.
Что касается
Трудозатраты тут минимальны: открыть кодового агента и воспользоваться логикой, аналогичной той, что реализована в репозитории из статьи. Как раз удобство подхода, что не нужно поднимать отдельно компоненты, как в RAG с векторным поиском.
Все, что нужно - это кодовый агент, правила для него и ваши данные. Затем воспользоваться результатом при работе с проектом, релевантным созданной LLM-Wiki.
Для сравнения векторного поиска и LLM-Wiki (+ еще гибридный подход) по-хорошему нужно собирать метрики качества ответов, иначе это будет субъективной оценкой. Работа трудоемкая.
Я для своих баз знаний использую топовые модели типа GPT-5.5/Opus-4.7, т.к. создание и поддержка базы знаний съедает относительно небольшое количество токенов и конфиденциальных данных у меня нет. Итоговое качество баз знаний меня устраивает.
Как это будет работать на локальных моделях я не знаю, нужно тестировать.
В статье действительно явно не рассматривается вопрос применимости на большом объеме данных и проблема поиска информации в большом индексе есть.
Косвенно про это говорится в двух местах:
1. В блоке сравнения LLM-Wiki и классического RAG
LLM‑Wiki — структурированные markdown‑страницы +
[[wikilinks]]+ индекс + LLM‑навигация (при росте базы поверх можно добавить тот же гибридный поиск, например через qmd).2. В части "Сравнение по основным параметрам" отдельной строкой указан масштаб. Там говорится, что LLM-Wiki применяется для "~100 источников и сотни страниц, индекс умещается в контекст", т.е. для относительно небольших индексов. Для тысяч-миллионов документов нужно использовать RAG или гибридный подход LLM-Wiki с qmd, как указано выше.
Спасибо за комментарий! Вопросы и опасения по делу.
Все мы немного недоверчивые субъекты))
Спасибо, что поделились. Интересный сценарий!
В большинстве случаев сценарии применения аналогичны классическому RAG. Разница в том, насколько качественно организованы данные и выполняется поиск информации.
Один из примеров использования: при решении задачи в Cursor указывается путь до нужного vault'а и выполняется планирование решения или исследование определенной темы.
Примером vault'а может быть LLM-wiki по документации pet-проекта и релевантной ему информации (наборы статей, идей и заметок по итогам личного исследования). Ровно так был реализован репозиторий с примером vault'а из статьи.
Без доступа к документации агент решит задачу, но не будет учитывать, например, особенности системы, ее ограничения и ваше видение. С доступом к базе знаний решение будет персонализированным конкретно для этой системы.
P.S. если документация состоит из нескольких .md документов, то ее достаточно сложить в репозиторий проекта, например в папку /docs, и все. LLM-Wiki в таком случае будет излишним.
Согласен. Подобные подходы уже популярны и не только в кодовых агентах.
Если заглянуть в комментарии оригинальной публикации идеи от Karpathy, то можно найти что-то типа "Последнее время я пытался реализовать что-то подобное". Иногда исследователям не хватает именно формализации и популяризации их идей.
Спасибо! Обновил в статье
Под верификацией тут понимается именно проверка написанного агентом кода. Так агент может убедиться, что написанный код отрабатывает верно и в случае необходимости исправить ошибки.
Смысл верификации один, но реализована она может быть с помощью разных инструментов. Набор из оригинального поста "Конфуция":
Запуск bash команды
Прогон тестов
Тестирования приложения в браузере или мобильном симуляторе
Таким образом, верификация имеется в виду как концепт, инструменты - как способ реализации верификации.
Системный промпт на серверах производителя тоже может внедряться непосредственно перед попаданием полного промпта в модель. Это нужно, например, для соблюдения политик компании и ввода ограничений на поведение модели. Он как раз может быть одним для всех агентов, которые ее используют.
Однако за разное поведение одной и той же модели в разных агентах в частности отвечают системные промпты агента для этой модели.
Именно так. Еще агент может вызывать субагентов (subagents) со своими системными промптами.
Ради интереса можно посмотреть системные промпты различных AI-инструментов вот тут по ссылке: https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools/tree/main