СОЗДАЙ СВОЙ ВТОРОЙ МОЗГ НА ОСНОВЕ ИИ: полный гайд по построению памяти и RAG для ии-агентов

Каждый, кто прикасался к ИИ-агентам, по-любому задумывался над концепцией второго мозга и видел красивейшие графы заметок людей, которые пользуются Obsidian. И кажется сделать из агента отражение своей базы знаний или ассистента с бесконечной памятью максимально легко: просто скинул все свои заметки и материалы в папку, где живёт агент и всё, перед тобой гениальный ИИ бро который либо о тебе знает всё. Но закинув, ты конечно же обнаружишь, что ничего не работает :))

Сегодня будем расхаживать по тесным чертогам разума ИИ-агентов и толковать о том, почему железная коробка до сих пор забывает, что ты просил её сделать пять минут назад, ну и конечно же узнаем ответы на главные вопросы:

Почему твой агент не находит те заметки, что нужны? Как искать среди своих заметок по смыслу, а не по ключевым словам? Что такое RAG, векторные БД и семантический поиск? Почему перелинковка заметок в обсидиан НИКАК не улучшает понимание агентом твоих файлов? Можно ли всё-таки создать свой второй мозг и какие инструменты для этого выбрать?

С этим раскудрявыми темами мы и будем разбираться.

Меня зовут Пироман 17, я исследую web3 рынок, работаю в Data Science, год активно занимаюсь темой AI. В своём телеграм канале пишу про то, как строю свою AI систему, как при помощи неё выношу рынок, а также рассказываю про билдинг своего стартапа на стыке web3 и AI.

Поехали😤

Стоит начать с того, что у агента вообще НЕТ ПАМЯТИ, он обладает только локальным контекстным окном, которое существует в рамках одной сессии и в стоковом виде в нём находятся:

Тогда что мы все называем памятью агента? По сути это внешнее хранилище данных + специальный механизм, который перетаскивает из хранилища только релевантную информацию в контекст агента. Этот процесс мы называем RAG.

Что из себя представляет:

RAG (Retrieval-Augmented Generation) - это технология, которая позволяет LLM формировать ответы на основе ваших собственных, актуальных и специфических данных, которые располагаются в векторной БД.

Само название технологии расшифровывается через три её главных этапа:

Эта технология решают проблему лимитов контекстного окна: вы не можете просто скопировать огромную книгу или базу данных и вставить её в промпт ИИ, текст либо не поместится в лимит контекста, либо такой запрос будет стоить очень дорого. RAG решает эту проблему, извлекая только самую нужную выжимку.

Этапы работы RAG:

Этап 1: Подготовка ваших данных

Перед тем как RAG начнёт работать, все данные, которые у вас есть (например ваш obsidian vault) нужно поместить в векторную базу данных. Как это происходит:

Этап 2: Обработка вопроса пользователя

Далее разберём как происходит поиск релевантной информации в соответствии с промптом пользователя

Этап 3: Извлечение контекста

На всём, что я описал выше, зиждется любой инструмент, дающий память вашему агенту - это база, которую нужно запомнить. Теперь, переходя к практике, важно осознать следующее:

RAG - это ДИСЦИПЛИНА РАЗРАБОТКИ, такая же как, например, создание веб-приложений. Нельзя просто прийти в гугл с запросом "Скачать RAG на Claude Code". Хотя решения под ключ конечно же существуют, в первую очередь это отдельная дисциплина, по которой даже чемпионаты проводятся.

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

Мы разберём оба.

Я не буду вам переписывать мануалы по использованию разных инструментов для разработки RAG - это бессмысленно, тем более в эпоху ИИ, когда каждый просто может закинуть документацию в NotebookLM или открыть её через DeepWiki и узнать всё, что он захочет, а потом это навайбкодить.

Моя задача - отсеять весь шум и дать вам фундаментальное понимание того:

Сразу же разберём главный инструмент для ручной разработки RAG:

Фреймворк "LlamaIndex"

P.S. Для не айтишников: фреймворк – это НАБОР из МОДУЛЕЙ С КОДОМ, каждый из которых покрывает какую-то из задач RAG (конкретно в нашем кейсе). Пример: вместо print 'hello world' можно просто написать h.w Фишечка в том, что в этих модулях за нас уже продумана архитектура, настройки, правила и т.п., и всё заточено под RAG.

