월드컵 데이터를 활용한 "지루한" RAG 데모 구축 — SQLite, sqlite-vec, 그리고 프레임워크 없이

대부분의 RAG 튜토리얼은 단 하나의 질문에 답하기도 전에 벡터 데이터베이스 (vector database)와 무거운 프레임워크 (framework)를 먼저 찾습니다. 저는 이 모든 과정이 얼마나 작아질 수 있는지 확인하고 싶었습니다. 그래서 파일 기반의 SQLite 데이터베이스, 벡터 확장 기능 (vector extension), 그리고 LLM 호출만을 사용하여 실제 축구 데이터를 기반으로 한 질의응답 데모를 구축했습니다.

가입 없이 무료로 직접 체험해 보실 수 있습니다: WorldCup.GetToKnowYourOwnData.com

"2022년 월드컵 결승전에서 누가 득점했나요?" 또는 "모로코의 조별 리그 성적은 어땠나요?"와 같은 질문을 던지면, 시스템은 평이한 영어로 답변하며 사용한 경기 기록을 참조(point back)해 줍니다. 따라서 무조건 믿는 대신 직접 확인할 수 있습니다.

이 포스트에서는 의도적으로 흥미롭지 않게 설계된 아키텍처 (architecture)를 살펴봅니다. 그것이 바로 핵심입니다.

RAG란 무엇인가 (한 단락 요약)
검색 증강 생성 (Retrieval-Augmented Generation, RAG)은 모델을 변경하지 않습니다. 질문을 던질 때 모델 앞에 무엇을 놓느냐를 변경하는 것입니다. 자신만의 콘텐츠 컬렉션을 유지하고, 질문과 가장 관련이 높은 몇 가지 조각을 찾아낸 뒤, 질문과 함께 이를 LLM에 전달하여 제공된 정보로부터 답변하도록 요청합니다. 모델은 사용자의 데이터를 기억할 필요가 없습니다. 그저 검색된 스니펫 (snippets)을 읽을 뿐입니다. 마치 지식이 풍부한 친구가 손에 맞는 핸드북 페이지를 펼쳐놓고 있는 모습을 상상해 보세요.

전체 스택 (The whole stack)
포함된 모든 요소는 다음과 같습니다:

1. 소스 문서를 구절 (passages) 단위로 청킹 (Chunk) 합니다.
2. 임베딩 모델 (embedding model, 저는 Voyage AI를 사용합니다)을 사용하여 각 청크를 임베딩(embed)합니다 — 즉, 텍스트를 벡터 (vector)로 변환합니다.
3. 벡터 검색을 위해 sqlite-vec 확장 기능을 사용하여 청크와 그 벡터를 SQLite에 저장합니다.
4. 쿼리 (query) 시점에 질문을 임베딩하고, 벡터 유사도 검색 (vector similarity search)을 실행하여 상위 k개의 가장 유사한 청크를 가져온 뒤, "이 컨텍스트 (context) 내에서만 답변하고 출처를 밝히세요"라는 프롬프트 (prompt)와 함께 LLM (저는 Claude를 사용합니다)에 전달합니다. 벡터 DB 서비스도 없고, 오케스트레이션 프레임워크 (orchestration framework)도 없습니다. 데이터베이스는 scp로 복사할 수 있는 단일 파일입니다. 검색 (retrieval)은 단 하나의 SQL 쿼리 (query)로 이루어집니다:

SELECT c.text, c.source
FROM chunk_vectors v
JOIN chunks c ON c.chunk_id = v.chunk_id
WHERE v.embedding MATCH :question_vector
ORDER BY distance
LIMIT 8;

벡터 데이터베이스 대신 SQLite를 사용하는 이유
수천 개의 청크 (chunk)로 구성된 코퍼스 (corpus) — 이는 수많은 실제 사용 사례를 포괄합니다 — 의 경우, 전용 벡터 데이터베이스를 사용하는 것은 여러분에게 존재하지도 않는 규모 (scale) 문제를 해결하려는 것과 같습니다. sqlite-vec을 사용하는 SQLite는 프로세스 내 (in-process) 벡터 검색을 제공합니다: 서버가 필요 없고, 네트워크 홉 (network hop)이 없으며, 단일 휴대용 파일인 데이터베이스를 가집니다. 파일을 복사하여 백업하세요. 파일을 복사하여 배포하세요. 정말로 이 규모를 넘어서게 된다면 그때 알게 될 것입니다. 그리고 대부분의 프로젝트는 결코 그 단계에 도달하지 않습니다.

