지연 시간: 배치, 비동기 처리, 시간이 쓰이는 곳

일반적인 RAG 요청에서 시간이 쓰이는 곳

쿼리 임베딩 — 호스팅 모델은 30–200ms, 작은 로컬 모델은 5–20ms
벡터 검색 — 단일 노드 Chroma는 5–50ms, HNSW를 쓰는 pgvector는 1–10ms
선택적인 BM25 — 5–30ms
선택적인 후보 50개 cross-encoder 재순위화 — CPU는 100–500ms, GPU는 30–150ms
LLM 생성 — 작은 모델은 500ms, 큰 모델의 긴 출력은 10초까지 걸려 다른 단계를 압도해.

최적화 순서

먼저 시간을 재고 가장 큰 항목부터 줄여. LLM 호출이 4초 걸리는데 쿼리 임베딩을 100ms에서 10ms로 줄이는 데 힘을 쓰는 것은 효율이 낮아. 검색 시간을 절반으로 줄이는 것보다 LLM 답변을 스트리밍하는 편이 사용자 경험을 더 크게 개선하는 경우가 많아.

스레드보다 비동기 처리

검색은 입출력 대기가 많은 작업이야. 구조가 허용한다면 파이썬의 asyncio나 다른 언어의 async/await를 사용해 임베딩 호출, 벡터 검색, BM25를 동시에 실행해. 직접 스레드를 관리하는 방식은 이 문제에 알맞은 추상화가 아니야.

Code

벡터 검색과 BM25를 동시에 실행하기·python

import asyncio

async def parallel_retrieve(question: str, k: int = 20):
    vec_task  = asyncio.create_task(asyncio.to_thread(vector_search, question, k))
    bm25_task = asyncio.create_task(asyncio.to_thread(bm25_search,   question, k))
    vec, bm25 = await asyncio.gather(vec_task, bm25_task)
    return reciprocal_rank_fusion([
        [r['id'] for r in vec],
        [r['id'] for r in bm25],
    ])

results = asyncio.run(parallel_retrieve('how do I cancel?'))

단계마다 걸린 시간 재기·python

import time
from contextlib import contextmanager

@contextmanager
def stage(name: str, log: dict):
    start = time.perf_counter()
    try:
        yield
    finally:
        log[name] = round((time.perf_counter() - start) * 1000, 1)

log = {}
with stage('embed', log):
    qvec = embed(question)
with stage('search', log):
    cands = collection.query(query_embeddings=[qvec], n_results=20)
with stage('rerank', log):
    final = rerank(question, cands)
print(log)   # {'embed': 42.3, 'search': 11.8, 'rerank': 187.4}

일반적인 RAG 요청에서 시간이 쓰이는 곳

최적화 순서

스레드보다 비동기 처리

Code

External links

Exercise

Progress

댓글 0