Соберите личный RAG: чат со своими документами (без кода)

RAG — Retrieval-Augmented Generation — это технический термин для «пусть ИИ отвечает на мои вопросы по моим документам». До 2024 года это была в основном разработческая возможность. К 2026 году появились отличные варианты без кода, которые настраиваются за пятнадцать минут и дают результат, конкурентный с кастомными системами.

В этой статье — три no-code-пути к личному RAG, когда какой использовать, и решения в дизайне, которые отличают полезный RAG от раздражающего. Смысл не в том, чтобы «загрузить всё». Смысл в ограниченном, привязанном к источникам ассистенте, ответы которого можно проверить.

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

Что именно значит «личный RAG»

Личный RAG — это чат-интерфейс, где:

1. Вы загружаете свои документы (PDF, Word, текст, веб-страницы, транскрипты).
2. Система индексирует их так, чтобы по ним можно было искать.
3. Когда вы задаёте вопрос, система достаёт самые релевантные фрагменты ваших документов и подаёт их LLM вместе с вашим вопросом.
4. LLM даёт ответ, обоснованный вашими документами, с цитированиями.

Преимущество перед обычным ChatGPT или Claude: модель использует именно ваши документы, а не свои обучающие данные. Это значит:

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

Ограничение: всё, чего нет в ваших документах, — вне области. Система либо скажет «у меня нет такой информации», либо — хуже — перейдёт к общим знаниям и может нагаллюцинировать.

Три no-code-пути

Для 90% сценариев личного RAG в 2026 году правильный ответ — один из этих трёх:

Путь 1: NotebookLM (самый простой)

Уже разбирался в нашей статье для начинающих про NotebookLM. Освежим:

• Создайте notebook на notebooklm.google.com.
• Загрузите до ~50 источников (PDF, документы, веб-страницы, YouTube, аудио).
• Общайтесь с notebook — каждый ответ привязан к источникам и процитирован.
• Audio Overview генерирует резюме в формате подкаста.

Сильные стороны: самая простая настройка, лучшее заземление, цитированные ответы, audio overview реально полезен.

Ограничения: ограниченные интеграции (нет автосинка с вашими документами, при изменении источников — ручная перезагрузка). Лимиты на число источников. Не встраивается в другие места.

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

Путь 2: Claude Projects (самый гибкий)

Фича Projects в Claude позволяет создать папку с:

• Кастомными инструкциями по поведению проекта.
• Файлами знаний (загруженными документами, на которые ассистент может ссылаться).
• Всеми разговорами, которые вы ведёте внутри проекта.

Сильные стороны: качество диалога выше, чем у NotebookLM (сильная сторона Claude — письмо), более гибкая настройка поведения, удобнее для постоянной работы.

Ограничения: меньше поддерживаемых типов источников (в основном текст, PDF, код). Нет нативного веб-фетчинга. При изменении документов — ручная перезагрузка.

Лучше всего для: «базы знаний проекта», к которой вы возвращаетесь регулярно. Личные исследовательские области. Domain-specific-ассистенты (юридический, технический, корпоративные знания).

Путь 3: low-code RAG-пайплайн (самый мощный)

Кастомная конфигурация на платформе рабочих процессов без кода (n8n, Make) или инструменте с небольшим количеством кода (Langflow, Flowise). Сам LangChain — это фреймворк для кода, а не инструмент без кода, но Langflow и Flowise лежат поверх похожих блоков с визуальным редактором. В любом случае пайплайн RAG вы собираете сами:

1. Ingestion: автоматический синк из ваших источников (Google Drive, Notion, папки, базы данных).
2. Чанкинг и эмбеддинг: разбиение документов, создание векторных эмбеддингов.
3. Векторное хранилище: Pinecone, Qdrant, Weaviate или Chroma на собственном сервере.
4. Извлечение: семантический поиск возвращает релевантные чанки под каждый запрос.
5. Генерация: чанки плюс запрос уходят в LLM.
6. Интерфейс: чат через вебхук в n8n с фронтендом или через инструмент вроде Open WebUI.

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

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

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

Как выбрать из трёх

Правило выбора:

NotebookLM, если: источники стабильны, нужно, чтобы заработало за 15 минут, сценарий — обучение или анализ (а не встраивание в другие воркфлоу).

Claude Projects, если: нужен постоянный ассистент для длинной предметной области (например, «всё, что связано с европейским налоговым комплаенсом»), вы цените качество диалога и уже пользуетесь Claude.

Кастомная сборка n8n/LangChain, если: источники часто меняются, нужен автосинк, вы хотите встроить чат в другой инструмент или приложение, либо вы строите это для команды.

Пошагово: сборка на Claude Projects

NotebookLM мы разбирали отдельно — пройдёмся по сборке RAG на Claude Projects, это правильная середина для большинства intermediate-пользователей.

