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 эмбеддинги/модель, умеренный контекст и стриминг токенов.

Связанные страницы: Векторы/индексы • Оценка качества • Эмбеддинги на GPU • Инференс и стоимость • Стриминг

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

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

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

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

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

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

Роли GPU: ингест (офлайн) — быстрый расчёт эмбеддингов батчами; онлайн — эмбеддинг запроса + GPU‑поиск + (опционально) rerank; LLM‑ответ — выбранный стек.

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

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

Подробнее про эмбеддинги: /solutions/embeddings/.

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

Выбор индекса зависит от N и бюджета задержек (детально):

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

Rerank: когда и как

Зачем: повысить точность top‑K, особенно на длинных/шумных документах. Практика: выдавайте topK_retrieve (например, 50–100), затем rerank до k' (8–12). На GPU — если SLA жёсткий и трафик высокий; на CPU — если K небольшой и задержки терпимы.

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

T_total ≈ T_embed_q + T_search + T_rerank + T_LLM

Ориентиры для онлайн‑чата (p95): T_embed_q ≤ 20–40 мс, T_search ≤ 50–150 мс, T_rerank ≤ 80–200 мс, T_LLM ≤ 600–900 мс.

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

Снижайте цену через:

• Кэш результатов по нормализованным запросам.
• Кэш префикса подсказки (в vLLM) и обрезка контекста по важности.
• Квантизацию INT8/INT4 для эмбеддингов/LLM, FP8 на H100.
• Лимиты длины и раздельные пулы short/long.

Мини‑пример пайплайна

def answer(query: str, k=50, k_rerank=10, out_tokens=200):
    q_vec = embed_query(query)               # T_embed_q
    cands = vecdb.search(q_vec, top_k=k)     # T_search
    reranked = rerank(query, cands)[:k_rerank]  # T_rerank
    ctx = build_context(reranked, budget_tokens=1200)
    prompt = make_prompt(query, ctx)
    return llm_generate(prompt, max_new_tokens=out_tokens, stream=True)

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

• Выбран размер чанков/overlap и схема метаданных.
• Замерен throughput эмбеддингов, выбран индекс; подтверждён объём памяти.
• Протестированы латентности T_embed_q/T_search/T_rerank/T_LLM на пилоте (p50/p95).
• Настроены пулы short/long, стриминг, лимиты max context/max_tokens.
• Включены guardrails (PII/injection), кэширование запросов и префиксов.
• Настроены метрики/логирование/трейсинг; определены SLO и алерты.

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

Векторные базы данных • Оценка качества • Эмбеддинги • Инференс LLM • Стриминг • Наблюдаемость • Guardrails • Стоимость