Инженер 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 на ноутбуке и сервисом, с которым ежедневно работают инженеры.
Эта дистанция измеряется не качеством модели, а дисциплиной работы с данными и инфраструктурой.