Шаг 1: создайте проект. В claude.ai кликните Projects → New Project. Назовите по предметной области (например, «EU Tax Compliance Assistant»).

Шаг 2: напишите инструкции. Это место, где ценность концентрируется. Надёжный шаблон:

Вы — ассистент в области [предметная область] для [ваша роль/команда]. Ваша задача — отвечать на вопросы, опираясь на документы, которые я загрузил как файлы знаний.

Всегда:
- Указывайте конкретный документ и раздел, из которого взят ответ.
- Помечайте всё, что вы выводите сами, меткой [мой вывод].
- Говорите «У меня нет такой информации», когда файлы знаний не покрывают вопрос, — никогда не выдумывайте и не переходите к общим знаниям, если я явно об этом не попрошу.

Когда я задаю:
- Фактический вопрос: цитируйте конкретный фрагмент.
- Вопрос «как сделать»: давайте пошаговый ответ со ссылками на источники.
- Сравнение: где это помогает, стройте таблицу.
- Открытый вопрос: структурируйте ответ по понятным разделам.

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

Если документ устарел (старше 2 лет): упоминайте это при цитировании.

Шаг 3: загрузите документы. Нажмите «Add knowledge» и загрузите PDF, Word, текстовые файлы. До нескольких десятков документов работают хорошо; больше — качество просаживается.

Несколько практик:

• Предпочитайте чистые текстовые PDF сканам.
• Разбивайте очень длинные PDF, если они охватывают несколько тем. Извлечение работает лучше с сфокусированными документами.
• Тегируйте в имени файла. «2026-04-tax-guidance-Estonia.pdf» лучше, чем «document1.pdf». Claude умеет использовать контекст из имени файла.
• Избегайте дубликатов. Три версии одного и того же документа путают извлечение.

Шаг 4: тестируйте. Задайте вопрос, ответ на который вы знаете. Проверьте, что ответ заземлён в нужном документе и его цитирует. Если нет — правьте инструкции или документы.

Шаг 5: пользуйтесь. Каждый разговор, который вы начинаете внутри проекта, использует документы как основу. Разговоры сохраняются внутри проекта, к ним можно возвращаться.

Перед добавлением источников задайте по каждому документу вопросы:

1. Кто владелец этого документа?
2. Есть ли там персональные данные, клиентские данные, учётные данные, договоры, медицинские данные или конфиденциальные цены?
3. Достаточно ли документ актуален, чтобы по нему отвечать?
4. Это авторитетный источник или черновая заметка/мнение?
5. Нужно ли вынести этот источник в отдельный RAG, потому что аудитория или права доступа отличаются?

Сопутствующий шаблон аудита источников из этой статьи даёт лёгкую таблицу для такой проверки.

Держите границу прав явной

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

Если две аудитории не должны видеть один и тот же источник, они не должны делить один RAG. В no-code-инструменте отдельный проект или notebook обычно является самой простой моделью прав.

Разобранный пример: личный юридический ассистент

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

Источники:

• Официальный «Закон о трудовых договорах» Эстонии (PDF из Riigi Teataja).
• Полный текст GDPR (PDF из EUR-Lex).
• Руководства ICO и Эстонской инспекции по защите данных.
• Ваши прошлые договоры и политики.
• Несколько качественных юридических блог-постов с разбором типовых вопросов.

Инструкции (в проекте):

Вы — ассистент по юридическому комплаенсу для эстонской B2B SaaS-компании на 50 человек. Ваша задача — отвечать на вопросы, опираясь на эстонское трудовое право, GDPR и наши внутренние политики.

Всегда:
- Указывайте конкретную статью, раздел или документ, на который ссылаетесь.
- Помечайте всё, что вы выводите или экстраполируете, меткой [мой вывод].
- В вопросах по GDPR разделяйте жёсткие требования и хорошие практики.
- В вопросах эстонского трудового права по умолчанию исходите из эстонского законодательства, если я не спрашиваю про другую юрисдикцию.

Всегда завершайте фразой:
«Это информация, а не юридическая консультация. За обязывающими толкованиями обращайтесь к квалифицированному эстонскому юристу по трудовому праву».

Если вопрос стоит показать юристу: скажите об этом явно.

Теперь у вас есть личный ассистент, отвечающий на вопросы по трудовому праву и GDPR, заземлённый в реальных исходных документах. Это не замена юристу — но для тех 80% вопросов, у которых есть чёткие ответы в источниках, это существенно быстрее, чем самому копаться в нормативке.

Типичные ловушки и как их избегать

Несколько конкретных капканов в личном RAG, на которые часто попадаются:

Ловушка 1: устаревшие документы. Вы загрузили версию регуляции от 2023 года, а в 2026 году она уже изменилась. RAG добросовестно отвечает по устаревшему материалу.

