У спільноті штучного інтелекту ім’я Андрея Карпаті давно стало синонімом передових ідей: співзасновник OpenAI, колишній директор з AI у Tesla, один із найвпливовіших інженерів у галузі. Нещодавно він запропонував концепцію, яка радикально переосмислює те, як люди працюють з документами за допомогою великих мовних моделей. Цю систему він назвав LLM Wiki. Канал Teacher’s Tech на YouTube демонструє практичну реалізацію цієї ідеї на базі Obsidian та Claude Code, але за технічними деталями ховається значно глибша зміна парадигми.
Йдеться не просто про ще один «обгортковий» інтерфейс до ChatGPT чи іншої моделі, а про спробу вирішити фундаментальний недолік більшості сучасних AI-робочих процесів: вони щоразу починають з нуля, не накопичуючи жодного довгострокового розуміння ваших документів. LLM Wiki пропонує замінити цей одноразовий підхід на постійну, еволюційну базу знань, яку модель будує і вдосконалює з часом.
Як працює більшість AI-сервісів з документами — і в чому їхня прихована вада
Сценарій знайомий усім, хто користувався ChatGPT, NotebookLM чи подібними інструментами. Ви завантажуєте кілька файлів — презентації, статті, PDF-звіти — і ставите запитання. Модель проглядає документи, знаходить фрагменти, які здаються релевантними, і формує відповідь. На перший погляд усе виглядає цілком розумно.
Проблема стає очевидною, якщо подивитися на цей процес у динаміці. Наступного дня ви ставите схоже запитання про ті самі файли. Система знову:
переглядає документи,
шукає релевантні шматки,
«зшиває» їх у відповідь.
Усе — з нуля. Жодна проміжна структура не зберігається, жодні висновки не накопичуються, жодне «розуміння» не переходить із сесії в сесію. Кожен запит — це чистий аркуш.
Технічно більшість таких рішень побудовані на Retrieval-Augmented Generation (RAG). Механіка проста: документи індексуються, при запиті система робить пошук по векторному індексу, дістає кілька найближчих фрагментів і передає їх у контекст моделі, яка генерує відповідь. Звучить ефективно, але є кілька суттєвих обмежень.
По-перше, RAG не має справжньої пам’яті. Індекс — це лише спосіб швидко знайти фрагменти тексту, а не розвинута модель знань. Після завершення відповіді все, що модель «зрозуміла» під час міркування, зникає. Немає жодної довгострокової структури, яка б жила між сесіями.
По-друге, кожне складне запитання змушує систему знову виконувати всю важку роботу: шукати по всіх джерелах, намагатися поєднати ідеї з різних документів, узгоджувати суперечності. Якщо потрібно пов’язати інформацію з п’яти чи десяти файлів, модель щоразу повторює один і той самий інтелектуальний марафон.
По-третє, це фундаментально заважає «нарощуванню» розуміння. Якщо ви тижнями досліджуєте тему, додаєте нові документи, ставите уточнювальні запитання, система не стає розумнішою щодо вашого корпусу даних. Вона не будує внутрішньої моделі предметної області, а лише раз за разом робить локальний пошук і локальний синтез.
У результаті користувач отримує ілюзію персоналізованого AI-помічника, але насправді взаємодіє з інструментом, який щоразу поводиться так, ніби «ніколи не бачив» жодного з ваших документів раніше.
Чому «починати з нуля» — це марнотратство для користувача і для моделі
Якщо перенести цю логіку в людський контекст, абсурдність стає очевидною. Уявімо дослідника, який тижнями читає наукові статті. Кожного разу, коли він ставить собі нове запитання, він повністю забуває все, що читав раніше, і знову перечитує всі джерела з першої сторінки. Саме так поводиться типовий RAG-пайплайн.
Це марнотратство проявляється одразу на кількох рівнях.
По-перше, витрачаються обчислювальні ресурси. Модель знову й знову проганяє одні й ті самі документи через механізм пошуку, аналізу й генерації. Для користувача це означає зайві затримки, для провайдерів — зайві витрати на інференс.
По-друге, втрачається можливість глибокої, кумулятивної аналітики. Складні питання часто вимагають не просто знайти відповідний абзац, а побачити патерни, суперечності, еволюцію ідей між джерелами. Якщо кожне міркування одноразове, система не може поступово будувати все більш точну й узгоджену картину предметної області.
По-третє, користувач позбавлений відчуття прогресу. Додавання нового документа не «прокачує» систему, а лише розширює поле для чергового одноразового пошуку. Немає відчуття, що ваш AI-помічник стає досвідченішим у конкретному проєкті чи темі.
Нарешті, це обмежує можливості для довгострокових робочих процесів. Якщо ви працюєте над курсом, дослідженням, бізнес-проєктом чи навіть плануванням подорожі, вам потрібен інструмент, який пам’ятає, що вже було опрацьовано, які висновки зроблено, які поняття введено. RAG у стандартному виконанні цього не дає.
Саме на цю фундаментальну ваду й націлена ідея LLM Wiki.
LLM Wiki: замість одноразових відповідей — постійна, еволюційна база знань
Карпаті пропонує просту, але радикальну зміну: замість того, щоб щоразу шукати по «сирих» документах, змусити модель прочитати їх один раз і перетворити на структуровану вікі — стійку базу знань, яка живе між сесіями і зростає з кожним новим джерелом.
У цій концепції LLM Wiki — це не метафора, а досить буквальний опис. Знання зберігаються у вигляді взаємопов’язаних markdown-сторінок, які фізично лежать у папці на вашому комп’ютері. Це не тимчасовий кеш, а постійний артефакт роботи моделі.
Коли ви додаєте новий документ — наприклад, PDF, статтю чи нотатки зустрічі, — система не просто індексує його для майбутнього пошуку. Вона:
читає текст,
виділяє ключові ідеї та сутності,
створює нові сторінки для нових понять,
оновлює вже існуючі сторінки, якщо з’явилися додаткові деталі,
проставляє посилання між пов’язаними концептами.
Якщо нове джерело суперечить уже наявній інформації, це також фіксується: суперечності не замовчуються, а позначаються як такі, що потребують уваги. Таким чином, база знань не просто розширюється, а й уточнюється.
Ключовий момент: усе це зберігається. Після завершення сесії структура вікі нікуди не зникає. Наступного разу, коли ви ставите запитання, модель працює не з «плоским» набором сирих файлів, а з уже організованою, попередньо синтезованою базою знань. Іншими словами, значна частина інтелектуальної роботи виконана наперед.
Це змінює саму природу взаємодії. Додавання нового джерела стає не просто завантаженням файлу, а внеском у спільну з моделлю «кодову базу» знань. Кожен наступний запит спирається на все, що було зроблено раніше, а не ігнорує минулий контекст.
Від RAG до «кодової бази знань»: нова роль користувача і моделі
Карпаті описує цю систему через знайому для розробників аналогію: Obsidian — це IDE, LLM — програміст, а вікі — кодова база. Суть у тому, що користувач рідко пише сторінки вікі вручну. Основну роботу з написання й організації бере на себе модель. Людина зосереджується на двох речах: які джерела «заливаються» в систему і які запитання до неї ставляться.
Це принципово відрізняється від класичного RAG-сценарію, де користувач щоразу «підкидає» документи й формулює запит, а модель у відповідь виконує одноразову операцію пошуку та генерації. У LLM Wiki користувач фактично керує еволюцією бази знань.
Тут важливо, що система побудована як трирівнева:
перший рівень — «сирі» джерела,
другий — власне вікі як набір markdown-сторінок,
третій — схема (schema), яка описує правила побудови й оновлення вікі.
Сирі документи залишаються недоторканими. Це «джерело істини», яке модель може читати, але не змінювати. Вікі — це похідний шар, який AI вільно створює й редагує, додаючи індексні сторінки, сторінки понять, сутностей, порівняльні огляди. Схема — це текстовий документ, що задає правила гри: як структурувати сторінки, як поводитися з новими джерелами, як відповідати на запитання, на які папки спиратися.
У практичній реалізації, яку демонструє Teacher’s Tech, ця схема зберігається у файлі claude.md в корені «сховища» Obsidian. Claude Code автоматично читає цей файл при відкритті проєкту і далі діє згідно з прописаними інструкціями. Користувачеві достатньо змінити одну ключову фразу — «purpose», тобто призначення вікі. У демонстрації це планування подорожі до Японії, але так само це може бути дослідження відновлюваної енергетики чи база знань за прочитаними книжками.
Усе інше — структура папок, правила індексації, формат сторінок, поведінка при відповіді на запитання — уже визначено в шаблоні. Важливий момент: схема не є статичною. Вона може еволюціонувати разом із вікі, уточнюватися, доповнюватися, коли стає зрозуміло, які саме структури найкраще відображають предметну область.
Таким чином, роль користувача зміщується з «постійно переформульовувати запит» до «керувати розвитком бази знань». Це набагато ближче до того, як працюють команди розробників із кодом, ніж до звичного «запит–відповідь» у чаті.
Markdown як пам’ять: чому персистентна вікі змінює якість відповідей
Один із найцікавіших аспектів LLM Wiki — вибір формату зберігання знань. Замість спеціалізованих баз даних чи закритих форматів використовується звичайний markdown. Це означає, що вся база знань — це набір текстових файлів, які можна відкрити будь-яким редактором, перенести, заархівувати, підключити до інших інструментів.
У демонстрації Obsidian виступає як зручний «глядач» цієї вікі. Це безкоштовний застосунок для нотаток, який працює з plain-text markdown-файлами і пропонує, зокрема, граф-подання зв’язків між сторінками. Саме в цьому графі наочно видно, як із одного-двох документів поступово виростає мережа понять, локацій, тем, пов’язаних посиланнями.
Такий підхід дає кілька важливих переваг порівняно з класичним RAG.
По-перше, знання стають персистентними. Якщо модель одного разу витягла з тексту ключові ідеї, структурувала їх, створила сторінки й посилання, цей результат зберігається. Наступні відповіді можуть спиратися на вже зроблену роботу, а не повторювати її.
По-друге, з’являється можливість справжньої крос-документної аналітики. Коли вікі оновлюється при додаванні кожного нового джерела, сторінки, що описують однакові сутності (наприклад, райони Токіо чи типи японської кухні), збагачуються новими деталями. Модель не просто «знаходить ще один абзац», а інтегрує його в уже наявну картину.
По-третє, користувач отримує прозорість. На відміну від «чорної скриньки» RAG, де незрозуміло, як саме система поєднала фрагменти, тут можна відкрити будь-яку сторінку вікі, побачити, які джерела її сформували, як вони між собою пов’язані, які твердження на чому ґрунтуються. Це особливо важливо для навчання, досліджень і бізнес-рішень, де відстежуваність аргументації має значення.
По-четверте, вікі стає спільним артефактом. Її можна редагувати вручну, доповнювати, коментувати, підключати до інших інструментів. Це вже не просто «сеанс спілкування з моделлю», а живий документ, який може жити й поза межами конкретного AI-сервісу.
Усе це разом означає, що LLM Wiki не просто економить обчислювальні ресурси. Вона змінює якість відповідей: замість одноразового синтезу з розрізнених фрагментів користувач отримує відповіді, що спираються на поступово вибудувану, узгоджену модель знань.
LLM Wiki як альтернатива RAG для довгострокових проєктів і персональних знань
Карпаті прямо позиціонує LLM Wiki як розумнішу альтернативу типовим RAG-процесам, особливо коли йдеться про персональні або проєктні знання, що розвиваються з часом. Якщо ваша взаємодія з AI не обмежується одноразовими запитами, а нагадує тривалу роботу над темою, переваги стають очевидними.
Уявімо студента, який готується до іспиту, викладача, що збирає матеріали для курсу, або бізнес, який формує внутрішню базу знань. У традиційному RAG-сценарії кожен новий документ лише збільшує обсяг даних для пошуку. У LLM Wiki кожен документ стає «цеглинкою» у структурі, що постійно вдосконалюється.
Коли в демонстрації Teacher’s Tech до вікі додається перший документ — тревел-блог про Токіо, — система створює сторінки для районів міста, видів активностей, загальних рекомендацій. Коли додається друге джерело — гід по їжі в Японії, — модель не просто створює нові сторінки, а й оновлює вже існуючі: сторінки районів доповнюються інформацією про ресторани, локальні страви, гастрономічні особливості.
Це і є «вікі, що робить свою роботу»: вона не дублює інформацію, а інтегрує її. З кожним новим джерелом мережа понять стає щільнішою, а відповіді на запитання — глибшими. Коли користувач запитує про, скажімо, найкращі райони для поєднання прогулянок і гастрономії, модель уже має попередньо зібрану й пов’язану інформацію, а не мусить щоразу шукати її по всіх сирих файлах.
Для довгострокових проєктів це означає, що AI-помічник справді «росте» разом із вами. Він не просто реагує на запити, а будує й підтримує спільну з вами базу знань, яка з часом стає все ціннішою.
Висновок: від одноразових чатів до спільної пам’яті з AI
Концепція LLM Wiki Карпаті ставить під сумнів саму основу того, як сьогодні влаштована більшість AI-сервісів для роботи з документами. Замість нескінченного циклу «завантажити — запитати — забути» пропонується модель співпраці, де AI не просто відповідає, а будує й підтримує персистентну, структуровану базу знань.
У традиційному RAG-підході кожне запитання стартує з нуля, проміжні структури не зберігаються, а потенціал кумулятивного розуміння втрачається. LLM Wiki натомість змушує модель один раз «прочитати» документи й перетворити їх на вікі з markdown-сторінок, які живуть між сесіями, оновлюються, збагачуються й пов’язуються між собою.
Це не просто технічний тюнінг, а зміна парадигми: від чат-бота, що забуває все після кожної відповіді, до спільної з AI пам’яті, яка розвивається разом із користувачем. Для всіх, хто працює з великими масивами інформації — від студентів до дослідників і бізнес-команд, — така еволюція може виявитися не менш важливою, ніж поява самих великих мовних моделей.
Джерело
Karpathy’s LLM Wiki – Full Beginner Setup Guide — Teacher’s Tech