Решения

RAG на GPU: индексирование, retrieval и latency‑бюджет

Задача страницы. Дать практический рецепт построения RAG‑системы (Retrieval‑Augmented Generation) на облачных GPU: от пайплайна подготовки данных и эмбеддингов до выбора индекса, rerank’а и бюджета задержек на прод‑инференсе.

TL;DR

RAG = ингест (chunk→embed) → поиск кандидатов → переранжирование → сбор контекста → ответ LLM.
На GPU ускоряются два узких места: эмбеддинги и векторный поиск (FAISS‑GPU / cuVS).
Держите latency‑бюджет: T_total ≈ T_embed_q + T_search + T_rerank + T_LLM. Для онлайн‑чата целитесь в p95 ≤ 1–1.5 с.
Экономьте VRAM/цену за 1M через INT8/INT4 эмбеддинги/модель, умеренный контекст и стриминг токенов.

Связанные страницы‑«детализация»:
→ Векторы/индексы: /solutions/rag/vector-db/
→ Оценка качества: /solutions/rag/evaluation/
→ Эмбеддинги на GPU: /solutions/embeddings/
→ Инференс и стоимость: /solutions/llm-inference/, /solutions/llm-inference/costs/
→ Стриминг/наблюдаемость/безопасность: /solutions/llm-inference/streaming/, /solutions/llm-inference/observability/, /solutions/llm-inference/guardrails/

Когда RAG лучше дообучения

Частые обновления знаний. Дешевле переиндексировать документы, чем регулярно дообучать LLM.
Много доменов/тенантов. Раздельные индексы/коллекции, единая модель ответа.
Требуется цитируемость. RAG возвращает ссылки/цитаты, повышая доверие и управляемость.

Когда не стоит: крайне «структурные» задачи с короткими контекстами и верифицируемой логикой — рассмотрите компактную модель без retrieval или лёгкий классификатор.

Архитектура RAG (канонический пайплайн)

Ингест → Очистка/Разметка → Chunking → Embeddings → Векторный индекс → (опц.) Метаданные/БМ25

Запрос → Embedding запроса → Поиск top‑K → (опц.) Rerank → Сбор контекста → Подсказка → LLM → Ответ+Цитаты

Роли GPU:

Ингест (офлайн): быстрый расчёт эмбеддингов батчами.
Онлайн: эмбеддинг запроса + GPU‑поиск + (опционально) rerank.
LLM‑ответ: выбранный стек (vLLM/TGI/TensorRT‑LLM/SGLang/llama.cpp).

Подготовка данных и чанкование

Нормализация: PDF/HTML/Docx → чистый текст + блоки разметки (заголовки, списки, таблицы).
Chunking:

Размер (токены): 256–512 для чата/QA; 768–1024 для аналитики; overlap 10–20%.
Стратегии: по абзацам/заголовкам; «умный» сплит по пунктуации; для кода — по логическим блокам.
Метаданные: title, section, source_url/id, lang, timestamp, tags.
Dedup: хеши шинглов/абзацев, чтобы не плодить близнецы.

Пример чанкера (упрощённо):

def chunk(text, max_tok=512, overlap=64, tokenize=lambda s: s.split()):

toks = tokenize(text)

i = 0

while i < len(toks):

yield » «.join(toks[i:i+max_tok])

i += max_tok — overlap

Подробнее про эмбеддинги и батч‑планирование: /solutions/embeddings/.

Эмбеддинги на GPU

Модель эмбеддингов выбирайте под языки/домены; важны: dim, latency, цена.
Параметры батча: балансируйте VRAM/throughput; цель — saturate Tensor Cores, избегая OOM.
Хранение: fp16 (2 байта × dim) или INT8‑квант для экономии памяти индекса (см. /solutions/llm-inference/quantization/).

Оценка памяти эмбеддингов:

Mem_vectors ≈ N_docs × dim × bytes_per_elem

Пример: 2 млн чанков × 768 × 2 байта ≈ ~2.95 ГБ (без оверхеда индекса).

Индексы и поиск (GPU)

Выбор индекса зависит от N и бюджета задержек (детально: /solutions/rag/vector-db/):

FLAT (точный): максимум качества, дороже по задержкам на больших N.
IVF‑Flat/IVF‑PQ: компромисс качество/скорость/память (centroids + PQ‑кванты).
HNSW: быстрый small‑to‑mid, больше памяти.
Гибрид (BM25 + вектор): смешанный candidate set.

Latency‑ориентиры (приближённо, порядок величин на одной GPU):

T_search FLAT: O(N) скан; IVF/HNSW: O(log N)/O(√N) с константами.
Offline‑ингест: IVF‑тренировка (к‑средних), PQ‑кодификация — тоже хорошо параллелится на GPU.

Rerank: когда и как

Зачем: повысить точность top‑K, особенно на длинных/шумных документах.
Где считать:

На GPU — если SLA жёсткий и трафик высокий.
На CPU — если K небольшой и задержки терпимы.

Практика: выдавайте topK_retrieve (например, 50–100), затем rerank до k’ (8–12). Для суперстрогой p95 часто хватает без rerank, но повышайте качество chunk‑контекста (заголовки, подсветка).

Сбор контекста и подсказка для LLM

Цели: компактность, цитируемость, устойчивость к «инъекциям».

Формируйте структурированный контекст: блоки [Источник|Заголовок|Сниппет|Score].
Ограничивайте общий context budget (например, ≤ 1–2 K токенов для short‑пула).
Сортируйте по релевантности, удаляйте дубликаты/пересечения.
В подсказке явно требуйте ссылки на источники и «не выдумывать» вне них.

Latency‑бюджет (как уложиться в SLA)

