Идея «поднять свой RAG в локальной инфраструктуре» ещё пару лет назад звучала как план выходного дня для энтузиаста, вооружённого Docker’ом, энциклопедией по трансформерам и бескрайним терпением. Сегодня же локальные стек-модели уверенно стучатся в дверь корпораций, где приватность стоит выше удобства, а каждое API-обращение к OpenAI или Anthropic превращается в юридическую головную боль.
Команда Skald решилась на эксперимент: собрать полностью локальный стек по генерации, дополненная поиском (Retrieval-Augmented Generation - RAG) на чистом open-source — и проверить, насколько он конкурентоспособен по сравнению с проприетарными сервисами. Результат получился парадоксальным: всё разворачивается за 8 минут, работает, отвечает, но скорее напоминает спортивный автомобиль, пересевший на грунтовку — едет уверенно, но грёбка ощущается.
Разберёмся, почему.
🔧 Локальный RAG как он есть: инженерный взгляд
Skald собрали минимальный, но функциональный tech stack:
- 🗄️ Postgres + pgvector — векторное хранилище без лишних сервисов
- 🧬 Sentence Transformers / BGE — эмбеддинги (английские и многоязычные)
- 📄 Docling — парсинг PDF/PPT/доков (фактически стандарт отрасли)
- 🧠 GPT-OSS 20B — локальная LLM поверх llama.cpp
- 🔁 Cross-encoder reranker — фильтрация релевантных кандидатов
И здесь проявилась ключевая философия подхода Skald: «не добавлять сервис, если можно донастроить Postgres». Многие инженеры считают pgvector «контроверсионным» выбором, но в мире компаний, где каждый лишний компонент = новая бумажная проверка, это решение абсолютно рациональное.
Технически это RAG без лишнего веса: легко портируется, легко деплоится, и самое главное — полностью автономен.
🚀 Почему локальные RAG-системы вообще нужны
Здесь речь не о моде на локальном развертывании (self-hosted). Причины — глубже.
- 🛡️ Законы и регуляции — от GDPR до внутренних compliance-правил
- 🔒 Air-gapped инфраструктуры — оборонка, финтех, гос-сектор
- 🧩 Нестандартные доменные данные — которые нельзя отдавать в API
- ⚙️ Контроль над LLM-пайплайном — возможность оптимизировать каждый этап
По сути, если ваш продукт — это не игрушки, а реальный корпоративный стек, локальный RAG — это не желание, а необходимость.
📊 Бенчмарки: где локальный стек сияет, а где — пасует
В статье Skald приводят сравнение трёх конфигураций.
И здесь самое важное — не абсолютные числа, а характер ошибок.
🟢 1. Claude + Voyage (облако)
Средняя оценка: 9.45/10
Почти идеальная точность. Frontier-LLM просто вытягивает всё, что бросают.
🟡 2. GPT-OSS 20B через API
Средняя оценка: 9.18/10
Открытая модель справляется удивительно хорошо.
Видно, что open-source LLM догоняют облачных конкурентов.
🟠 3. Полностью локальный стек
Средняя оценка: 7.10–8.63/10
И здесь начинают проявляться ограничения:
- 🌐 Проблемы с неанглийскими запросами
(англоязычные ST-модели просто не знают, что делать с португальским) - 🧩 Сложности с агрегацией контекста
(слияние фактов из 10+ документов всё ещё больное место OSS-моделей) - 🌀 Нечёткие вопросы сбивают эмбеддинги
- 🏎️ Многоязычные модели оказываются ощутимо медленнее
Но самое важное: точечные запросы локальный стек решает отлично.
Проблемы начинаются только там, где облачные модели исторически сильнее — в сложных reasoning-задачах.
🧠 Почему локальный RAG пока слабее — и что с этим делать
Моё мнение простое: открытые модели пока играют в разных весовых категориях с Claude и GPT-4.1/5.x не из-за качества генерации, а из-за ограничений на этапе извлечения контекста.
Вот где локальный RAG страдает:
- 🧵 Chunking: плохой разрез документа ломает смысл
- 🗃️ Vector search: вектор близкий, а смысл другой
- 🔍 Reranker: cross-encoder двигается медленно
- 📚 Multi-document reasoning: это навык frontier-LLM, а не OSS
Но хорошая новость: это решаемо.
Текущие тренды:
- Эмбеддинги становятся больше, глубже и многоязычнее
- Cross-encoder'ы оптимизируются под GPU/CPU
- Появляются гибридные методы: graph-RAG, agentive-RAG
- Open-source LLM активно учатся «дотягивать» разбросанные куски знаний
Через 12–18 месяцев пропасть между OSS и API-моделями будет не такой глубокой.
🔥 Моё видение: локальный RAG должен стать «инструментом первого выбора»
Сегодня компании выбирают облако по одной причине: простота.
Но по мере того как появляются:
- лаконичные фреймворки (пример: Skald)
- LLM уровня GPT-OSS 20B
- универсальные парсеры (Docling)
- мощные OSS-эмбеддинги
локальный стек превращается из «хака на коленке» в серьёзный инженерный продукт.
А теперь главное: локальный RAG даёт вам то, чего никогда не даст облако.
- 💼 юридическую безопасность
- 🧬 контроль над моделью
- 📦 детерминизм и повторяемость
- 🔍 наблюдаемость всего пайплайна
- 🛠️ возможность тонкой оптимизации под домен
Я уверен, что через пару лет локальный RAG станет стандартом для промышленных ИИ, так же как локальный Git когда-то вытеснил размещение кода на общих серверах.
📎 Источники
🔗 Новость
https://blog.yakkomajuri.com/blog/local-rag