# Використання 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 | | --- | --- | --- | | Розуміння знань | Статичний набір документів | Пам'ять, що постійно росте | | Свіжість даних | Залежить від частоти оновлення індексу | Реальний час, запам'ятовується одразу після написання | | Спосіб запиту | Активний пошук | Природна розмова | | Відношення до творчості | Пошук і творчість розділені | Переплетені — редагування є оновленням пам'яті | | Типовий сценарій | Корпоративний пошук, Q&A з політик | Особисте управління знаннями, другий мозок | **Дві парадигми не замінюють одна одну. Вони служать абсолютно різним сценаріям.** Як пошукова система та особистий помічник. --- ## 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)*