RAG в offshore-индустрии: 1 ТБ данных, 4 провала и 184 евро аренды GPU — 2 июня 2026 г. в 08:00:22.518
RAG в offshore-индустрии: 1 ТБ данных, 4 провала и 184 евро аренды GPU Инженер Andros Fenollosa опубликовал подробный разбор построения внутреннего RAG-сервиса для компании из offshore-индустрии. Внутри: ▪ локальная LLM, ▪ база технической документации и проектов почти за десять лет, ▪ требование давать ответы со ссылками на первоисточники. Кейс интересен не тем, что RAG собрали, а тем, на каких этапах система ломалась и во что в итоге превратилась архитектура. Старт: стандартная связка Начальная связка выглядела стандартно: ▪ Локальная модель — Ollama ▪ Эмбеддинги — nomic-embed-text ▪ Оркестратор — LlamaIndex ▪ Язык — Python На прототипе из небольшого набора документов все работало за пару недель. Проблемы начались при столкновении с реальными данными — 1 ТБ разнородного контента без структуры: технические отчеты, регламенты, CSV, видео, симуляции, бэкапы, архивы. Провал №1: память ❌ Проблема: LlamaIndex пытался обрабатывать все подряд, включая многогигабайтные видео и файлы симуляций, загружая их в RAM как текст. ✅ Решение: агрессивный фильтр на уровне пайплайна: ▪ исключение по расширениям и паттернам имён (видео, исполняемые файлы, архивы, бэкапы, временные файлы, почтовые архивы), ▪ отказ от индексации CSV и JSON ➡ Результат: сокращение набора на 54% и стабильная обработка без переполнения памяти. Провал №2: масштаб индексации ❌ Проблема: дефолтное хранение индекса в JSON-файле на диске не выдерживало сотен гигабайт. Любой перезапуск означал переиндексацию с нуля, checkpoint-механика давала повреждённые данные. ✅ Решение: переход на выделенную векторную БД — ChromaDB поверх SQLite. Индексация превратилась из монолитного процесса в пакетный пайплайн по 150 файлов, с чекпоинтами и устойчивостью к сбоям. ➡ Результат: ▪ 738 470 векторов, ▪ 54 ГБ индекса из исходных 451 ГБ документов. Провал №3: железо ❌ Проблема: на интегрированной графике обработка 500 МБ занимала 4–5 часов. ✅ Решение: аренда виртуальной машины с NVIDIA RTX 4000 SFF Ada на 20 ГБ VRAM. ➡ Результат: ▪ полная индексация заняла от 2 до 3 недель, ▪ счет за аренду — 184 евро, ▪ после этого SQLite-файл ChromaDB просто скопировали на production-сервер. Провал №4: хранение ❌ Проблема: production-VM имела 100 ГБ диска, тогда как исходные документы занимали около 500 ГБ. ✅ Решение: ▪ оригиналы оставили в Azure Blob Storage ▪ ссылки в ответах LLM формируются через SAS-токены для прямой загрузки пользователем из облака ▪ на локальном диске остались только индекс (54 ГБ), сама модель (~10 ГБ) и легкие бэкенд и фронтенд на Flask и Streamlit Ключевой вывод автора Если исходные данные недостаточно качественные, никакая LLM не компенсирует этого в ответах. Этот тезис хорошо согласуется с практикой: в production-RAG основная инженерная работа приходится не на выбор модели или фреймворка, а на: ▪ фильтрацию источников, ▪ нормализацию форматов, ▪ устойчивый пайплайн индексации, ▪ разделение слоев хранения (векторный индекс vs оригинальные документы). Архитектурные решения здесь диктуются не возможностями LLM, а ограничениями памяти, диска, GPU и экономикой облачной аренды. Что важно вынести из кейса Кейс полезен тем, что показывает реальную дистанцию между демо-RAG на ноутбуке и сервисом, с которым ежедневно работают инженеры. Эта дистанция измеряется не качеством модели, а дисциплиной работы с данными и инфраструктурой. #кейс