# Использование RAG в качестве второго мозга: нет лучшего решения, есть только наиболее подходящий сценарий За последние два года почти все команды, работающие с большими языковыми моделями, занимались одним и тем же: добавляли RAG к своим моделям. Причина проста. У больших языковых моделей есть два врожденных недостатка — знания имеют срок годности, и они склонны к галлюцинациям. RAG призван решить обе проблемы одновременно: предоставить модели свежие внешние данные и заставить её отвечать на их основе. Так возникло распространенное заблуждение: **RAG — это технология. Выбери правильную — и победил.** Но реальность такова: RAG — это не одна технология. **RAG — это общее название класса архитектур.** Разные сценарии требуют совершенно разных архитектурных решений. Так же, как большие языковые модели имеют разное применение — легковесная модель на 4B параметров не бесполезна, она более практична в сценариях с инференсом на устройстве, низкой задержкой и низкой стоимостью, чем модель с сотнями миллиардов параметров. Модель с триллионом параметров сильна в рассуждениях, но предприятие не может себе позволить её развернуть. У каждой своё место. Такая же разница существует и между RAG-решениями. Нет абсолютно лучшего решения. Есть только наиболее подходящее для текущего сценария. **Эта статья о том: в конкретном сценарии «заметки + документы + RAG» — то есть создании второго мозга с помощью ИИ — какое решени�� является оптимальным. И почему.** --- ## I. В чем настоящая сложность RAG в 2025 году Демо RAG можно сделать за один вечер. Но проблемы, выявленные в производственной среде, сосредоточены в трех измерениях: ### Индексация — это не разовая работа, а долгосрочное бремя «Вставить все документы в векторную базу данных» звучит просто. Но на практике: при обновлении модели 10 миллионов документов нужно переобработать, что составляет около 5 миллиардов токенов, только стоимость API составит $300-650. При удалении документов в векторной базе могут остаться устаревшие записи, которые не очищаются днями. При изменении прав доступа, если индексы документов уволенного сотрудника не обновлены вовремя, возникает окно уязвимости в несколько часов. При ограничениях платформы такие инструменты, как Slack, Notion, уже ограничивают массовый сбор данных третьими сторонами. ### Задержка — это многоуровневая цепочка Каждый запрос проходит через: понимание вопроса → векторный поиск → сортировка результатов → сборка контекста → генерация ответа ИИ. Если любой из уровней замедляется, замедляется всё. Инференс LLM занимает 60-80% сквозного времени. ### Стоимость растет с объемом данных Чем больше документов, тем больше обработки. Все три звена расширяются. **Общий корень: сначала нужно построить индекс из документов, чтобы начать поиск.** Это «поисково-центричный» RAG. --- ## II. Два основных типа решений ### Решение 1: Векторная база данных + статический индекс Документы сначала нарезаются, преобразуются и помещаются в векторную базу данных. При запросе из базы ищется наиболее похожий контент. **Сильные стороны:** Огромное количество документов, статичный контент. **Слабые стороны:** Часто меняющийся контент, каждое редактирование требует перестроения индекса. ### Решение 2: Поток данных в реальном времени + событийно-ориентированный подход Изменения данных запускают обновление, индекс синхронизируется в реальном времени. **Сильные стороны:** Свежесть в секундах. **Слабые стороны:** Сложная инфраструктура, требуются кэш-слой, механизм событий, двойной слой хранения. ### Существует сценарий, который не обслуживается ни одним из двух путей Юрист готовит краткое изложение дела. 200 заметок по делу, 50 файлов с нормативными актами. Она пишет и одновременно ищет — «Как раньше аргументировалось дело о неконкуренции?» Закончив абзац, она меняет содержание и через несколько секунд снова ищет. Новый контент уже должен быть в результатах поиска. Характеристики этого сценария: **контент часто меняется** (не статическая библиотека), **поиск и создание переплетены** (пишет и ищет одновременно), **пользователь — обычный человек** (не пишет код, не понимает векторные базы), **данные и конфиденциальность — красная линия**. **Это не требование «более высокой технической сложности». Это требование «техническое решение не должно быть таким тяжелым».** --- ## III. От Search-centric к Memory-centric Основные решения предполагают, что **база знаний статична**. Запрос — это разово�� поисковое действие. Эта парадигма называется **поисково-центричный RAG (Search-centric RAG)**. Модель: база знаний = набор документов, RAG = интеллектуальный поиск. Но для создания второго мозга нужна другая парадигма. Вы каждый день пишете заметки, редактируете их, удаляете, импортируете новые документы. Знания постоянно растут и развиваются. Вы хотите, чтобы ИИ не просто «искал», а **постоянно «помнил» ваши знания и естественно вызывал их, когда нужно.** Это **памятно-центричный RAG (Memory-centric RAG)**. Модель: база знаний = постоянно развивающаяся память, RAG = естественный доступ. | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | Понимание знаний | Статический набор документов | Постоянно растущая память | | Свежесть данных | Зависит от частоты обновления индекса | В реальном времени, запомнил сразу после записи | | Способ запроса | Активный поиск | Естественный диалог | | Связь с творчеством | Поиск и создание разделены | Переплетены — редактирование = обновление памяти | | Типичный сценарий | Корпоративный поиск, ответы на политики | Управление личными знаниями, второй мозг | **Две парадигмы не заменяют друг друга. Они служат совершенно разным сценариям.** Как поисковая система и личный ассистент. --- ## IV. Какая архитектура нужна для Memory-centric RAG? Четыре требования к архитектуре: **1. Отсутствие зависимости от предварительной индексации.** Каждое редактирование требует перестроения индекса — о реальном времени не может быть и речи. Система поиска должна разделять данные с редактором — контент изменился, и следующий запрос это отражает. **2. Минимальное использование контекста.** Заметки — это конфиденциальные данные, их нельзя загружать целиком. Но ИИ должен видеть информацию, чтобы отвечать. Точка баланса: передавать только самые релевантные несколько предложений, сжатые фрагменты, удалять после передачи. **3. Использование лучших облачных моделей для генерации.** Пользователь не возится, серверная сторона видит только минимальный контекст. **4. Редактирование = обновление памяти.** Изменения немедленно входят в память, следующий запрос это отражает. --- ## V. Практика Memory-centric RAG в NoteRich ### Заметки всегда локальны, полные данные не загружаются Заметки сохраняются локально в браузере. Это не допускается (взрыв стоимости) и не должн�� быть (конфиденциальность пользователя). ### При запросе передается только минимально необходимый контекст Передаются только самые релевантные несколько предложений, сжатые фрагменты. После обработки на сервере они удаляются — не хранятся, не записываются, не используются для обучения. **Небольшая загрузка неизбежна, полная загрузка полностью предотвратима.** ### Без предварительной индексации, редактирование = память Векторная база данных не строится заранее. Система поиска уже онлайн, пока вы пишете заметки. Изменения контента отражаются в реальном времени. ### Многомерная оценка + точность до предложения + сервер без состояния Не только семантическое сходство. Возврат с точностью до предложения, дедупликация и слияние. Бэкенд не хранит, не записывает, не обучает. --- ## VI. Четыре уровня второго мозга **Первый уровень: Пам��ть.** ИИ «помнит» все заметки, которые вы когда-либо писали. **Второй уровень: Помощь в создании.** Генерация нового контента на основе старых заметок. **Третий уровень: Обратная связь в реальном времени.** Как только вы написали абзац, ИИ немедленно это воспринимает. **Четвертый уровень: Редактирование = память.** Изменение контента, созданного ИИ, немедленно входит в память. Замкнутый цикл знаний. --- ## VII. Признать границы, а затем преодолеть их ### Граница 1: Ограничения возможностей браузера Онлайн-версия полностью работает в браузере. Протестировано на десятках тысяч текстовых документов и десятках миллионов символов — очень плавно. **До нескольких сотен тысяч документов без проблем, при превышении производительность падает.** Это физическая граница браузера. Но обычные пользователи почти никогда не достигают этой границы. Если вы её достигли — у вас корпоративные потребности. В офлайн-решении та же архитектура работает на сервере, масштабируется по мере необходимости. ### Граница 2: Поддержка мультимодальности В настоящее время фокус на тексте. OCR изображений, транскрипция аудио, анализ видео — онлайн-версия ограничена вычислительной мощностью браузера. Корпоративное офлайн-развертывание может быть настроено и интегрировано на сервере. **Текстовая память — это основа, мультимодальная память — это апгрейд.** ### Граница 3: Сложные рассуждения по нескольким документам Многошаговые рассуждения — это задача этапа генерации, а не этапа поиска. Поиск занимается только «поиском», а не «выводом». NoteRich позволяет потребительским моделям достигать практических результатов с помощью высококачественного контекста. ### Граница 4: Полностью офлайн Топовые большие языковые модели не могут работать на обычных компьютерах — это физический закон. Офлайн-решение может подключаться к локальным моделям, развернутым на предприятии. --- ## VIII. Офлайн-решение Юридические фирмы, больницы, финансовые учреждения — данные ни в коем случае не должны покидать внутреннюю сеть. Офлайн-развертывание упаковывает архитектуру Memory-centric в однокомпонентный бэкенд, развертывается одним кликом, весь процесс не покидает корпоративную сеть. --- ## IX. Конечное видение **Search-centric RAG решает проблему «поиска».** Memory-centric RAG решает проблему «запоминания». Они не конкурируют. NoteRich просто сделал неск��лько более прямых выборов на пути Memory-centric RAG. **Быстро, дешево, качественно.** Позволяя обычным людям начать управлять знаниями с помощью ИИ за 30 секунд, а предприятиям — полностью доверять ему за брандмауэром. **[Попробовать NoteRich →](https://noterich.com/app/)** *Концептуальный проект с открытым исходным кодом [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*