Решение: датируйте документы в имени файла. Периодически ревьюйте и заменяйте. Для часто обновляющихся источников рассмотрите вариант RAG на платформе рабочих процессов с автосинхронизацией.

Ловушка 2: низкокачественные источники. Вы загрузили SEO-спам, который выглядит авторитетно, но содержит ошибки. RAG отвечает по нему.

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

Ловушка 3: расползание области. RAG был про «эстонское трудовое право», а вы добавили туда же общие HR-статьи, советы по переговорам и пару шаблонов договоров. Теперь извлечение мутнее, а ответы смешивают юридические источники с мнениями.

Решение: один проект — одна область. Делайте отдельные проекты под отдельные области.

Ловушка 4: вопросы вне корпуса. Пользователи (или вы) задают вопросы, которые документы не покрывают. Модель скатывается на обучающие данные и галлюцинирует.

Решение: жёсткие инструкции («не выдумывай — говори, что такой информации у меня нет»). Тестируйте краевые случаи. Подумайте о настройке модели на отказ от опоры на общие знания.

Ловушка 5: чанкинг имеет значение даже в no-code. Современные no-code-инструменты обрабатывают чанкинг автоматически, но если ваши документы свёрстаны странно (таблицы, колонки, блоки кода), качество извлечения падает.

Решение: предобрабатывайте, где можно. Конвертируйте сложные PDF в чистый Markdown до загрузки. Разбивайте очень длинные документы на сфокусированные секции.

Тестируйте отказ, а не только извлечение

Большинство людей тестирует RAG вопросами, на которые источники точно отвечают. Это проверяет только happy path. Тестируйте и вопросы, на которые корпус не должен отвечать.

Эти тесты отличают помощника по документам от уверенного генератора ответов с папкой документов поблизости.

За пределами no-code: когда выпускаться

Наступает момент, когда no-code RAG упирается в свои пределы и нужно выпускаться к более серьёзной конфигурации. Типичные триггеры:

Объём источников. У вас 500+ документов, и базовые механизмы загрузки уже просаживают качество.

Автосинк. Документы постоянно обновляются (страницы Notion, Google Docs, сообщения Slack, внутренние вики), и ручная перезагрузка нежизнеспособна.

Встроенный чат. Вы хотите, чтобы пользователи общались с RAG внутри вашего приложения, в Slack, на сайте — а не в интерфейсе Claude.

Специфичные требования к извлечению. Нужна фильтрация по метаданным (отдел, тип документа, дата), гибридный поиск (семантический + ключевой) или переранжирование результатов.

Оптимизация стоимости. Использование такое, что важно контролировать токены.

Для любого из этих случаев нужен кастомный RAG. Следующий шаг — один из:

• n8n с нодами векторных хранилищ. No-code с серьёзным контролем.
• LangChain, LlamaIndex или Haystack. Python-библиотеки. Реальный код, но хорошо документированный.
• Хостинговый RAG-сервис (Vectara, Unstructured, Ragie, Pinecone в виде RAG-as-a-service). Меньше контроля, меньше работы.

У нас есть отдельная продвинутая статья по продакшен-RAG. Сейчас — просто распознавайте порог и переходите, когда упрётесь.

Несколько паттернов, которые складываются с процентами

Привычки, делающие личный RAG полезнее со временем:

Курируйте, не сваливайте. Соблазн — загрузить всё. Реальность — больше не значит лучше; лучше значит лучше. Три отличных источника отвечают на большинство вопросов; 50 посредственных отвечают на них хуже.

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

Стройте маленькие, отдельные RAG под отдельные предметные области. Один RAG под «личные юридические вопросы», другой — под «продуктовые знания компании», третий — под «материалы для аспирантуры». Чем меньше область, тем лучше ответы.

Периодически перетестируйте. Раз в месяц задавайте RAG пять вопросов, которые тестировали в самом начале. Если качество ушло (из-за новых документов или изменения модели) — заметьте и обновитесь.

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

Заметка про стоимость

NotebookLM бесплатен в рамках щедрых лимитов. Claude Projects работают через подписку Claude Pro / Max (примерно $20–200 в месяц, в зависимости от тарифа). Кастомная сборка на n8n / векторном хранилище стоит $10–100 в месяц в зависимости от объёма плюс ваше время на сборку и поддержку.

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

Какую сборку выбрать

Личный RAG в 2026 году — уже не разработческая привилегия. NotebookLM даёт рабочий RAG за 15 минут. Claude Projects — более гибкого ассистента за 30. Кастомная сборка n8n даёт полный контроль за несколько часов.

Выбирайте подходящий под сценарий. Курируйте источники тщательно. Тюньте инструкции. Тестируйте извлечение и отказ. Итерируйте. За неделю у вас будет инструмент, который для многих задач поиска по документам заменяет ручное копание ответом со ссылками на источники, который можно проверить.

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