Данный инструмент будет являться базовым для нас, он будет связывать все инструменты, что мы будем использовать, между собой. По сути мы можем не юзать никакие другие инструменты и собрать RAG чисто на одном этом фреймворке, так как он обладает огромным количеством модулей. Но в таком случае наш пайплайн получится очень скудным, поэтому каждый этап RAG мы будем апгрейдить.

Есть 3 главных элемента (этапа) RAG:

Сейчас мы разберём каждый из них.

Начало нашего цикла RAG. Качество этого этапа определяет всю последующую работу системы, так как именно по чанкам будет осуществляться поиск.

Size-based chunking

Самый простой и быстрый метод, при котором текст делится вслепую по достижении заданного лимита (как правило, 400-512 токенов), без учета смысловых границ документа.

Метод невероятно быстр, не требует вычислительных затрат и выдает предсказуемые размеры блоков, однако он игнорирует смысловые границы, может разрезать таблицы или предложения на полуслове.

Для того, чтобы компенсировать обрыв мысли на стыке блоков, применяется "overlap" 10-20% от размера чанка, когда конец одного блока становится началом следующего.

Recursive Chunking

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

Чтобы понять, где границы у текста, алгоритм считывает специальный символы (в случае с абзацем - двойной перенос строки), поэтому данная стратегия хорошо подходит для обработки кода, т.к. можно задать в качестве разделителей какие-то специфические команды, например вызов новой функции

Sentence-Based Chunking

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

Способ гарантирует, что ни одна мысль не будет прервана посередине, что делает текст максимально связным для чтения языковой моделью. Однако длинные предложения могут создавать слишком большие чанки, а сам алгоритм может давать сбои на плохо отформатированном тексте.

Подходит для: диалоговых логов, Q&A и текстов с четкой структурой предложений

Page-Level Chunking

Извлекает контент страница за страницей, создавая один чанк на каждую страницу документа.

Идеально подходит для чанкинга PDF-файлов, финансовых отчетов и презентаций, поскольку сохраняет визуальную верстку, удерживая таблицы, рисунки и связанный с ними текст в едином контексте.

Из минусов: подходит только для документов, имеющих физическую пагинацию, и может генерировать чанки непредсказуемого размера в зависимости от плотности текста на странице.

Semantic Chunking

Этот метод дробит текст не по чётким границам, а по смыслу. Система анализирует связь между соседними предложениями и создает новый чанк там, где происходит смена темы.

Алгоритм разбивает текст на предложения, генерирует эмбеддинги для каждого из них, а затем вычисляет математическое сходство между соседними векторами. Если сходство падает ниже заданного порога, фиксируется смысловой разрыв.

Есть ещё супер продвинутый варианты данной стратегии, такие как: кластерный семантический чанкинг - группирует похожие предложения, даже если они не стоят рядом; и иерархический чанкинг - создаёт краткие хай-левел чанки с саммари общего контекса (например на уровне глав, если мы говорим о книге), а внутри них создаёт уже более маленькие детализированные чанки.

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

LLM-Based Chunking

Вместо математических формул или фиксированных правил, документы передаются напрямую в LLM, которая анализирует структуру и решает, где провести логические границы. Модель может не только определять точки разрыва, но и генерировать метаданные или краткие резюме для каждого созданного чанка.

Обеспечивает максимальное понимание контекста и динамическую адаптацию под солжные структуры документов, но опять супер дорого в использовании и, как правило, процесс чанкинга происходит очень долго. Для масштабных задач пока что не очень подходит.

Late Chunking

Данный алгоритм работает так: программа считывает весь документ и переводит его в базовые единицы текста - слова или части слов (токены). Далее алгоритм анализирует весь текст (все токены) сразу, математически вычисляя связи между всеми словами (токенами), чтобы, например, местоимение точно связалось с нужным именем из другого абзаца. Только после того, как каждое слово впитало смысл всего документа (стало контекстуализированным), текст разрезается на чанки. На последнем этапе эмбеддинги слов внутри каждого отдельного чанка математически складываются в единое среднее значение. В итоге формируются короткие фрагменты, которые хранят в себе глобальный смысл всего исходного документа.

