RAG для начинающих: база знаний из PDF на n8n и Ollama — 2026

RAG (Retrieval-Augmented Generation, «генерация с подтягиванием из базы») — это способ заставить нейросеть отвечать не «из головы», а по вашим файлам: инструкциям, регламентам, PDF-каталогам, заметкам команды. Модель сначала находит релевантные куски текста в хранилище, потом формулирует ответ с опорой на них.

Если вы уже умеете собирать workflow в n8n и поднимали Ollama локально, RAG — логичный следующий шаг после простых цепочек «запрос → LLM → ответ». Этот лонгрид для тех, кто ищет rag для начинающих и хочет связку langchain n8n без ухода в Python: документы → эмбеддинги → локальная модель → ответы в Telegram. Базовый маршрут по n8n и no-code автоматизациям — в pillar-гайде «n8n для начинающих: автоматизация и ИИ-агенты»; установку Ollama и выбор модели мы не дублируем — она в «Нейросети для начинающих».

Я собрал материал как практик автоматизаций: через один рабочий кейс «10 PDF → бот в Telegram», а не через академическое определение векторной алгебры. RAG — нишевый, но быстро растущий тех-запрос: его ищут после освоения n8n, когда чат-бот начинает «выдумывать» там, где нужны точные цитаты из ваших документов.

RAG за 30 секунд: зачем, когда нужен, чем не заменяет fine-tuning

RAG для начинающих можно свести к трём шагам:

1. Индексация. Документы режут на фрагменты (чанки), каждый фрагмент превращают в числовой вектор (эмбеддинг) и кладут в векторное хранилище.
2. Поиск. Вопрос пользователя тоже превращают в вектор и находят ближайшие по смыслу фрагменты из базы.
3. Генерация. Найденные фрагменты подставляют в промпт локальной или облачной LLM: «отвечай только на основе этого контекста».

Зачем это нужно, если ChatGPT «и так умный»? Три практичные причины:

• Свои данные. Внутренние регламенты, прайсы, техдокументация — их нет в обучении публичной модели или они устарели.
• Контроль источника. Можно показать пользователю, из какого PDF взята цитата — меньше слепого доверия.
• Обновление без переобучения. Добавили новый файл — переиндексировали. Fine-tuning на каждое изменение не нужен.

Чем RAG не заменяет fine-tuning (дообучение модели на ваших примерах):

• Fine-tuning меняет «стиль и поведение» модели — тон, формат JSON, доменный сленг. RAG подтягивает факты извне, но не переучивает модель говорить иначе.
• Fine-tuning дороже и дольше на старте; RAG быстрее запускается на no-code стеке.
• RAG не спасает, если в документах дыры или противоречия — модель их честно подтянет и может запутаться.

Рабочая формула: fine-tuning — когда нужен стабильный формат и «характер» ответа; RAG — когда нужны актуальные факты из конкретных файлов. На практике их иногда комбинируют, но новичку достаточно освоить RAG на n8n + Ollama.

Когда RAG, а когда нет

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

Сценарий	RAG?	Почему	Альтернатива
Ответы по внутренним PDF, регламентам, Wiki	Да	Объём больше контекстного окна; факты должны быть из ваших файлов	RAG на n8n + Ollama
FAQ по продукту с частыми обновлениями	Да	База меняется — проще переиндексировать, чем переобучать	RAG + ручная проверка новых документов
Onboarding новых сотрудников по документам компании	Да	Много разрозненных источников; нужен поиск по смыслу	RAG + ссылки на исходный файл в ответе
Креатив: посты, слоганы, идеи	Нет	Нужна фантазия модели, не цитирование PDF	Обычный промпт в LLM
Актуальные цены, остатки, курс валют	Нет	Данные живут в API/CRM, статичный индекс устареет за часы	n8n → HTTP к API → LLM форматирует
Классификация писем по теме	Обычно нет	Задача на метку, не на цитату из базы знаний	Один промпт + JSON в n8n
Юридически значимые ответы без эксперта	Осторожно	RAG снижает выдумки, но не заменяет юриста	RAG + обязательный disclaimer + ревью человека
Математика, расчёты	Нет	LLM ошибается в цифрах; документ не калькулятор	Code-нода или калькулятор в workflow
Единый стиль бренда во всех ответах	Частично	RAG даёт факты; стиль — зона промпта или fine-tuning	Системный промпт + при необходимости fine-tune