Обозначим:
T_embed_q — эмбеддинг запроса; T_search — поиск; T_rerank — переранжирование; T_LLM — генерация (prefill + decode).

Бюджет:

T_total ≈ T_embed_q + T_search + T_rerank + T_LLM

T_LLM ≈ (L_in / P) + (L_out / (D / B)) + overhead

Где L_in — системный промпт + контекст, L_out — целевая длина ответа; P/D/B — как в /solutions/llm-inference/costs/.

Ориентиры для онлайн‑чата (p95):

T_embed_q ≤ 20–40 мс, T_search ≤ 50–150 мс, T_rerank ≤ 80–200 мс, T_LLM ≤ 600–900 мс.
Для «аналитики» допускается больше (2–3 с), но обязательно — стриминг (см. /solutions/llm-inference/streaming/).

Стоимость и кэширование

Ключевые драйверы цены: эмбеддинг запроса + генерация LLM.
Снижайте:

Кэш результатов по нормализованным запросам (n‑gram сигнатуры, канонизация).
Кэш префикса подсказки (в vLLM) и обрезка контекста по важности.
Квантизация: INT8/INT4 для эмбеддингов/LLM, FP8 на H100 (см. /solutions/llm-inference/quantization/).
Лимиты длины и раздельные пулы short/long (см. /solutions/llm-inference/multi-model/).
Цена за 1M токенов → формулы в /solutions/llm-inference/costs/.

Безопасность и качество

Guardrails: PII‑санитайзинг входа/выхода, фильтры категорий, защита от prompt‑injection (см. /solutions/llm-inference/guardrails/).
Оценка качества: offline‑метрики (Recall@K/MRR), A/B на проде, ручная разметка edge‑кейсов — см. /solutions/rag/evaluation/.
Наблюдаемость: TTFT/TBT/TTLT, hit‑rate кэшей, распределение L_in/L_out, ошибки — см. /solutions/llm-inference/observability/, /solutions/monitoring-logging/.

Паттерны эксплуатации

Мульти‑коллекции/тенанты: изоляция индексов, отдельные лимиты, кванты, бюджеты.
Инкрементальные обновления: log‑таблица изменений → периодический re‑embed + reindex.
Гибридный поиск: BM25‑кандидаты + векторный rerank — особенно для длинных документов/кода.
Мультиязычность: детект языка → выбор соответствующего эмбеддинга/коллекции.
Док‑контекст в несколько шагов: multi‑hop (retrieve → answer → follow‑up retrieve) — отделяйте в long‑пуле.

Мини‑пример пайплайна (псевдокод)

				
					def answer(query: str, k=50, k_rerank=10, out_tokens=200):
    # 1) Эмбеддинг запроса (GPU)
    q_vec = embed_query(query)               # T_embed_q

    # 2) Поиск кандидатов (GPU индекс)
    cands = vecdb.search(q_vec, top_k=k)     # T_search  → [(doc_id, score)]

    # 3) (Опц.) Rerank (GPU/CPU)
    reranked = rerank(query, cands)[:k_rerank]  # T_rerank

    # 4) Сбор контекста (дедуп/обрезка)
    ctx = build_context(reranked, budget_tokens=1200)

    # 5) Подсказка и генерирование (стриминг)
    prompt = make_prompt(query, ctx)
    return llm_generate(prompt, max_new_tokens=out_tokens, stream=True)

Конфигурации под разные масштабы

Small (≤ 100 тыс. чанков)

Индекс: FLAT/HNSW, rerank включён.
Эмбеддинги/поиск/LLM — одна или две GPU.

Medium (10⁵–10⁶)

Индекс: IVF‑Flat или IVF‑PQ (k‑means на GPU), rerank по top‑50→10.
Отдельные пулы short/long, кэширование запросов.

Large (≥ 10⁶–10⁷)

Шардинг по коллекциям/тенантам; префильтры по метаданным.
Индекс IVF‑PQ + гибрид с BM25; периодические ребилды ночами.
Горизонталь по поиску и отдельный пул LLM.

Детали по индексам и параметрам тренировки — в /solutions/rag/vector-db/.

Как запускать это в cloudcompute.ru

Шаблон “RAG‑Stack” в /solutions/templates/:
– сервис инжеста (chunk→embed→index) с батч‑GPU;
– онлайн‑поиск (GPU), опциональный rerank;
– LLM‑сервис (vLLM/TGI/TensorRT‑LLM/…);
– кэш запросов, стриминг, метрики/трейсы/алерты.
Экономика и SLA: /solutions/llm-inference/costs/, /solutions/llm-inference/observability/, /solutions/llm-inference/streaming/.

Чек‑лист перед продом

Выбран размер чанков/overlap и схема метаданных.
Замерен throughput эмбеддингов (батчи/VRAM), выбран индекс (IVF/HNSW/…); подтверждён объем памяти.
Протестированы латентности T_embed_q/T_search/T_rerank/T_LLM на пилоте (p50/p95).
Настроены пулы short/long, стриминг, лимиты max context/max_tokens.
Включены guardrails (PII/injection), кэширование запросов и префиксов.
Настроены метрики/логирование/трейсинг; определены SLO и алерты.
Оценка качества: Recall@K, MRR, A/B — см. /solutions/rag/evaluation/.

Навигация по разделу «RAG»

/solutions/rag/vector-db/ • /solutions/rag/evaluation/ • /solutions/embeddings/ • /solutions/llm-inference/ • /solutions/llm-inference/streaming/ • /solutions/llm-inference/observability/ • /solutions/llm-inference/guardrails/ • /solutions/llm-inference/costs/

RAG на GPU: индексирование, retrieval и latency‑бюджет

Подготовка данных и чанкование

Свяжитесь с нами

Подпишитесь на рассылку