Late chunking не заменяет привычные алгоритмы чанкинга, а работает как дополнительный слой поверх них, который очень повышает итоговую точность поиска.

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

КАКУЮ СТРАТЕГИЮ ВЫБРАТЬ?

На первый взгляд может показаться, что нужно просто скомбинировать все самые мощные методы и мы получим "крутецкую круть", которая сделает из нашего агента AGI.

Но на универсального решения не существует.

Для базового выбора по умолчанию советую использовать рекурсивный чанкинг с размером фрагментов 400-512 токенов и оверлепом 10-20%.

Если вы богатый или у вас есть мощное железа для запуска локальных моделек, то можете прокать семантический и LLM чанкинг, ну и конечно если у вас огромная база знаний и для ваших задач требуется серьёзная аналитическая работа (например, вы делаете RAG в корпоративных целях для решения юридических задач).

Плюсом ко всему совершенно недавно вышло исследование, которое доказывает, что рекурсивное разбиение по символам на фрагменты в 512 токенов дает максимальную точность ответов. При этом сложный чанкинг показал наихудшие результаты.

Таким образом, на практике, на этапе обработки исходных документов вместо выбора супер умных стратегий чанкинга лучше сфокусироваться на:

КАКИЕ ИНСТУРМЕНТЫ ИСПОЛЬЗОВАТЬ?

С базовым чанкингом и не сложными пайплайнами отлично справляется базовый LlamaIndex. Для простого RAG и первого раз ничего сверхъестественного придумывать не надо.

Но если вы хотите попробовать что-то более сочное и мощное, то маст хев юзать Chonkie - лёгкая и быстрая библиотека (условно, то же самое, что и фреймворк) для построения продвинутого чанкинга. Её главные фишечки в том, что, во-первых, она обеспечивает ОЧЕНЬ высокую скорость чанкинга , во-вторых, она содержит большое количество методов чанкинга.

Эксперименты показывают, что использование чанков от Chonkie повышает качество ответов языковой модели: по результатам оценки метриками DeepEval (релевантность, точность фактов, полнота контекста), Chonkie получил наивысший средний балл среди конкурентов, среди которых был и LlamaIndex.

Если вы собираетесь в своём RAG использовать pdf файлы как исходники крайне рекомендую ознакомиться со следующими тулзами:

Что касаемо обогащения метаданными здесь хочу отметить хороший парсер маркдаун заметок встроенный в лламаиндекс - вместе с чанками он сохраняет метаданные (например, сохраняет структуру заголовков благодаря чему при поиске видна структура мд заметки).

Глобально, чуваки, ваще не парьтесь над этим этапом. Есть куча embed моделей, но по факту мало чем они отличаются.

Просто задеплойте себе какую-нибудь локальную модельку по типу paraphrase-multilingual-minilm-l12-v2 (сам такую юзаю) или чё нибудь совсем простое типо nomic-embed-text.

Единственная моделька которую действительно хочется выделить это Gemini Embedding 2 - она умеет превращать в эмбединги не только текст, но и картинки, видео, аудио и PDF.

Причем всё это ложится в одно математическое пространство (то есть не отдельно для видосиков у нас есть циферки, отдельно для аудио, а всё в одной математически-смысловой территории).

Это круто, потому что без такой модельки вам приходится городить огромные цепочки по обработке нетекстовых документов, а тут сразу без заморочек из коробки всё можно превратить в эмбединги. Из минусов - она платная)))

P.S. Гугл вообще в целом топ-1 в мультимодальности

На этом этапе у нас происходит хранение и поиск эмбеддингов.

Векторных баз в целом просто туча, но для вас я разберу только самые сочные из них. Но для начала стоит определить, что векторные БД существуют:

И здесь появляется важный нюанс: когда вы деплоите векторную БД локально, вам нужно быть готовым к тому, что она будет есть очень много оперативки, так как эмбединги будут храниться именно там.

