00:00:00Давайте решим проблему Claude Code и памяти, чтобы заставить ИИ-системы надежно и точно
00:00:06отвечать на вопросы о прошлых разговорах или огромных массивах документов — это задача, которую мы
00:00:13пытаемся решить годами, и типичным ответом был RAG (генерация с дополнением выборкой), и
00:00:20хотя это видео называется «Семь уровней Claude Code и RAG», на самом деле оно
00:00:26о деконструкции проблемы Claude Code и вообще ИИ-систем и памяти, и,
00:00:33что еще более важно, это видео о том, чтобы дать вам дорожную карту, которая покажет ваше место
00:00:37в этой борьбе между ИИ-системами и памятью, и что вы можете сделать, чтобы перейти на следующий уровень. Итак, путешествуя
00:00:43по этим семи уровням Claude Code и RAG, мы затронем ряд тем, но
00:00:48мы не начнем с GraphRAG или чего-то сложного, мы начнем с самого начала,
00:00:53а именно с базовых систем памяти, встроенных в Claude Code, потому что, как ни прискорбно,
00:00:59именно здесь большинство людей не только начинают, но и остаются — от авто-памяти и вещей вроде
00:01:04claud.md мы перейдем к внешним инструментам, таким как Obsidian, прежде чем в конечном итоге окажемся
00:01:10с «большими ребятами», с настоящими системами RAG. На этих уровнях мы поговорим о том, что такое RAG на самом деле,
00:01:16как он работает, о разных типах RAG: наивный RAG против GraphRAG и агентного RAG, о таких вещах,
00:01:21как реранкеры и все, что между ними. И на каждом уровне мы будем разбирать всё по одной схеме:
00:01:25мы обсудим, чего ожидать на этом уровне, навыки, которые нужно освоить,
00:01:29ловушки, которых следует избегать, и что нужно сделать, чтобы перейти на следующий уровень. Чего в этом видео
00:01:34не будет, так это сверхглубокого технического объяснения того, как именно настраивать эти
00:01:40конкретные системы, потому что во многих случаях я это уже делал, когда мы говорили о GraphRAG и
00:01:45LightRAG, например, или даже о более продвинутых темах, таких как RAG-everything в этих различных
00:01:50системах эмбеддингов; я делал видео, где разбираю от самого начала до самого конца, как
00:01:55настроить это самостоятельно. Поэтому, когда мы дойдем до тех разделов, я дам ссылки на те видео, и это
00:02:00в наших общих интересах, чтобы это видео не длилось пять часов, но на этих уровнях мы все равно поговорим
00:02:04о том, что это на самом деле означает, что дает каждая система и когда ее следует использовать. Но
00:02:09прежде чем мы начнем с первого уровня, короткое слово от сегодняшнего спонсора — меня самого. Буквально в прошлом месяце я выпустил
00:02:15мастер-класс по Claude Code, и это лучший способ пройти путь от нуля до ИИ-разработчика, особенно если у вас нет
00:02:21технического бэкграунда. Этот мастер-класс немного отличается, потому что мы фокусируемся на
00:02:25множестве различных сценариев использования, чтобы научиться применять Claude Code. Один из них — это что-то вроде
00:02:31RAG уровня продакшена: как создавать системы RAG, которые вы увидите в этом видео, в реальных сценариях и
00:02:37действительно использовать их как член команды или продать клиенту — вот на таких вещах мы фокусируемся. Так что,
00:02:42если вы хотите получить доступ, вы можете найти его в Chase AI Plus, ссылка на него есть в закрепленном
00:02:47комментарии, и мы будем рады видеть вас там. А теперь давайте начнем с уровня 1 — и это авто-память.
00:02:51Это системы, которые Claude Code автоматически использует для создания некоего аппарата памяти,
00:02:58чтобы действительно помнить вещи, о которых вы говорили. И вы понимаете, что находитесь здесь, если вы никогда
00:03:02ничего специально не настраивали, чтобы помочь Claude Code запоминать контекст в целом о предыдущих разговорах
00:03:09или просто о том, что происходит в вашей кодовой базе. И когда мы говорим об авто-памяти, это
00:03:13буквально так и называется — система авто-памяти, которая автоматически включается при использовании
00:03:18Claude Code. По сути, она позволяет Claude Code самостоятельно создавать файлы Markdown, в которых
00:03:26перечисляются вещи, которые он считает важными о вас в этом конкретном проекте. И это основано чисто
00:03:32на его собственной интуиции, исходя из ваших разговоров. И я могу видеть эти файлы памяти, которые он создал; опять же,
00:03:37он делает это сам. Если вы зайдете в папку .claud, затем в projects, вы увидите там
00:03:42папку под названием memory, и внутри этого файла вы увидите ряд файлов Markdown. Здесь
00:03:47их четыре, и они похожи на версию стикеров Claude Code, говорящих: «О да, он как-то упомянул
00:03:51вот это про цели роста своего YouTube-проекта, давайте это запишем». И внутри папки памяти
00:03:59каждого будет файл memory.md. Вы видите, что в этом файле памяти есть небольшая заметка об
00:04:04одном из моих навыков, а затем, по сути, индекс всех этих вложенных файлов памяти, гласящий:
00:04:09«Эй, тут есть файл про рост YouTube, про доход или рекомендации, и вот что внутри него». Таким образом,
00:04:13если я просто разговариваю с Claude Code в своем файле хранилища и упоминаю что-то о YouTube и своих
00:04:19целях роста или чем-то еще, он обратится к этому и скажет: «О да, Чейз пытается
00:04:23получить столько-то подписчиков к концу 2026 года». Это мило, но в конечном счете не так уж полезно.
00:04:30Это похоже на то, как внутри ChatGPT он иногда выдает случайные вещи из
00:04:35предыдущих разговоров и как бы впихивает их. И ты такой: «Окей, я понял, ты это запомнил,
00:04:40но мне это не особо важно, и, честно говоря, немного странно постоянно это упоминать. Я бы предпочел, чтобы ты этого не делал».
00:04:44И, к сожалению, именно на этом этапе большинство людей останавливаются в своем путешествии по изучению памяти, и это основано на
00:04:49некоем почти травмирующем прошлом, которое есть у всех нас, когда дело касается использования этих чат-ботов.
00:04:54Потому что у этих чат-ботов нет никакой реальной памяти от разговора к разговору, и поэтому
00:05:00мы всегда до смерти боимся закрыть окно чата или выйти из сеанса терминала,
00:05:06потому что думаешь: «О боже, он же не запомнит мой разговор». И это действительно
00:05:10серьезная проблема, потому что каков у всех ответ на то, что окно чата ничего
00:05:17не может запомнить? Что ж, ответ в том, что вы просто ведете этот разговор вечно, потому что не хотите
00:05:22оказаться в ситуации, когда вам придется выйти, и он все забудет. Этот страх рождается здесь, внутри
00:05:26этих окон чата, начиная с ChatGPT, и то же самое с веб-приложением Claude. И, честно говоря,
00:05:31раньше с веб-приложением Claude было бесконечно хуже, потому что, я думаю, мы все помним времена до
00:05:35контекстного окна в 1 миллион, когда у вас было типа 30 минут на разговор с Claude, а потом: «Ну что ж,
00:05:39увидимся через четыре часа». Проблема в том, что люди перенесли это своего рода психотическое, невротическое поведение
00:05:45в терминал, и то, что они делают по большей части — потому что теперь это сходит с рук благодаря окну в 1 миллион
00:05:50контекста, — они никогда не очищают историю, они просто продолжают и продолжают говорить с Claude Code,
00:05:55потому что никогда не хотят, чтобы он забыл, о чем они говорят, из-за этих проблем с памятью. И
00:06:00проблема в том, что ваша эффективность со временем сильно падает, чем дольше вы говорите с Claude Code внутри
00:06:05одной и той же сессии. И это фундаментальная идея «разложения контекста» (context rot). Если вы не знаете, что такое
00:06:10разложение контекста, то это феномен, когда чем больше я использую ИИ-систему в рамках одной сессии, в рамках одного
00:06:16чата, и чем больше я заполняю это контекстное окно, тем хуже она работает. Вы можете видеть это прямо здесь: Claude Code, окно в 1 миллион
00:06:23контекста. На 256 тысячах токенов, то есть я заполнил лишь около четверти его контекстного окна, точность
00:06:30составляет 92%. К концу она падает до 78%. Так что чем больше вы используете его в одном чате, тем хуже он становится, и это одна
00:06:36из основных проблем, которые возникают у людей с ИИ-системами и памятью. У меня есть Claude Code, у него контекст в миллион,
00:06:42и все же я не хочу, чтобы он забыл разговор, который мы ведем, поэтому я просто никогда не закрываю
00:06:47окно, я просто заполняю его и заполняю. И происходят две вещи: во-первых, падает эффективность,
00:06:51как вы только что видели; во-вторых, ваше потребление ресурсов зашкаливает, потому что количество токенов, используемых при
00:06:59миллионном окне — эти 800 000 контекста — стоят гораздо дороже, чем 80 000 контекста. Так что это не единственная проблема,
00:07:08но, немного отклоняясь от темы: мы сейчас находимся в экосистеме, где все жалуются на то, что Claude Code
00:07:12«понерфили» и что лимиты использования исчерпываются автоматически. Для этого есть ряд причин, но одна
00:07:18из них, несомненно, заключается в том, что с момента появления окна в 1 миллион люди понятия не имеют, как
00:07:24управлять своим собственным окном контекста, и они далеко не так,
00:07:29далеко не так решительны в очистке и сбросе разговора, как следовало бы. Но это вроде как оффтоп.
00:07:34Суть всей этой дискуссии в том, что когда дело доходит до памяти в этом разговоре о RAG и
00:07:39Claude Code, мы должны помнить о разложении контекста, потому что мы постоянно пытаемся справиться с этим напряжением: «Окей,
00:07:44я хочу скормить контекст, чтобы Claude Code мог отвечать на вопросы о ряде вещей,
00:07:50но в то же время я не хочу, чтобы контекст становился слишком большим, потому что тогда будет только хуже».
00:07:55Так что об этом всегда нужно помнить в разговоре о памяти.
00:08:02Но чтобы вернуть нас к самому видео и первому уровню: что люди делают на первом уровне? Ответ:
00:08:06они на самом деле ничего не делают. И поскольку они ничего не делают, они просто полагаются
00:08:10на раздутое окно контекста, чтобы оно все помнило. Вы понимаете, что вы здесь, если вы никогда не редактировали
00:08:15файл claud.md и никогда не создавали никаких артефактов или файлов, которые позволили бы Claude Code
00:08:23понять, что, черт возьми, происходит, что он на самом деле делал в прошлом и что ему нужно
00:08:27делать в будущем. Так что же нам нужно освоить на этом уровне? Ну, на самом деле все, что вам нужно
00:08:31освоить, несмотря на все, что я здесь написал, — это просто понять, что авто-памяти недостаточно,
00:08:35и нам нужно взять на себя активную роль, когда дело касается Claude Code и памяти. Потому что ловушка на этом уровне
00:08:40в том, что если вы не берете на себя активную роль, у вас нет контроля, а нам нужно контролировать то, что Claude Code
00:08:44принимает во внимание, когда отвечает на наши вопросы. И поэтому, чтобы разблокировать уровень один и перейти на уровень два,
00:08:50нам нужна явная память, и нам нужно выяснить, как на самом деле это сделать. Какие файлы
00:08:57вам нужно редактировать и понимать, что они вообще существуют, чтобы занять активную позицию в этих
00:09:01отношениях? Итак, уровень два посвящен одному конкретному файлу — файлу claud.md. Когда вы узнаете
00:09:06об этой штуке, это кажется божьим даром: наконец-то появилось единое место, где я могу прописать Claude Code
00:09:12правила и конвенции, которым я всегда хотел, чтобы он следовал, и он будет это делать; и,
00:09:16более того, я могу включить туда вещи, которые хотел, чтобы он помнил, и он всегда будет это делать. Поначалу это определенно кажется
00:09:20прогрессом. Вот шаблон стандартного файла claud.md для проекта личного ассистента. Теперь,
00:09:29Claude Code автоматически создаст файл claud.md, но у вас есть возможность
00:09:33редактировать его или даже обновлять по запросу, используя команду типа /init. И
00:09:38идея этой штуки в том, что она, опять же, является чем-то вроде святого грааля инструкций для Claude Code для этого конкретного
00:09:43проекта. По сути, Claude Code будет заглядывать в него перед выполнением любой задачи.
00:09:50Так что, если вы хотите, чтобы он запомнил конкретные вещи, что вы сделаете? Вы
00:09:54поместите их в claud.md. Теоретически, это своего рода уменьшенная версия RAG: мы же не
00:10:00запихиваем сюда целые документы, но это вещи, которые вы хотите, чтобы Claude Code
00:10:05всегда помнил, и конвенции, которым вы хотите, чтобы он следовал. Для этого примера у нас есть раздел «Обо мне»,
00:10:09у нас есть разбивка структуры файловой системы и того, как мы хотим, чтобы он работал,
00:10:14когда мы даем ему команды. И, как я уже сказал, поскольку на это есть ссылки практически в каждом промпте, Claude Code
00:10:18очень хорошо следует этому. Так что идея типа «эй, я хотел, чтобы он запомнил определенные вещи» —
00:10:22кажется отличным местом для этого. Но нам нужно быть осторожными, потому что мы можем переборщить. Когда мы смотрим на
00:10:28подобные исследования, оценивающие agents.md (вы можете заменить agents.md на claud.md),
00:10:33в этом исследовании обнаружили, что такие файлы могут на самом деле снижать эффективность больших
00:10:40языковых моделей в целом. И почему это так? Ну, потому что то, что делает их такими хорошими — тот факт,
00:10:45что они внедряются практически в каждый промпте, — это же может сделать их такими плохими. Действительно ли мы
00:10:51внедряем правильный контекст? Пробились ли мы сквозь шум и даем ли мы на самом деле четкий
00:10:57сигнал, или мы просто накидали туда вещей, которые нам кажутся полезными? Потому что если это не относится
00:11:02буквально к каждому промпту, который вы собираетесь дать в своем проекте, должно ли оно быть здесь, в claud.md?
00:11:08Является ли это хорошим способом позволить Claude Code запоминать вещи? Я бы сказал, что нет, не совсем. И это идет
00:11:15вразрез с тем, что многие говорят о claud.md и о том, как его структурировать. Основываясь на подобных исследованиях
00:11:20и личном опыте: меньше — значит лучше. Загрязнение контекста реально, разложение контекста реально.
00:11:26Поэтому, если что-то находится внутри claud.md и это не имеет смысла для, опять же, практически каждого
00:11:32отдельного промпта, который вы ему даете, должно ли оно там быть? Ответ — нет. Но большинство людей этого не понимают и
00:11:37вместо этого попадают в ловушку раздутого свода правил. Вместо этого навыки, которые мы должны осваивать, —
00:11:42это как создавать контекст проекта с высоким уровнем сигнала. Как мне убедиться, что то, что я на самом деле кладу
00:11:48внутрь этой штуки, имеет смысл? И вместе с этим приходит идея осознания разложения контекста, о которой мы говорили
00:11:53на прошлом уровне. И если взять все это вместе, на уровне два кажется, что вы
00:11:57движетесь вперед: «Эй, я принимаю активное участие в работе памяти, у меня есть этот файл claud.md». Но вы понимаете,
00:12:02что этого на самом деле недостаточно. И когда мы говорим об уровне три и о том, что мы можем сделать для продвижения вперед,
00:12:08мы хотим думать не о статичном своде правил, а о чем-то, что может развиваться, и это
00:12:14что-то, что может включать в себя claud.md. Вместо того чтобы полагаться на claud.md во всем, что если мы
00:12:18будем использовать claud.md своего рода как индексный файл, который указывает Claude Code нужное направление?
00:12:24Что я имел в виду под тем, что claud.md действует как своего рода индекс и указывает на другие файлы?
00:12:30Ну, я говорю об архитектуре внутри вашей кодовой базы, в которой не просто один файл Markdown
00:12:37пытается справиться со всеми проблемами памяти в форме claud.md. Я говорю о наличии
00:12:41нескольких файлов для конкретных задач. Думаю, отличный пример этого в действии — то, как работает GSD, инструмент
00:12:47оркестрации «Get Shit Done». Он не просто создает один файл, в котором говорится: «Эй, вот что
00:12:53мы собираемся построить, вот требования, вот что мы сделали и куда мы идем».
00:12:56Вместо этого он создает несколько. Вы можете видеть здесь слева: у нас есть project.md, requirements.md,
00:13:02roadmap.md и state.md. Требования существуют для того, чтобы Claude Code всегда знал и помнил,
00:13:08что именно он должен строить. Дорожная карта (roadmap) разбивает на части то, что именно мы собираемся
00:13:12создавать не только сейчас, но и что мы сделали в прошлом и будущем. А файл проекта дает ему
00:13:16память, дает ему контекст того, что мы делаем, обзор на высоком уровне: какова наша «путеводная звезда»? И
00:13:22разделяя память, контекст и конвенции в такой системе, мы боремся с идеей
00:13:29разложения контекста и с идеей, высказанной в том исследовании: внедрение этих файлов в каждый
00:13:34промпт все время, как мы делаем в claud.md, на самом деле контрпродуктивно. Это не помогает нам получать
00:13:39лучшие результаты. Кроме того, разбивка на такие чанки и наличие четкого пути, по которому Claude
00:13:44Code может пройти: «Так, я хочу выяснить, где находится эта информация... О, я иду в claud.md».
00:13:49«О, claud.md говорит, что у меня есть пять вариантов. Окей, вот этот нужный. Пойду найду его».
00:13:54Такую структуру вы на 100% увидите на следующем уровне, когда мы будем говорить об
00:13:58Obsidian, и на самом деле это своего рода грубое переосмысление системы чанкинга и
00:14:04векторного поиска по сходству, которые мы видим в настоящих системах RAG. Но, очевидно, на этом уровне все довольно мелкомасштабно.
00:14:10Мы говорим о четырех файлах Markdown, а не о системе, которая
00:14:14может обрабатывать тысячи и тысячи документов. Но, как вы часто будете от меня слышать:
00:14:20что это значит для вас? Нужна ли вам система, о которой мы будем говорить на уровнях 4,
00:14:265, 6, 7, которая может обрабатывать столько документов? Ответ: возможно, и нет. И поэтому часть этого RAG-путешествия
00:14:32состоит в понимании не только того, где вы находитесь, но и того, куда вам на самом деле нужно попасть. Всегда ли
00:14:36вам нужно быть на седьмом уровне и знать, как сделать агентную систему RAG внутри Claude Code? Наверное,
00:14:41полезно знать, как это делать, но так же полезно знать и то, когда вам не нужно
00:14:46это внедрять. Иногда того, что мы видим в подобных системах, вполне достаточно для многих людей.
00:14:52Так что одинаково важно знать, как это делать, и понимать, нужно ли вам это и стоит ли это делать.
00:14:58Когда мы говорим об уровне три и о файлах состояния (state files), как мы понимаем, что мы здесь?
00:15:00Мы понимаем, что мы здесь, когда мы все еще находимся строго внутри экосистемы Claude Code. Мы еще
00:15:04не интегрировали внешние инструменты или приложения, и на самом деле мы просто находимся на этапе создания
00:15:09нескольких файлов Markdown для создания нашей собственной самодельной системы чанкинга памяти.
00:15:14Но это все равно очень важно. Мы все еще осваиваем здесь реальные навыки: идею того, как
00:15:18на самом деле структурировать документы, наличие какой-то системы, которая обновляет состояние на каждой
00:15:23сессии, потому что это может быть проблемой и в RAG: как убедиться, что все в актуальном
00:15:28состоянии? И, скорее всего, в этот момент вы также начинаете склоняться к уровням оркестрации, таким как
00:15:33GSD и Superpowers, которые делают подобные вещи — создают архитектуру из нескольких Markdown-файлов — самостоятельно. Но
00:15:40здесь есть реальная ловушка: то, что мы создаем в этом проекте, предназначено только для этого проекта. И
00:15:46довольно неудобно потом брать эти Markdown-файлы и переносить их в другой проект. Поэтому на уровне
00:15:51четыре мы подключаем Obsidian, и это инструмент, который сейчас на хайпе,
00:15:56и не без причины. Когда такие люди, как Андрей Карпатый, говорят о созданных ими
00:16:00базах знаний для LLM, которые построены, по сути, на фундаменте Obsidian,
00:16:06и это набирает почти 20 миллионов просмотров, нам, вероятно, стоит прислушаться и посмотреть, как это на самом деле работает.
00:16:11Для контекста: я сделал полный глубокий разбор этой базы знаний для LLM Андрея Карпатого в Obsidian,
00:16:18я дам ссылку выше, так что если вы хотите сосредоточиться на том, как это построить, обязательно посмотрите.
00:16:22И что я также хочу упомянуть большинству людей, так это то, что эта тема с Obsidian, о которой мы
00:16:27говорим прямо здесь, на четвертом уровне, — это, честно говоря, тот уровень, к которому большинству людей и стоит стремиться,
00:16:32потому что этого достаточно для большинства людей и большинства сценариев использования. Когда мы будем говорить об уровнях пять, шесть и
00:16:37семь, мы будем обсуждать настоящие структуры RAG, и, честно говоря, для большинства людей это перебор. Это
00:16:43перебор для большинства людей. Мы любим говорить о RAG, это здорово, я это понимаю, но
00:16:50Obsidian — это то решение на 80%, которое в реальности является решением на 99% для большинства, потому что оно бесплатное,
00:16:56практически не требует накладных расходов и отлично справляется с задачей для соло-оператора. И когда я говорю, что оно справляется
00:17:02с задачей для соло-оператора, я имею в виду, что оно решает проблему подключения Claude Code к куче
00:17:07различных документов, куче различных Markdown-файлов, позволяя получать точную и своевременную
00:17:13информацию из них, при этом человек сохраняет понимание того, что в этих документах. Потому что когда я
00:17:19кликаю на эти документы, становится очень ясно, что происходит внутри, и очень ясно, какие документы
00:17:24с ними связаны. Когда я кликаю по этим ссылкам, я попадаю на другие документы, а когда кликаю по тем ссылкам,
00:17:30я перехожу к следующим. И для меня как для человека наличие такого понимания важно,
00:17:36потому что, положа руку на сердце, понимание структуры документов через Obsidian, я бы сказал, превосходит
00:17:42многие инсайты, которые вы получаете от систем RAG. Когда мы говорим о тысячах и тысячах
00:17:47документов, внедренных в нечто вроде системы GraphRAG. Это выглядит отлично визуально,
00:17:52выглядит очень эффектно. Но действительно ли вы знаете, что происходит внутри? Возможно.
00:17:58Честно говоря, вы просто полагаетесь на ответы, которые он показывает, на ссылки и прочее, но
00:18:03в самих эмбеддингах разобраться сложно. Все это к тому, что вам следует обратить особое
00:18:08внимание на Obsidian и Claude Code, потому что, когда мы говорим об этом пути от RAG, я всегда советую
00:18:13всем, включая клиентов: «Давайте просто начнем с Obsidian и посмотрим, как далеко мы сможем это масштабировать».
00:18:20В конце концов, если мы упремся в стену, всегда можно перейти на более надежные RAG-системы. Так почему бы
00:18:26не попробовать простой вариант? Если он сработает — отлично, это бесплатно. Чем пытаться сразу
00:18:31создать RAG-систему, которую может быть довольно трудно внедрить в производство, в зависимости от ваших задач.
00:18:35Всегда начинайте с простого. Никогда не поздно перейти к чему-то более сложному.
00:18:40Итак, о чем мы на самом деле говорим здесь, на четвертом уровне? Мы говорим о том, чтобы взять
00:18:45ту структуру, которую мы начали строить на третьем уровне (с индексным файлом, указывающим на разные
00:18:50markdown-файлы), масштабировать ее и подключить внешний инструмент Obsidian, чтобы
00:18:56вам, человеку, было проще видеть эти связи. Платонический идеал этой версии —
00:19:00это примерно то, что изложил Андрей Карпатый, создавая базу знаний LLM поверх Obsidian
00:19:05на базе Claude Code. И выглядит эта структура следующим образом.
00:19:11Когда вы используете Obsidian (скачиваете его бесплатно, опять же, посмотрите видео, которое я постил ранее),
00:19:16вы назначаете определенную папку своим «хранилищем» (vault). Думайте о хранилище как о своего рода RAG-системе,
00:19:23квази-RAG-системе, которую вы создали. Внутри хранилища мы выстраиваем архитектуру,
00:19:30структурируем его просто с помощью файлов. У нас есть главная папка — хранилище, и внутри
00:19:36мы создаем несколько подпапок. В случае Андрея Карпатого он говорит о трех разных подпапках.
00:19:41На самом деле это могут быть любые папки, они просто должны соответствовать теме, о которой мы говорим.
00:19:47В одной папке у нас «сырые данные» (raw data) — это все, что мы поглощаем и со временем хотим структурировать,
00:19:52чтобы Claude Code мог ссылаться на это позже. Представьте, что вы поручили Claude Code провести
00:19:58конкурентный анализ 50 ваших конкурентов, и он вытягивает по 50 сайтов для каждого.
00:20:03Речь идет о большом объеме информации, около 2500 различных объектов. Все это сбрасывается в какую-то папку raw.
00:20:08Это своего рода площадка для подготовки данных. Далее у нас есть папка wiki. Папка wiki — это то место,
00:20:14куда попадают структурированные данные. Мы заставляем Claude Code взять эти сырые данные и структурировать их,
00:20:20по сути, в разные статьи типа Википедии внутри папки wiki. Каждая статья получает свою папку.
00:20:28Идея в том, что когда вы спрашиваете Claude Code о чем-то (допустим, мы заставили его
00:20:33искать информацию об AI-агентах), и я говорю: «Эй, Claude Code, расскажи мне об AI-агентах»,
00:20:38точно так же, как вы бы запросили RAG-систему, Claude Code пойдет в хранилище, из хранилища
00:20:45он пойдет в wiki. В wiki есть главный индексный markdown-файл — вспомните, что мы уже
00:20:50обсуждали по поводу claud.md раньше. Видите, как эти темы переходят
00:20:56с одного уровня на другой? Он заглядывает в этот главный индекс, и главный индекс сообщает ему,
00:21:00что есть в этой RAG-системе на базе Obsidian. «О, AI-агенты существуют, круто». И угадайте, что происходит дальше?
00:21:08Там также есть индексный файл, в котором говорится об отдельных существующих статьях. О чем я говорю?
00:21:14Я говорю о том, что существует четкая иерархия, к которой Claude Code может обращаться,
00:21:21когда хочет найти информацию: vault, wiki, index, article и так далее. Благодаря тому,
00:21:31что путь поиска и превращения данных в wiki так прозрачен, мы можем создать систему,
00:21:37содержащую множество документов, без полноценного RAG. Сотни, тысячи — если делать это правильно.
00:21:44Если система понятна: «Я проверяю хранилище, проверяю индекс, там четко разграничено, где что находится»,
00:21:50тогда Claude Code не составит труда разобраться, где искать данные. Таким образом,
00:21:54можно обойтись без RAG-структуры для тысяч документов, что раньше было действительно трудно.
00:21:58И все потому, что большинство людей вообще ничего не структурируют. У них просто миллиард
00:22:02документов в одной папке. Это эквивалентно 10 миллионам файлов, разбросанных по полу завода.
00:22:08Сможет ли Claude Code найти что-то? Нет. Вам просто нужен картотечный шкаф. На самом деле
00:22:13Claude Code довольно умен, и вы можете увидеть эту архитектуру в действии прямо здесь. Сейчас мы
00:22:17смотрим на файл claud.md, который находится в хранилище Obsidian. И что там написано? Там
00:22:24разбита структура хранилища, система wiki, общая структура подпапок и то,
00:22:30как с этим работать. Опять же, мы используем claud.md как файл с правилами. Здесь слева
00:22:36вы видите папку wiki, внутри нее главный индекс, и в нем перечислено, что находится внутри.
00:22:43В данном случае там всего одна статья — об управляемых агентах Claude. Внутри этой папки мы видим
00:22:49«Управляемые агенты Claude», там своя папка wiki, разбивающая статьи внутри, пока вы не
00:22:55дойдете до самой статьи. Шаги, которые нужно предпринять, предельно ясны. И когда я говорю Claude Code:
00:23:01«Расскажи мне об управляемых агентах», у нас есть wiki об этом, ему очень легко найти ее через
00:23:06встроенный инструмент grep. Он дает мне ссылку на сам markdown-файл и расписывает все,
00:23:12что там происходит. Теперь на четвертом уровне главным вопросом становится масштаб: сколько
00:23:16документов мы можем себе позволить, чтобы подобная система продолжала работать? Есть ли точка,
00:23:22в которой система Андрея Карпатого начинает разваливаться? «Я понимаю, это очень четкий путь,
00:23:26которому следует Claude Code: он идет по индексам и так далее». Сохранится ли это при
00:23:312000 документов? 2500? 3000? Есть ли точное число? Ответ: мы точно не знаем.
00:23:37Это число может быть и меньше, потому что все ваши документы разные. И столкновение со стеной
00:23:43выражается не только в том, что Claude Code дает неверные ответы из-за избытка файлов в
00:23:47Obsidian. А в том, сколько это стоит вам в токенах теперь, когда мы добавили столько файлов, и как
00:23:52быстро он работает? Ведь RAG может быть бесконечно быстрее и дешевле в определенных ситуациях.
00:23:59То, что мы видим здесь — это сравнение текстовых LLM (гигантские столбцы) и текстовых
00:24:06RAG по количеству токенов, затраченных на получение правильного ответа, и времени,
00:24:11потраченному на этот ответ. Что мы видим? Мы видим, что между текстовым RAG и текстовыми LLM
00:24:18существует огромная разница. Порядка 1200 раз. Я говорю, что RAG в 1200 раз дешевле и в 1200
00:24:25раз быстрее, чем текстовая LLM в этих исследованиях. Контекст: это было сделано в 2025 году, не
00:24:33с Claude Code. С тех пор эти модели значительно изменились. Это просто чистые LLM,
00:24:37а не специализированные инструменты для кодинга и т.д. Тем не менее, речь шла о разнице в 1200 раз. Поэтому,
00:24:48оценивая, стоит ли мне использовать Obsidian или же полноценную RAG-систему, нельзя просто
00:24:54смотреть на то, дает ли она правильный ответ. Ведь может возникнуть ситуация,
00:24:59когда вы получаете верный ответ в Obsidian, но если бы вы использовали RAG, это было бы в тысячу раз дешевле
00:25:04и быстрее. Так что грань между тем, когда достаточно Obsidian
00:25:10и простой архитектуры на markdown-файлах, а когда уже нужен RAG — очень размытая.
00:25:15Точного ответа нет. У меня нет для вас готового ответа. Вам придется экспериментировать,
00:25:18пробовать оба варианта и смотреть, что работает. Потому что эти данные уже устарели — 2025 год,
00:25:25старые модели. Разница между RAG и текстовыми LLM уже не 1200 раз, но насколько сократился
00:25:32этот разрыв? Ведь это был безумный разрыв, не в 10 раз, а в 1200. Нужно многое знать,
00:25:39и опять же, вы не узнаете ответ заранее. Смотрите любые видео, сколько хотите,
00:25:45никто не скажет вам точно, где проходит эта черта. Вам буквально нужно экспериментировать
00:25:49и смотреть, что подходит именно вам по мере увеличения количества документов, по которым
00:25:54Claude Code должен давать ответы. На этой ноте давайте перейдем к пятому уровню, где мы наконец
00:25:59начнем обсуждать реальные RAG-системы и такие основы, как эмбеддинги,
00:26:04векторные базы данных и то, как данные на самом деле проходят через систему, становясь частью нашей
00:26:10базы знаний RAG. Начнем с разговора о «наивном RAG» — это самый базовый тип,
00:26:16но он закладывает фундамент для всего остального. Вы можете представить RAG-систему,
00:26:21разделенную на три части. Слева у нас стадия создания эмбеддингов, далее
00:26:27идет векторная база данных, и затем собственно извлечение (retrieval) с помощью большой
00:26:33языковой модели. Раз, два и три. Чтобы лучше проиллюстрировать эту модель, давайте проследим путь
00:26:40документа, который станет частью нашей базы знаний. Помните, что в большой RAG-системе
00:26:45речь может идти о тысячах документов, и в каждом документе могут быть тысячи страниц. Но в этом
00:26:50примере мы возьмем одностраничный документ. Если мы хотим добавить этот документ
00:26:56в нашу базу данных, он не будет поглощен как единое целое. Вместо этого
00:27:03мы берем этот документ и разбиваем его на части (chunks). Так эта одна страница
00:27:08по сути превращается в три разных фрагмента. Эти три фрагмента затем отправляются в модель эмбеддингов,
00:27:15задача которой — взять эти три части и превратить их в векторы
00:27:21в векторной базе данных. Векторная база данных — это просто разновидность стандартной базы данных.
00:27:27Когда мы говорим о стандартной базе данных, представьте себе Excel-файл: у вас есть
00:27:32столбцы и строки. В векторной базе данных это не двумерные столбцы и строки — там
00:27:37на самом деле сотни, если не тысячи измерений. Но для целей сегодняшнего дня просто представьте
00:27:43трехмерный график, как здесь. Векторы — это просто точки на этом графике, и каждая
00:27:50точка представлена серией чисел. Вы видите здесь бананы, и «бананы»
00:27:57представлены числами 0.52, 5.12 и 9.31. Это продолжается на сотни чисел.
00:28:06Где именно каждый вектор расположится на этом гигантском многомерном графике, зависит от его семантического
00:28:13значения. Что эти слова означают на самом деле? Вы видите здесь секцию
00:28:19фруктов: у нас есть бананы, яблоки, груши. А вот здесь у нас корабли и лодки.
00:28:24Возвращаясь к нашему документу: представим, что этот документ о кораблях Второй мировой войны.
00:28:31Каждый из этих фрагментов превратится в последовательность чисел, и эти числа
00:28:37будут представлены точкой на графике. Как вы думаете, куда они попадут? Скорее всего,
00:28:42в эту область. Это будут раз, два и три. Так размещаются документы: каждый
00:28:49документ разбивается на части, каждая часть проходит через модель эмбеддингов, и она
00:28:54помещает их в векторную базу данных. Повторяем это для каждого документа. В итоге,
00:28:58проделав это несколько тысяч раз, мы получаем векторную базу данных, которая представляет наш граф
00:29:04знаний, нашу базу данных. И это подводит нас к третьему шагу — извлечению.
00:29:09Где во всем этом вы? Обычно, давайте изобразим вас... выделим вас
00:29:16другим цветом, вы будете розовым. Вот вы. Обычно вы просто общаетесь
00:29:23с Claude Code и задаете ему вопросы о линкорах Второй мировой войны. В обычной
00:29:29конфигурации без RAG что произойдет? Языковая модель Opus 4.6
00:29:34заглянет в свои обучающие данные и даст вам ответ на их основе —
00:29:39информацию о линкорах Второй мировой. Но с RAG-системой она сделает больше: она
00:29:44извлечет подходящие векторы. Она использует эти векторы, чтобы дополнить генерируемый ответ
00:29:51для вас. Отсюда и название: «генерация с дополнением извлечением» (Retrieval-Augmented Generation). В этом сила RAG: она
00:29:56позволяет языковым моделям подтягивать информацию, которой нет в их обучающих данных, чтобы дополнить ответ.
00:30:02В данном примере это линкоры Второй мировой. Да, я понимаю, модель это и так знает, но
00:30:06замените это любыми проприетарными данными компании, которых нет в открытом доступе, и сделайте это
00:30:15в масштабе. В этом суть RAG. В нашем примере, когда мы просим Claude Code дать
00:30:21информацию о линкорах Второй мировой в конфигурации с RAG, он
00:30:25возьмет наш вопрос и превратит его в серию чисел, похожую на
00:30:32векторы вот здесь. Затем он посмотрит на числовой код нашего вопроса и коды
00:30:39векторов и определит, какой из этих векторов наиболее точно соответствует вектору вопроса.
00:30:46Насколько векторы похожи на вопрос? После этого он извлечет определенное
00:30:51количество векторов — будь то 1, 2, 3, 4, 5, 10 или 20 — и передаст
00:30:56информацию из этих векторов в большую языковую модель. Теперь у языковой модели есть
00:31:02ее обучающие данные плюс, скажем, информация из 10 векторов. Это была стадия извлечения.
00:31:09Затем она дополняет и генерирует ответ с этой дополнительной информацией. Вот как
00:31:13работает RAG, вот как работает «наивный RAG». Однако это не особо эффективно по ряду причин. Эта
00:31:19очень базовая структура начинает разваливаться в самом начале, когда мы задумываемся: как
00:31:25именно мы разбиваем эти документы на части? Случайно? Просто по количеству токенов?
00:31:31Делаем ли мы нахлест (overlap) между частями? Настроены ли сами документы так, чтобы
00:31:36их вообще имело смысл разбивать? Что если в фрагменте №3 есть ссылка на что-то в фрагменте
00:31:42№1? И когда мы извлекаем фрагменты по векторам, что если мы не получим нужный?
00:31:47Что если он не достанет тот другой фрагмент, необходимый в качестве контекста, чтобы в фрагменте
00:31:53№3 вообще был смысл? Очень часто весь документ целиком необходим для ответа на
00:31:59вопросы по нему. Так что идея получать такие фрагментарные ответы на практике
00:32:05не очень-то работает. Тем не менее, именно так RAG строился долгое время. Могут возникнуть
00:32:10и другие проблемы. Например, что если у меня возникнут вопросы о связях между разными векторами?
00:32:17Ведь сейчас я просто вытаскиваю векторы по отдельности. А что если я захочу узнать, как лодки связаны с
00:32:22бананами? Звучит странно, но вдруг? При стандартном подходе векторной базы данных в стиле наивного RAG
00:32:31все как бы изолировано. Трудно соединять информацию, и многое зависит
00:32:36от того, насколько хорошо были структурированы исходные документы. Подходят ли они
00:32:41для обработки через RAG? За годы мы придумали способы смягчить эти проблемы:
00:32:46например, реранкеры (re-rankers) — системы ранжирования, которые смотрят на все извлеченные векторы и
00:32:51затем еще раз прогоняют их через языковую модель, чтобы расставить их по релевантности. Но
00:32:56в целом эта система «наивного RAG» вышла из моды. Тем не менее, важно
00:33:03понимать, как это работает на фундаментальном уровне, чтобы это могло помочь вам в принятии решений, если вы
00:33:07перейдете к более надежному подходу к RAG. Ведь если вы не понимаете, как работают чанкинг или эмбеддинги,
00:33:13как вы можете решать, как структурировать документы? Когда мы говорим о
00:33:17чем-то вроде GraphRAG или обсуждаем более сложные системы эмбеддингов, например,
00:33:22новую от Google, которая может поглощать не только текст, но и видео. Если вы не понимаете
00:33:27этого фундамента, вам будет сложно понять ловушку. А ловушка в том, что
00:33:31мы, по сути, создали паршивый поисковик. В этих наивных RAG-системах, где все, что мы
00:33:36делаем — это хватаем фрагменты и не можем по-настоящему понять связи между ними, чем это
00:33:42отличается от просто переусложненной системы Ctrl+F? Ответ: особой
00:33:48разницы нет. Вот почему в этих упрощенных, устаревших RAG-структурах, которые
00:33:54на самом деле все еще повсюду... если вы видите кого-то, кто говорит: «О, вот моя
00:33:58RAG-система на Pinecone» или «вот мои стойки на Supabase», и они ничего не упоминают о GraphRAG
00:34:03или не говорят: «Смотрите, у нас есть сложная система реранкинга» —
00:34:07скорее всего, это будет работать плохо. Вплоть до того, что реальная эффективность там около
00:34:1225% правильных ответов. Иногда проще угадать. Если вы не знаете этого
00:34:18заранее, вас легко обмануть, запутать или даже «впарить» вам RAG-систему, в которой нет смысла.
00:34:23Так что пятый уровень — это не о внедрении этих наивных RAG-систем.
00:34:28Он о понимании принципов их работы, чтобы, когда придет время внедрять
00:34:34что-то более сложное, вы действительно понимали, что происходит. Потому что
00:34:38это пятиминутное объяснение RAG — это то, чего, к сожалению, большинство людей не понимает, когда говорит:
00:34:43«Мне нужна RAG-система». А действительно ли нужна? Ведь вы также должны спросить себя: какие вопросы вы
00:34:48на самом деле задаете своей системе? Если вы просто относитесь к своей базе
00:34:54знаний как к огромному своду правил и вам нужно вытаскивать из него конкретные факты,
00:34:59тогда Obsidian, вероятно, достаточно, или можно обойтись даже наивным
00:35:02RAG. Но если нам нужно знать о взаимосвязях, о том, как X взаимодействует с Y,
00:35:09а это два отдельных документа, которые даже не упоминают друг друга, и это нельзя
00:35:13просто засунуть в контекст напрямую, потому что таких документов тысячи — вот тогда
00:35:19вам и понадобится RAG, причем что-то более сложное, чем базовый векторный RAG.
00:35:23Тогда нам пора поговорить о GraphRAG. Когда мы говорим о шестом уровне
00:35:29Claude Code и RAG, мы говорим о GraphRAG, мы говорим об этом. И,
00:35:34на мой взгляд, если вы собираетесь использовать RAG, это минимальный уровень инфраструктуры, который вам
00:35:39нужно создать. Здесь используется LightRAG — полностью открытый инструмент (я оставлю ссылку выше,
00:35:44где подробно разбираю, как им пользоваться и как его собрать). Идея GraphRAG довольно очевидна:
00:35:50это идея того, что все связано. Это не векторная база с кучей изолированных векторов,
00:35:55а множество вещей, соединенных друг с другом. Я нажимаю на этот документ и вижу вот здесь
00:36:00справа (сейчас передвину) описание вектора, имя, тип, файл, фрагмент и, что еще
00:36:05важнее, различные взаимосвязи. И этот подход, основанный на связях,
00:36:10дает более эффективные результаты. Вот график из GitHub-репозитория LightRAG. Ему примерно
00:36:156-8 месяцев. Также отмечу, что LightRAG — это самая легковесная система GraphRAG,
00:36:23которую я знаю. Есть очень мощные версии, включая саму GraphRAG от
00:36:30Microsoft — она буквально так и называется. Но когда мы сравниваем наивный RAG с LightRAG,
00:36:35повсеместно мы видим скачки эффективности часто более чем на 100%. 31.6 против 68.4,
00:36:4324 против 75 и так далее. И при этом, согласно данным LightRAG,
00:36:49он на самом деле держится уверенно и даже обходит сам GraphRAG, но эй, это цифры от LightRAG, так что
00:36:54воспринимайте их с долей скепсиса. Теперь, когда мы смотрим на эту систему графа знаний, ваш разум,
00:36:58вероятно, сразу обращается к Obsidian, потому что это выглядит очень похоже. Однако то, что мы видим здесь,
00:37:04в Obsidian, гораздо более рудиментарно, чем то, что происходит внутри LightRAG или любой системы GraphRAG,
00:37:10потому что эта серия связей, которую мы видим здесь, создана вручную и в некоторой степени произвольна. Это
00:37:16связано только потому, что мы установили связь между документами или Claude Code установил её, когда создавал
00:37:22этот конкретный документ. Например, просто добавил пару скобок — и бам, документ связан.
00:37:27Так что теоретически я мог бы соединить кучу случайных документов, которые на самом деле не имеют ничего общего
00:37:30друг с другом. Конечно, Claude Code не глуп и не станет этого делать, но это сильно отличается
00:37:35от того, что произошло здесь. Тут всё прошло через реальную систему эмбеддингов, она проанализировала само
00:37:41содержание, установила отношения, выделила сущности. Внутри LightRAG проводится гораздо больше работы
00:37:46по определению связей, чем в Obsidian. Но приводит ли эта разница на самом деле
00:37:52к какому-то дикому разрыву в производительности на низком уровне? Возможно, при огромном масштабе.
00:38:02Опять же, мы находимся в «серой зоне», всё зависит от ваших масштабов и того, о чем именно мы говорим,
00:38:07и никто не ответит на этот вопрос, кроме вас самих и личного опыта. Но поймите, эти две
00:38:13вещи — не одно и то же. Мы не одинаковы, брат. Это две совершенно разные системы: одна довольно
00:38:20сложная, другая — довольно примитивная. Поймите это. И в завершение шестого уровня в GraphRAG:
00:38:26мы оказываемся здесь, когда решаем: «Эй, штуки вроде Obsidian не подходят, мы не можем использовать
00:38:31обычный RAG, потому что он просто не справляется, и нам нужно что-то, способное извлекать сущности
00:38:36и отношения, и по-настоящему использовать гибридную систему запросов "вектор плюс граф"».
00:38:43Но есть и ловушки, есть серьезные препятствия даже здесь, на шестом уровне. Когда мы говорим
00:38:48о LightRAG — это только текст. А что если у меня есть отсканированные PDF? Что если у меня есть видео? Что если
00:38:55у меня есть изображения? Мы не живем в мире, где все ваши документы будут только из Google Docs.
00:39:01И что нам делать в таких случаях? Мультимодальный поиск — это огромная тема, и вдобавок ко всему,
00:39:06как насчет того, чтобы добавить этим системам больше агентных качеств? Дать им немного больше мощи ИИ,
00:39:11какой-то скачок в этом направлении? Что ж, если мы говорим о мультимодальных вещах, то мы можем, наконец, перейти
00:39:17к самому передовому краю RAG на сегодняшний день — по состоянию на апрель 2026 года. Это то, чему посвящен 7-й уровень.
00:39:24Говоря о седьмом уровне в агентном RAG, главное, на чем мы хотим сделать акцент — это
00:39:31вещи, связанные с мультимодальной обработкой данных. Мы уже делали видео об этом, о таких инструментах,
00:39:36как RAG-Anything, которые позволяют импортировать изображения и нетекстовые документы (опять же, вспомните
00:39:44отсканированные PDF) в структуры вроде графа знаний LightRAG, который вы видели здесь. Также есть новые релизы,
00:39:49такие как Gemini Embedding 2, вышедший в марте, который позволяет нам встраивать видео прямо в нашу
00:39:56векторную базу данных. Само видео. И честно говоря, именно туда движется индустрия. Недостаточно работать
00:40:01только с текстом. Как много информации, как много знаний заперто в интернете, особенно в таких местах,
00:40:06как YouTube, где контент — чистое видео? И нам нужно больше, чем просто транскрипция. Самой
00:40:10транскрипции недостаточно. Эта мультимодальная проблема реальна, и, опять же, это те вещи,
00:40:16которые появились всего несколько недель назад. Седьмой уровень — это также то место, где нам нужно начать
00:40:20уделять внимание нашей архитектуре и пайплайнам, когда речь идет о данных, входящих в систему RAG и выходящих из нее.
00:40:25Недостаточно просто поместить сюда данные. Это здорово, вы знаете: «Окей, у нас есть все эти связи и прочее».
00:40:30Но как данные туда попадают? Как они попадают туда в контексте работы команды? Как данные
00:40:35выводятся оттуда? Что если часть информации здесь изменилась в конкретном документе?
00:40:40Что если кто-то отредактировал его? Как он обновляется? Что если мы добавим дубликаты? Кто вообще может
00:40:46размещать там эти вещи? Когда дело доходит до продакшн-уровня, это те самые вопросы,
00:40:50которые вам нужно начать себе задавать. И когда мы смотрим на систему агентного RAG, подобную этой от
00:40:54n8n, вы видите, что подавляющая часть инфраструктуры — всё, что здесь обозначено, — полностью посвящена
00:41:01сбору и синхронизации данных. Есть лишь очень небольшая часть, имеющая отношение к самому RAG,
00:41:06которая находится прямо здесь. Потому что нам нужны системы, которые очищают данные, которые способны видеть:
00:41:11«Окей, мы только что загрузили этот документ, на самом деле это вторая версия первой, можем ли мы теперь вернуться и очистить те данные?»
00:41:17Вот пример пайплайна загрузки данных, где документы не попадают напрямую в систему,
00:41:21как в LightRAG. Вместо этого мы помещаем их, скажем, в Google Drive, а оттуда они загружаются
00:41:27в систему Graph RAG и заносятся в логи. Именно такие вещи определят успех или провал
00:41:31вашей RAG-системы в реальной работе. И когда мы говорим об агентном RAG, вы видите здесь,
00:41:37пусть и немного размыто, что если у нас есть ИИ-агент, управляющий всей программой — представьте,
00:41:42вы создали чат-бота для своей команды — нужно ли ему всегда обращаться к этой базе данных? Ответ:
00:41:49скорее всего, нет. Вероятно, в командной или бизнес-среде у вас будет
00:41:54информация в подобной базе, например, текст, но, скорее всего, у вас также есть
00:41:58другой набор баз данных, например, обычные базы Postgres с кучей информации, которую вы хотите
00:42:03запрашивать через SQL. Поэтому, когда мы говорим об агентной RAG-системе, нам нужно нечто,
00:42:08способное разумно решать: «Так, стоит ли мне сейчас обратиться к базе Graph RAG,
00:42:15показанной здесь, или же просто выполнить SQL-запросы в Postgres?». Всё это может
00:42:20усложняться, верно? И всё это зависит от конкретного случая использования, поэтому порой сложно
00:42:23делать такие видео и пытаться охватить каждый нюанс. Суть 7-го уровня не в том,
00:42:30что существует какая-то «супер-RAG-система», о которой вы никогда не слышали, а в том, что
00:42:34дьявол кроется в деталях, и в основном это касается этапа загрузки данных и поддержания их
00:42:39в актуальном состоянии. А также того, как вы к этому обращаетесь. В демо-версии всё просто:
00:42:46мы заходим в LightRAG, переходим в раздел извлечения и задаем вопросы. Но сценарий меняется,
00:42:50когда речь идет о команде, где каждый подходит к задаче со своей стороны, и вы,
00:42:55вероятно, не хотите, чтобы у всех был доступ к прямой загрузке данных в сам LightRAG
00:43:01через веб-приложение. Тем не менее, для индивидуального разработчика, который хочет создать сложную
00:43:07RAG-систему с поддержкой мультимодальности, я бы посоветовал связку RAG-Anything и LightRAG.
00:43:14Я уже делал об этом видео, и если еще не прикрепил ссылку, то добавлю её выше. Рекомендую это
00:43:19по нескольким причинам: во-первых, это открытый исходный код и легковесное решение, так что вы не
00:43:26тратите кучу денег или времени на запуск чего-то подобного, чтобы проверить, подходит ли это вам.
00:43:31Опять же, мы не хотим застрять в закрытых системах, на которые уже
00:43:37потратили кучу денег, — именно поэтому я так люблю Obsidian и всегда советую такие вещи,
00:43:42как LightRAG и RAG-Anything. Ведь если вы попробуете и это не сработает или
00:43:45не подойдет — ничего страшного, вы потратили всего пару часов, а не
00:43:50состояние на GraphRAG от Microsoft, который отнюдь не дешев. Итак, когда вы понимаете,
00:43:56что находитесь на 7-м уровне? Это по-настоящему мультимодальные вещи: индексация изображений, таблиц, видео
00:44:02и интеграция агентной системы, которая может разумно решать, по какому пути пойти,
00:44:06чтобы найти ответ. Ведь на 7-м уровне вы, скорее всего, объединяете всё это: у вас наверняка
00:44:12есть файлы .claud.md с важной информацией, возможно, есть кодовая база с markdown-файлами
00:44:16для быстрого поиска; возможно, вы также используете хранилище Obsidian,
00:44:20плюс у вас есть часть документов в базе данных Graph RAG,
00:44:25и над всем этим стоит ИИ-система, которая решает: «Ага, на этот вопрос я пойду
00:44:33вот этим путем». Это зрелая архитектура памяти, которую я бы советовал, но в чем здесь ловушка?
00:44:40Ловушка, честно говоря, в том, чтобы заставлять себя переходить на этот уровень сложности,
00:44:47когда в этом нет необходимости. По правде говоря, большинству из вас вполне хватит Obsidian.
00:44:52Вам не нужен Graph RAG, вам вообще особо не нужен RAG в целом. И если не очевидно,
00:44:57что вам нужен 7-й уровень, и уж тем более, если вы еще не пробовали путь с Obsidian, вам это не нужно.
00:45:01Это, скорее всего, пустая трата времени. Но цель всего этого видео заключалась в том,
00:45:07чтобы максимально наглядно показать вам разные уровни RAG, памяти и Claude Code, и в чем
00:45:12заключается проблема, каковы болевые точки и компромиссы, и где вам стоит находиться
00:45:18в зависимости от ваших задач. И опять же, главное — просто экспериментируйте. Вам не нужно знать
00:45:24ответ заранее, просто пробуйте. Я бы советовал идти по восходящей: если вы можете
00:45:28обойтись простыми markdown-файлами в системе Claude — отлично, так и делайте.
00:45:34Затем попробуйте Obsidian; если его мало — пробуйте LightRAG и так далее. На этом
00:45:39я сегодня и закончу. Если хотите узнать больше, особенно о промышленном
00:45:43применении RAG — как запустить это для команды или упаковать для клиента — у нас есть целый модуль
00:45:47об этом в Chase AI Plus, так что заглядывайте. В остальном, пишите, что думаете,
00:45:52я знаю, это было долгое видео. Еще увидимся!