RAG-сервис из видеолекций: пайплайн и стоимость
Рабочий RAG-сервис по видеолекциям можно собрать на сервере с 2 CPU и 4 ГБ памяти: расшифровка через Faster Whisper, нарезка на 1667 чанков, эмбеддинги text-embedding-3-small, векторная база Qdrant и генерация через gpt-4o-mini. Векторизация полутора миллионов символов обошлась меньше чем в цент. Главное архитектурное решение — не считать эмбеддинги на слабом CPU в проде.
Ниже — пайплайн нашего сервиса N-GPT по шагам, с параметрами и ценами, и то, что мы сознательно не стали делать. Схема подходит для корпоративного обучения: записи инструктажей, вебинаров и внутренних курсов превращаются в ассистента, который отвечает сотрудникам языком самих лекций.
Что такое RAG-пайплайн
RAG-пайплайн — последовательность шагов, превращающая исходные материалы в сервис вопросов и ответов: извлечение текста, нормализация, нарезка на чанки, векторизация, хранение в векторной базе, поиск и генерация ответа языковой моделью. Для видео к стандартной цепочке добавляется первый шаг — распознавание речи. Общий принцип RAG разобран в материале о том, как работает RAG для базы знаний компании.
Итоговая схема: видео → текст → чанки → эмбеддинги → Qdrant → top-k чанков → промпт → LLM → ответ.
Шаг 1. Видео в текст: Faster Whisper
Исходник — подборка видеолекций по машинному обучению. Субтитры извлекались open-source-моделью Faster Whisper: по соотношению ресурсов и качества она оказалась лучшей, нормально работает даже на CPU и не требует тонкой настройки. Через несколько минут после установки она готова к работе.
Результат шага — посекундная транскрипция каждой лекции в текстовых файлах.
Шаг 2. Нормализация
Тексты приводятся к единому формату, чтобы нарезка вела себя одинаково. На базовой версии мы не усложняли: удалили таймкоды, склеили текст в сплошную строку без переносов и убрали технические символы. Точки и запятые оставили — дальше они нужны для нарезки по концам предложений.
Шаг 3. Нарезка на чанки
| Параметр | Значение |
|---|---|
| Итоговое число чанков | 1667 |
| Максимальный размер чанка | 1600 символов |
| Минимальный размер | 1000 символов |
| Правило разреза | последняя точка до границы в 1600 символов |
| Перекрытие | 250 символов |
В расшифровках лекций точка почти всегда означает конец предложения, поэтому резать по ней надёжно. Для базовой версии это удачная отправная точка. Как выбирать размер и перекрытие под другие типы документов, разобрано в материале о чанковании в RAG.
Шаг 4. Эмбеддинги: почему мы ушли с локальной модели
Первой попыткой была open-source-модель bge-m3, запущенная локально. Чанки векторизовались, но выяснилась архитектурная ошибка: в проде эмбеддинг нужно считать для каждого вопроса пользователя, а на слабом CPU bge-m3 работает медленно. Сервис тормозил бы на каждом запросе.
Решение — эмбеддинги по API через OpenRouter, модель text-embedding-3-small от OpenAI.
| Критерий | bge-m3 на локальном CPU | text-embedding-3-small по API |
|---|---|---|
| Скорость | Медленно, узкое место на каждом запросе | В десятки раз быстрее |
| Цена | Бесплатно, но нужен мощный сервер | 0,00002 доллара за 1000 токенов |
| Векторизация всего корпуса | — | 1,5 млн символов меньше чем за 1 цент |
| Требования к серверу | Высокие | Хватает 2 CPU и 4 ГБ памяти |
Вывод для предприятия: закрытый контур с локальными моделями возможен, но под него закладывается GPU или мощный CPU — это считается в совокупной стоимости владения, а не выясняется после запуска. Подобрать вычислитель под локальный инференс можно в каталоге вычислителей и AI-модулей.
Шаги 5–6. Qdrant и поиск
Векторная база — Qdrant, без экспериментов. Поиск — косинусное сходство (Distance.COSINE). Задача базовой версии была понять качество «из коробки», без дополнительных надстроек, и оно оказалось достаточным.
Шаг 7. Генерация: gpt-4o-mini
Языковая модель тоже взята по API OpenRouter — gpt-4o-mini. Качество для ответов по лекциям достаточное, API стабильное, цена низкая: 0,15 доллара за миллион входных токенов и 0,60 — за миллион выходных. У OpenRouter для этой модели есть несколько провайдеров, и при простое одного цена иногда опускается ниже прямого API.
Шаг 8. API и развёртывание
Сервис упакован во Flask с тремя маршрутами: проверка живости, приём вопроса и журнал, показывающий путь запроса от вопроса до ответа — какие чанки нашлись и что ушло в модель. Всё собрано в Docker и развёрнуто на сервере с 2 CPU и 4 ГБ памяти.
Журнал оказался полезнее, чем казалось: по нему сразу видно, ошибся поиск или модель. Это та же латентность и прозрачность инференса, которую стоит закладывать в любой промышленный сервис.
Что мы сознательно не делали: реранкер
Cross-encoder-реранкер заметно улучшает выдачу, но в этом проекте он лишний. Лекции идут последовательно от темы к теме, повторов мало, чанков немного — 1667. Тесты показали, что лучшие кандидаты по косинусному сходству уже достаточно точны. Реранкер оправдан, когда база большая и в ней много похожих документов — например, несколько версий одного регламента.
Чеклист сборки пайплайна
- Выбрать модель распознавания речи, которая работает на имеющемся железе.
- Нормализовать текст: убрать таймкоды и служебные символы, сохранить пунктуацию.
- Задать размер чанка, минимум и перекрытие; резать по концам предложений.
- Заранее решить, где считаются эмбеддинги вопросов в проде, и замерить скорость.
- Посчитать стоимость векторизации всего корпуса до запуска.
- Начать с простого поиска по косинусному сходству, без реранкера.
- Добавить журнал пути запроса — какие чанки нашлись и что ушло в модель.
- Упаковать сервис в контейнер и проверить его на целевом сервере.
Частые ошибки
Проверять эмбеддинг-модель только на индексации. Корпус векторизуется один раз, а вопросы — постоянно; медленная модель ломает прод, а не подготовку.
Сразу добавлять реранкер и сложный поиск. Без базовой версии непонятно, какую проблему решает каждая надстройка.
Удалять пунктуацию при нормализации. Без точек нарезка по предложениям невозможна.
Не вести журнал запросов. Жалоба «ассистент ответил неправильно» без журнала не разбирается.
Считать API-модели дорогими на глаз. На корпусе такого размера векторизация стоит меньше цента; дорогим обычно оказывается сервер под локальную модель.
Что делать дальше
Посчитайте объём ваших учебных записей в часах и прикиньте: при расшифровке это даст порядка полутора миллионов символов на курс, векторизация которых по API стоит копейки. Главный вопрос не цена, а допустимость отправки внутренних материалов во внешний API. Если допустимо — пилотный проект собирается за дни на недорогом сервере. Если нет — сначала закладывается локальный вычислитель, и уже от него считается весь пайплайн.