После того, как вы выключите ПК / саму БД эмбеддинги будут просто пропадать и embed моделькам придётся заново всё считать при последующих запусках. Чтобы это избежать нужно обязательно настроить автоматическую выгрузку эмбедингов из RAM на жёсткий диск и подгрузку их при запуске БД.

По модному вся эта бурда называется персистентность))

Если вы используете облачную БД и платите за неё свои драгоценные шекели, то заморачиваться вам с этим всем не придётся, настройку персистентности)) берёт на себя провайдер.

Окей, давайте разбираться какие же БД у нас есть.

Лично я ограничиваюсь Qdrant и мне хватает за глаза для своего локального RAG.

И ЧТО ДЕЛАТЬ ДАЛЬШЕ?

А дальше просто вайбкодить!

Просто проговариваешь своему клоду, что ты хочешь видеть в своём пайплайне, рефлексируешь вместе с ним и делаешь итерации - вот и вся магия.

Даже если что-то сейчас вам кажется непонятным, скорее всего, это не так важно, так как у вас сейчас есть реально все базовые знания, определения и представления, благодаря которым вы сможете детально описать своему ИИ-агенту, что вы хотите видеть - большего и не надо.

А если большее и потребуется, то вы всегда сможете углубиться в какую-либо тему благодаря ИИ.

Внезапно мы переходим к совершенно другой теме))

Я решил вставить этот блок именно сюда, перед разбором готовых решений, потому что

Выше я выдал всю фундаментальную базу и на том можно было даже и закончить статью, ахах) Но у нас дип дайв! Поэтому сейчас разбираемся, что у нас наслаивается ещё поверх нашего фундамента.

Это вообще авантюрно-фишечная тема. Суть данного метода в том, что здесь мы используем не обычную векторную БД, а графовую.

Хотя классический RAG отлично справляется с базовым извлечением фактов, у него есть существенный изъян. Он слепо делит тексты на отдельные, несвязанные фрагменты (чанки), из-за чего ИИ-агент часто теряет глобальный контекст. Если мы хотим наделить агента по-настоящему глубокой памятью, нам нужен инструмент, работающий иначе - GraphRAG.

Что из себя представляет:

Вместо изолированных кусков текста GraphRAG извлекает из данных сущности (entities) и связывающие их отношения или рёбра (relationships).

И такие взаимосвязанные сущности являются представлением смысла исходного текста и составляют нашу графовую базу данных:

По своей логике этот подход очень похож на метод ведения заметок Zettelkasten (популярный в приложении Obsidian) или на саму человеческую память. В нашей памяти факты не существуют в вакууме: например, понятие "Лондон" связано с понятием "чай" невидимой логической нитью, потому что мы знаем, что "англичане любят чай". Благодаря этому ИИ-агент видит полную картину и отвечает значительно эффективнее.

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

P.S. Здесь важно добавить, что, если вы прикуртите к своему обсдиану графРАГ и будете связывать заметки с помощью [[ ]], вашей графРАГ будет глубоко плевать на это. Для пайплайнов и ИИ вот эти линки в обсдиан - просто текст, который ни на что не влияет.

Какие инсутрменты использовать:

В качестве ядра нашего графРАГ можно продолжить юзать LlamaIndex - у него есть уже встроенные функции для работы с графами и их построением.

Но всё же LlamaIndex не заточен специально под GraphRAG и результат скорее всего получится не очень.

Поэтому лучше всего использовать специализированный фреймворк Microsoft GraphRAG.

Лучшей и самой популярной графовой БД является - Neo4j

А визуализировать весь свой невероятный knowledge graph с помощью Gephi

А если вы хотите сделать жёсткий дип дайв в тему графового RAG, то советую почитать эту книгу от главы разработки в Neo4j и прогера, участвовавшего в разработке фреймворка LlamaIndex.

Это не совершенно другой тип RAG, как графовый, а больше как надстройка над любым RAG пайплайном.

Что из себя представляет:

Это подход, при котором ИИ-агент автономно управляет процессом поиска данных. Вместо однократного извлечения документов по жестко заданному алгоритму, агент анализирует запрос, составляет план действий и динамически вызывает подходящие инструменты.

Найденная информация сразу оценивается самой моделью: если данных не хватает или они нерелевантны, система корректирует запрос и запускает новые итерации поиска.