Таблица — эвристика для старта, не юридическая классификация. Если сомневаетесь, начните с одного узкого кейса (например, «ответы по 10 PDF отдела») и замерьте качество на 20 реальных вопросах.

Три коротких факта, которые часто путают:

• RAG не гарантирует нулевые галлюцинации — модель может «додумать» связку между фрагментами.
• RAG не заменяет полнотекстовый поиск по ключевым словам: он ищет по смыслу, что удобно для перефразированных вопросов.
• Для 3-5 страниц текста иногда хватит вставить весь документ в промпт без RAG — не усложняйте раньше времени.

Стек для новичка: Ollama + n8n + LangChain как опция

Минимальный стек для локального RAG без облачных API:

• Ollama — две роли: модель для эмбеддингов (превращает текст в вектор) и модель для ответов (чат). Каталог моделей — на ollama.com/library; ставите через ollama pull без привязки к конкретной версии в этом гайде.
• n8n (self-hosted) — визуальная сборка двух workflow: «индексация PDF» и «вопрос → ответ». Подробности установки — в гайде по n8n.
• Векторное хранилище — для первых тестов хватит встроенного Simple Vector Store в n8n (в памяти процесса); для постоянной базы — Qdrant, Pinecone или pgvector на VPS. Выбор зависит от объёма и того, переживёт ли индекс перезапуск контейнера.
• LangChain — фреймворк на Python/JS для RAG-пайплайнов. В связке langchain n8n он не обязателен: часть AI-нод n8n уже использует LangChain-примитивы под капотом, но вы собираете сценарий на канвасе, а не в IDE. Отдельный LangChain имеет смысл, когда no-code упирается в кастомный retriever или сложную логику ветвлений.

Что должно быть готово до RAG (чек-лист входа):

1. Ollama запущена, в n8n из той же сети доступен endpoint http://host:11434/v1 (как для обычного чата — см. стартовый гайд).
2. n8n self-hosted с LangChain AI-нодами из коробки (актуальный список — docs.n8n.io).
3. Папка с PDF или другим текстом для теста (5-10 файлов достаточно для первого вечера).
4. Telegram-бот для приёма вопросов (опционально, но удобно для демо).

Железо: эмбеддинги легче чата, но 10 PDF среднего размера на слабом ноутбуке могут индексироваться несколько минут. Для комфортного локального RAG разумно закладывать 16 GB RAM на рабочей машине или вынести Ollama на VPS с 8+ GB — точные цифры зависят от выбранных моделей.

Пошаговый кейс: 10 PDF → ответы в Telegram (low-code)

Цель кейса: внутренняя «мини-Wikipedia» по десяти PDF (инструкции, описания продуктов, регламент) — сотрудник пишет вопрос в Telegram, бот отвечает с опорой на документы. Кода нет; только n8n + Ollama.

Часть 1. Индексация (один раз или по расписанию)

1. Триггер. Manual Trigger для первого прогона или Schedule «раз в ночь» + Read/Write Files из папки с PDF на сервере.
2. Извлечение текста. Нода чтения PDF (Extract from File или community-нода под PDF) — на выходе plain text.
3. Метаданные. К каждому фрагменту добавьте имя файла и номер страницы (поля в JSON) — без этого потом непонятно, откуда цитата.
4. Чанкинг. Text Splitter: ориентир 400-800 символов с перекрытием 50-100 символов между чанками, чтобы не резать предложения посередине. Слишком мелкие чанки теряют контекст; слишком крупные — «размывают» поиск.
5. Эмбеддинги через Ollama. Sub-нода Embeddings Ollama с моделью из каталога (например, nomic-embed-text — актуальный тег на ollama.com/library). Если native-нода в вашей версии n8n падает, fallback — Embeddings OpenAI с Base URL http://host:11434/v1 и явным размером вектора (768 для nomic-embed-text).
6. Запись в Vector Store. Insert Documents в Simple Vector Store (тест) или Qdrant/Pinecone (прод). Отдельный workflow — только индексация; не смешивайте с ответами в одной «каше» на первом проходе.