"RAG를 위해 어떤 프레임워크를 사용해야 하나요?"라는 질문에 대한 솔직한 답변은 종종 "아무것도 사용하지 마세요"입니다. 구성 요소는 청커 (chunker), 임베더 (embedder), 벡터 인덱스 (vector index), 그리고 프롬프트 (prompt)입니다. 이 네 가지 모두가 여기에서 명확히 보입니다.

데이터
이 데모는 무료 오픈 데이터를 기반으로 작동합니다:

1. StatsBomb 오픈 데이터: 2022 월드컵, Euro 2024, Copa América 2024와 같이 완료된 토너먼트의 상세 경기 정보(슈팅, 기대 득점 (expected goals), 득점자 등)를 포함합니다.
2. Openfootball: 2026 월드컵 일정 및 결과 (오픈 데이터이며, 경기 중 실시간이 아닌 다음 날 업데이트되는 방식).

각 경기는 읽을 수 있는 몇 개의 텍스트 문서가 되며, 다른 데이터와 마찬가지로 청킹 (chunking) 및 임베딩 (embedding) 과정을 거칩니다. 코퍼스 (corpus)는 그저 디스크 상의 파일일 뿐입니다.

오늘은 클라우드, 내일은 로컬 — 제가 가장 중요하게 생각하는 부분
이 데모는 생성을 위해 클라우드 모델 (Claude)을 호출합니다. 하지만 LLM (대규모 언어 모델)은 RAG 파이프라인 (pipeline)에서 진정으로 교체 가능한 유일한 부분입니다. 시스템의 다른 어떤 부분도 어떤 모델이 답변하는지에 신경 쓰지 않습니다. 설정 파일의 두 줄만 바꾸면 동일한 파이프라인이 Ollama를 사용한 로컬 모델에서 실행됩니다. 따라서 전체 시스템을 데이터 유출 없이 단 한 대의 기기에서 실행할 수 있습니다. 이는 대부분의 사람들이 자신의 문서에 RAG를 적용하려는 진짜 이유인 개인정보 보호 (privacy) 측면에서 매우 중요합니다. 변호사의 계약서, 의사의 기록, 기업의 내부 문서 등 그 어떤 것도 클라우드 API에 도달해서는 안 됩니다.

이 라이브 축구 데모는 파이프라인이 작동한다는 것을 보여주는 저렴하고 공개적인 증거입니다. 로컬 모델을 대상으로 하는 동일한 아키텍처가 바로 민감 데이터를 처리할 때 실제로 사용하게 될 방식입니다.

강점과 한계점
RAG(검색 증강 생성)는 답변이 콘텐츠의 한두 조각에 존재하는 경우, 즉 'X의 점수는 무엇이었나', 'Y에서 누가 득점했나'와 같은 질문에 강합니다. 하지만 전체 코퍼스(corpus)를 한 번에 종합해야 하는 질문에는 약하며, 검색된 것만 볼 수 있습니다. 게다가 여전히 틀릴 수 있습니다. 검색 과정에서 누락될 수도 있고, 모델이 받은 내용을 잘못 해석할 수도 있습니다. 이것이 바로 데모의 모든 답변이 출처를 인용하는 이유입니다. 접지(Grounding)는 엄청난 도움을 주지만, 검증은 여전히 사용자에게 달려있습니다.

직접 시도해 보거나 깊게 파고들어 보세요
데모: WorldCup.GetToKnowYourOwnData.com — 무료이며 가입할 필요가 없습니다. 이 데모를 부수면서 검색(retrieval)이 어디서 실패하는지 저에게 알려주세요.

이 데모는 제가 작성한 RAG 구축 전 과정을 다룬 책('Get to Know Your Own Data with RAG')의 실습 예제이며, 관련 코드는 GitHub에 무료로 공개될 예정입니다(이번 달 책 출판 시).

여기서 한 가지를 얻어 가신다면: 벡터 데이터베이스와 프레임워크를 설치하기 전에, 지루한 버전부터 시도해 보세요. 파일 하나, SQL 쿼리 하나, 그리고 프롬프트 하나가 놀라울 정도로 큰 역할을 합니다.