Этот цикл повторяется до тех пор, пока агент не соберет достаточный и проверенный контекст для генерации финального ответа.

Какие инсутрменты использовать:

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

Существует ещё невероятное количество разных фреймворков и инструментов, но для большинства задач этих хватит. Да и смысла все расписывать нет - это будет ту мач.

P.S. Эти инструменты вы можете юзать не только чтобы сделать AgenticRAG, но и, в целом, что прогать своих собственных ИИ-агентов)

Это надстройка над классическим RAG, которая позволяет хранить и искать данные на нескольких уровнях масштаба.

Что из себя представляет:

Благодаря данной технологии документ с исходными данными разбивается на крупные родительские фрагменты, которые затем делятся на более мелкие дочерние

Эмбеддинги вычисляются только для мелких дочерних чанков, что обеспечивает высокую точность семантического поиска, поскольку в них меньше информационного шума. Однако, когда система находит релевантный дочерний чанк, она извлекает и передает LLM весь связанный с ним родительский фрагмент или документ целиком

Таким образом, LLM получает более широкий контекст вокруг найденного факта.

Главная фишечка здесь, что данная технология старается решить одну из проблем классического RAG: либо ты хранишь мелкие куски и теряешь общий смысл, либо хранишь крупные и теряешь точность поиска. Организация данных в виде иерархии позволяет системе понимать как мелкие детали, так и глобальные концепции корпуса документов.

Какие инсутрменты использовать:

В LlamaIndex есть такая тема как RaptorPack. Это реализация алгоритма, который рекурсивно кластеризует и суммаризирует документы в иерархические слои.

Ещё в том же LlamaIndex есть функции:

Вот такие вот продвинуты стратегии RAG :)

Небольшое предисловие: все данные решения подключаются к вашему Claude Code по MCP (за исключением 1 инструмента, я об этом скажу).

Mem0

Представляет собой продвинутый RAG пайплайн под ключ и с облачным подключением без заморочек с локальным развёртыванием (есть и возможность локально деплойнуть).

Поиск производится посредством семантического и графового анализа одновременно + дополнительно по метаданным. В качестве векторной БД в базе использует Qdrant (можно подключить и другие), в качестве графово - Neo4j, а для метаданных - PostgreSQL.

НО важно учитывать: Mem0 специализируется, в первую очередь, на векторной памяти через Qdrant или аналогичные БД. Графы использует, скорее, как вспомогательную структуру для сохранения информации о связях между конкретными сущностями. Поэтому реализация графового модуля оказывается очень упрощённой и иногда глупой.

Также в пайплайн встроен механизм реранкинга - это когда сторонняя LLM переупорядочивает найденные чанки по релевантности перед тем как отправлять в контекст вашего сообщения.

Память обновляется полностью автоматически в фоновом режиме посредством извлечения встроенной LLM из ваших сессий с агентом ключевых фактов и архитектурных решений (если речь про разработку). Система сама решает когда что-то добавлять в память, а когда что-то извлекать для добавления в контекст.

Также из интересных фишечек Mem0 имеет облачный дашборд для управления памятью, а также поддерживает мультимодальность, т.е. помимо текста можно загружать ещё и видео, картиночки.

QMD

Немного писал уже о данном инструменте в своём тгк.

Представляет собой локальную поисковую систему для markdown-заметок, созданную CEO Shopify

Как только вы отправляете запрос в программу, локальная LLM расширяет ваш запрос синонимами и производит поиск.

Длаее алгоритм параллельно запускает лексический (по ключевым словам) и векторный поиск.

Результаты объединяются алгоритмом RRF (алгоритм объединения результатов из нескольких поисковых списков. Он не сравнивает оценки результатов напрямую, а учитывает, на каком месте каждый результат оказался в разных источниках) и переранжируются для выдачи топ-30 фрагментов для контекста.

Дробление исходных доков производится посредством AST-Aware Chunking, который:

Из минусов: ОЧЕНЬ сильно нагружает оперативку и порой достаточно долго думает. Но результаты, которые он выдаёт - мне нравятся.

Важно: работает только на маке и линуксе