После прогона проверьте: в store лежит порядка сотен записей для 10 PDF (зависит от объёма). Если 0 — смотрите лог каждой ноды: чаще всего PDF пустой скан без OCR или Splitter отдал пустые строки.

Часть 2. Ответ на вопрос (каждый запрос пользователя)

1. Триггер Telegram. On message → текст вопроса в переменную.
2. Эмбеддинг вопроса. Тот же Ollama embeddings endpoint, та же модель, что при индексации (иначе поиск ломается).
3. Retrieve. Vector Store Retrieve: top-k = 3-5 фрагментов, similarity threshold подберите экспериментально (слишком низкий порог тащит мусор, слишком высокий — «не знаю» на нормальных вопросах).
4. Промпт. Системная инструкция жёсткая: «Отвечай только на основе CONTEXT. Если ответа нет в CONTEXT — скажи «В документах этого нет» и не выдумывай. В конце укажи имя файла из metadata.»
5. LLM. Ollama Chat через OpenAI-совместимую ноду: CONTEXT = склеенные чанки, USER = вопрос из Telegram.
6. Ответ. Send Message в Telegram. Для важных тем добавьте ветку «если confidence низкий → переслать админу».

Это и есть практическая связка PDF → Ollama → n8n: PDF не «загружаются в модель» целиком, а живут во внешнем индексе; Ollama делает и поисковые векторы, и финальный текст; n8n оркестрирует шаги и доставку в мессенджер.

Чек-лист после первого запуска

• Задайте 10 вопросов, ответы на которые точно есть в PDF — засеките, сколько верных.
• Задайте 3 вопроса вне базы — бот должен честно отказать, а не фантазировать.
• Добавьте 11-й PDF и убедитесь, что переиндексация подхватывает новый файл.
• Зафиксируйте в заметке: модель эмбеддингов, модель чата, размер чанка, k retriever — без этого через месяц не воспроизвести.

LangChain vs n8n: где что проще

LangChain (и родственные фреймворки) — это код: вы явно описываете Document Loader, Text Splitter, VectorStore, Retriever, Chain. Плюсы: гибкость, кастомные retriever’ы (HyDE, rerank, multi-query), unit-тесты. Минусы: нужен Python или TypeScript, деплой, отладка — порог выше, чем у no-code.

n8n — это оркестрация и интеграции: Telegram, почта, CRM, cron, webhook в одном workflow. RAG в n8n собирается из готовых нод; сложные ветки видны на канвасе. Плюсы: быстрый MVP, self-hosted, связка с Ollama без отправки PDF в облако. Минусы: тонкая настройка retriever’а иногда упирается в потолок no-code — тогда один узкий шаг выносят в микросервис (Cursor + Python) и вызывают HTTP-нодой из n8n.

Критерий	LangChain (код)	n8n (low-code)
Порог входа	Выше: окружение, зависимости, деплой	Ниже при уже знакомом n8n
Скорость MVP «PDF → Telegram»	1-3 дня у новичка в коде	Один вечер по шаблону нод
Интеграции с SaaS	Пишете обёртки или используете SDK	Готовые ноды из коробки
Кастомный retriever / rerank	Полный контроль	Ограничено; кастом через Code-ноду или внешний API
Приватность PDF	Да, если self-hosted	Да, Ollama + n8n на своём сервере
Сопровождение командой без dev	Сложнее	Проще: workflow виден на канвасе

