RAG는 아키텍처가 아니야

RAG는 시스템 설계 방식이야

Retrieval-Augmented Generation은 모델 아키텍처가 아니라 검색을 생성 앞에 붙이는 시스템 패턴이야. 질문이 오면 응용 코드가 벡터 저장소, 데이터베이스, 웹 검색, 구조화 질의에서 관련 문서를 찾고 그 내용을 모델의 컨텍스트에 넣어. 모델 가중치는 그대로고, 모델은 추가된 문서를 프롬프트 일부로 읽어 답을 만들어.

검색하고, 붙이고, 물어봐

이름을 벗기면 세 단계야. 말뭉치에서 관련 조각을 찾고, 모델 입력에 붙이고, 그 자료를 바탕으로 답하라고 지시해. 세 단계 모두 응용 코드가 맡으며 모델 자체는 RAG가 없을 때와 같은 생성기야.

왜 내장 능력처럼 들릴까

‘내장 검색’, ‘기억을 갖춘 AI’ 같은 말은 모델 안이 달라진 듯 들려. 하지만 같은 기반 모델을 여러 RAG 시스템으로 감쌀 수 있고, 가중치를 바꾸지 않아도 결과는 크게 달라져. 그 차이는 모델보다 검색 품질과 프롬프트 구성에 있어.

RAG를 붙이면 달라지는 것

입력: 질문마다 모델이 읽는 자료가 늘어.
지연 시간: 생성 전에 검색 단계가 하나 생겨.
비용: 컨텍스트가 커져 입력 토큰 과금이 늘 수 있어.
행동: 학습 데이터에 없던 최신·사내 자료를 바탕으로 답할 수 있어.

그대로인 것

모델의 가중치, 학습 이력, 백본 아키텍처는 바뀌지 않아. 검색 능력을 갖는 건 모델이 아니라 모델을 둘러싼 시스템이야.

Code

네 줄로 구현한 RAG: 모델은 그대로·python

def rag_answer(query, vector_db, llm, top_k=5):
    docs    = vector_db.search(query, top_k=top_k)
    context = "\n\n".join(docs)
    prompt  = f"Context:\n{context}\n\nQuestion: {query}"
    return llm.generate(prompt)
# llm.generate is the SAME call you'd make without RAG.
# RAG lives in the four lines around it, not inside it.

RAG는 시스템 설계 방식이야

검색하고, 붙이고, 물어봐

왜 내장 능력처럼 들릴까

RAG를 붙이면 달라지는 것

그대로인 것

Code

External links

Exercise

Progress

댓글 0