Инженер 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 на ноутбуке и сервисом, с которым ежедневно работают инженеры.

Эта дистанция измеряется не качеством модели, а дисциплиной работы с данными и инфраструктурой.