Практичная стратегия для rag для начинающих: соберите первую базу в n8n. Если упёрлись в один шаг (например, rerank или гибрид BM25 + вектор) — вынесите только его в LangChain-микросервис, не переписывая весь пайплайн. Подробнее про агентные паттерны поверх RAG — в материалах тех-кластера автоматизации и лонгриде про Hermes Agent.

Типичные ошибки: чанки, галлюцинации, приватность

RAG кажется «магией», пока не столкнёшься с теми же граблями, что и в продакшене у команд с LangChain.

Чанки и индекс

• Резка без структуры. Таблицы и списки из PDF ломаются — модель получает обрывки. Для важных документов проверяйте чанки глазами после Splitter.
• Разные модели эмбеддингов. Индексировали одной, ищете другой — similarity бессмысленна. Одна пара моделей на весь проект.
• Нет метаданных. Без имени файла пользователь не проверит ответ. Всегда прокидывайте source в промпт и в ответ.
• Забыли переиндексировать. PDF обновился, а в store старая версия — RAG уверенно цитирует устаревшее.

Галлюцинации при RAG

• Пустой retriever. Порог similarity слишком высокий, контекст не пришёл — модель всё равно «отвечает». Добавьте ветку: если chunks.length = 0 → фиксированный отказ.
• Слабый системный промпт. «Помоги пользователю» без запрета на выдумки — RAG превращается в обычный чат.
• Слишком много чанков в контексте. k=15 с разными темами путает модель. Начните с k=3-5.
• Нет проверки на прод. Ответы клиентам или в compliance — только с human-in-the-loop или жёстким шаблоном.

Приватность и безопасность

• PDF в облачный OpenAI без DPA — утечка коммерческой тайны. Для внутренних документов — Ollama на своём железе или VPS в вашей юрисдикции.
• Vector store в облаке без шифрования — эмбеддинги обратимо не расшифровать «как текст», но по ним можно делать inference. Для чувствительных данных — self-hosted Qdrant/pgvector.
• Telegram-бот без авторизации — любой задаёт вопросы по вашей базе. Ограничьте chat_id или добавьте пароль-команду.
• Ключи API в нодах — только Credentials n8n, не скриншоты workflow в чат.

Куда дальше

Когда MVP RAG отвечает на десяток тестовых вопросов, маршрут расходится так:

• Назад к базе n8n. Если workflow ещё «шатается» — вернитесь к pillar по автоматизации: триггеры, ошибки, Ollama в HTTP-нодах.
• Назад к Ollama. Выбор модели под ваше железо — в гайде для начинающих.
• Вглубь агентов. RAG часто становится «инструментом» у AI Agent в n8n: модель сама решает, когда искать в базе, когда вызвать API. Следующий уровень после линейного retrieve → chat.
• Обучение под ваш кейс. Курсы и наставничество по n8n, RAG и локальным моделям — направление «ИИ-агенты и автоматизация» на странице обучения.
• Смежные лонгриды. Следующий уровень после RAG — Hermes Agent (self-hosted агент с терминалом и Telegram); дальше — мульти-агентные системы вроде CrewAI. Они опираются на уверенный n8n + RAG, а не заменяют этот гайд.

Не обязательно идти во все ветки сразу. Для фрилансера с базой PDF-курсов логично довести Telegram-бота до 50 реальных вопросов и только потом усложнять retriever.

FAQ: RAG, LangChain и n8n

Вывод эксперта

RAG для начинающих — не про «подключить волшебную кнопку», а про дисциплину: нормальные чанки, одна пара моделей эмбеддингов и чата, жёсткий промпт «только из контекста», переиндексация при обновлении PDF. На стеке Ollama + n8n это реально собрать за вечер, если n8n и локальная модель у вас уже стоят.

Один шаг, который стоит сделать сегодня: возьмите три PDF из реальной работы, прогоните индексацию, задайте пять вопросов в Telegram и запишите, где бот ошибся. LangChain, rerank и агентные паттерны — второй месяц; первый — стабильный retrieve → answer. Карта no-code автоматизаций — в гайде по n8n; база по нейросетям — в стартовом pillar.