OpenViking

Представляет память не как плоскую векторную базу данных, а как иерархическую файловую систему с URL-адресацией (например, viking://projects/changelog.md), что хорошо структурирует память и придаёт ей иерархичности.

Данный инсутрмент построен на Agent File System и его главная идея в том, чтобы хранить контекст не как длинную историю разных сессий, а как структурированные файлы и папки: заметки, сводки, решения, факты, проекты.

Поиск по нашей виртуальной файловой системе памяти производится по нескольким ступеням:

Также все свои знания OpenViking категорирует по следующим группам:

Поиск по памяти осуществляется рекурсивным методом. Это означает, что сначала он определяет наиболее релевантные каталоги или области контекста, а уже потом углубляется в их содержимое.

Важная идея здесь в том, что поиск идет не просто по похожим фрагментам, как в обычном RAG, а по структуре памяти. Это делает поиск быстрее и прозрачнее.

Если кратко разбирать цикл работы OpenViking, то он устроен следующим образом:

Graphiti

Представляет собой надстройку над популярными графовыми БД, а именно: Neo4j и FalkorDB.

Graphiti предлагает сохранять не только статические данные в графах знаний, но также привязывать их к конкретному моменту времени: когда образовались объекты (улзы в графе), какие сформировались отношения между ними, как они менялись со временем и в какой момент стали неактуальны.

Все эти данные будут записаны в граф и вы сможете достаточно легко их получить.

Извлечение памяти в данном инструменте гибридное: семантическое, лексическое и графовое

Пример использования (с официального сайта): можно реализовать память о программном проекте (разработка какого-то ПО) в качестве Graphiti графа с помощью MCP Graphiti, подключенному к Claude Code. Фактически, в результате мы получаем память о проекте и всех изменениях, которые в нём происходили c учётом связей между различными сущностями. Что позволяет CC в любой момент задать в граф вопрос в духе "Кто, зачем и когда добавил ту или иную фичу?" и получить на него ответ.

В общем, топ инструмент для аналитической работы с постоянно изменяющимися данными!

Hindsight

Инструмент, основанный на GraphRAG. Его память разделена на 4 типа:

При этом опыт, мнения и наблюдения формируются в процессе взаимодействия с пользователем. То есть мы имеем обучающуюся и развивающуюся систему, которая изменяется при взаимодействии с пользователем.

В любой момент можно посмотреть, в результате чего сформировался опыт или мнение агента.

Все сохранённые знания также обладают временной привязанностью. Есть функция отображение данных из графа на таймлайне – это топ. Очень удобно анализировать.

Обладает четырехмерным поиском: семантика, ключевые слова, граф, время.

Отличия от Graphiti: графити более кастомизируемый инструмент и более скудный из коробки, в то время как хиндсайт является полностью решением под ключ и работает замечательно сразу после деплоя.

Важно: подключается к Claude Code через плагин hindsight-memory

Cognee

Хорошо кастомизируемый движок знаний для ИИ-агентов. Сочетает в себе векторный и графовый поиск, а также фильтрацию по метаданным.

Дробление доков производится, как в QMD, посредством AST-Aware Chunking.

Cognee сам готовит любой загруженный документ (более 30 типов поддерживает) к загрузке в векторную БД. Потом из каждого чанка извлекает сущности, из которых строит граф связей.

Есть привязка фактов ко временни.

Есть режим, в котором LLM самостоятельно определяет режим поиска по данным (типо AgenticRAG). Правда, если это не SOTA-модель, лучше определять его самостоятельно.

Ключевая фишечка: очень быстро и легко развёртывается, буквально несколько команд.

Вот такой вот умопомрачительный гайд получился.

Что делать дальше? Пробовать!!!!!!!!!!! Просто бери и применяй все методы из данного гайда. 80-90% описанных инструментов не требуют никаких финансовых затрат, развернув всё локально.

Статью подготовил твой проводник в мир AI — Пироман 17

В своём телеграм-канале пишу про то, как строю свою AI систему, как при помощи неё выношу рынок, а также рассказываю про билдинг своего стартапа на стыке web3 и AI. Выведем снг в авангард AI движа вместе.

Подписывайся на PYRO17