클래식 벡터 RAG vs Google의 새로운 OKF 포맷 vs 두 방식의 결합 벤치마크 — 동일 코퍼스, 동일 7개 질문, 모두 로컬 환경
요약
Google의 새로운 OKF 포맷과 클래식 벡터 RAG의 성능을 로컬 환경에서 비교 벤치마크한 결과입니다. OKF와 RAG를 결합했을 때 정답률은 높아지지만 토큰 소모가 증가하며, 데이터의 최신성 문제나 청킹 오류 등 여전히 해결해야 할 한계점이 존재함을 보여줍니다.
핵심 포인트
- OKF+RAG 결합 방식이 일반 RAG 대비 정답률을 약 2배 높임
- 결합 방식 사용 시 일반 RAG보다 약 33% 더 많은 토큰 소모
- 청크 내 날짜 정보 부재 시 최신 문서 검색 실패 문제 발생
- 복잡한 스키마 분할 및 정보 구성(Composition) 시 검색 실패 사례 확인
Google Cloud는 6월 12일에 OKF (Open Knowledge Format)를 발표했습니다. 이는 YAML 프론트매터 (YAML frontmatter)가 포함된 마크다운 (markdown) 파일 디렉토리로 큐레이션된 지식을 저장하기 위한 사양 (spec)입니다. 파일당 하나의 개념을 담고, 서로 연결되며, 점진적 공개 (progressive disclosure)를 위한 index.md를 포함합니다. 유일한 필수 필드는 type입니다. 저는 이것이 실제로 무엇인가를 해결하는지 알고 싶어서, 테스트 코퍼스 (corpus)를 구축하고 측정했습니다. 모든 것은 로컬에서 실행됩니다: qwen3:8b + nomic-embed-text + ChromaDB, 외부 API는 사용하지 않았습니다.
설정 (SETUP)
- 코퍼스 (Corpus): 가짜이지만 현실적인 회사 문서 60개 (위키, 테이블 스키마, ADR, 40개의 지원 티켓). 800/100 기준 85개 청크 (chunks).
- OKF 번들 (bundle): 동일한 내용을 다루는 9개의 큐레이션된 개념.
- 7개 질문: 각각 다른 검색 실패 모드 (retrieval failure mode)를 유발하도록 설계됨.
결과 (7개 질문)
| 방식 | 정답 수 |
|---|---|
| RAG | 2 |
| OKF | 3 |
| OKF+RAG | 4 |
토큰 (tokens): 6341 (RAG), 8625 (OKF), 8435 (OKF+RAG)
어떤 것도 통과하지 못했습니다. 결합된 레이어 (combined layer)는 일반 RAG보다 약 33% 더 많은 토큰을 사용하면서, 일반 RAG의 두 배에 달하는 정답을 얻었습니다.
나를 놀라게 한 부분
질문: "수익을 어떻게 계산하나요?"
코퍼스에는 2023년 문서 (사용 중단됨, 장황함, 4000자)와 현재의 2026년 사양 (간결함, 500자)이 있습니다. 사용 중단된 문서는 7개의 청크로 나뉘고, 현재 문서는 1개로 나뉩니다. 상위 5개 검색된 청크 중 3개가 사용 중단된 문서에서 나왔습니다. 정답 문서는 85개 중 15위를 기록했습니다 — 용어 사전, 고객 테이블 스키마, 그리고 카나리아 제도 배송 비용에 관한 지원 티켓 뒤에 있었습니다. k 값을 15로 높여도 도움이 되지 않습니다. 올바른 것을 말하는 1개의 청크에 대항하여 잘못된 것을 말하는 6개의 청크를 가져오게 될 뿐입니다. 리랭커 (reranker)도 이를 해결할 수 없습니다 — 청크 텍스트 내에 어떤 것이 최신인지 나타내는 정보가 없기 때문입니다. 날짜가 청크에 포함되어 있지 않습니다.
발생한 다른 실패 모드들
-
청커 (Chunker)가 18개 컬럼의 스키마 테이블을 분할했습니다. 올바른 파일은 컨텍스트 (context) 안에 있었지만, 테이블은 없었습니다. 모델은 k=3과 k=5 모두에서 "모르겠습니다"라고 답했습니다.
-
구성 (Composition): 하나의 지표 정의에는 3개의 별도 파일에 있는 3개의 규칙이 필요합니다. RAG는 3개 중 2개를 검색하여 출처를 인용하며 자신 있게 답변했지만, 무언가 누락되었을 가능성은 전혀 암시하지 않았습니다.
-
흥미로운 패턴: 정보가 거의 없을 때는 "모르겠습니다"라고 답했지만, 정보가 거의 완벽하게 있을 때는 아무 말도 하지 않았습니다. 비용이 가장 많이 발생하는 바로 그 순간에 침묵합니다. OKF가 롱테일 (Long-tail) 질문에서 패배하는 지점입니다. "3월에 중복 주문 관련 사고가 있었나요?" — 일반적인 RAG는 검토되지 않은 40여 개의 지저분한 티켓들 사이에서 정답을 정확히 맞혔습니다. 이를 수동으로 큐레이션하는 것은 불가능에 가깝습니다. OKF 단독으로는 실패했습니다. 용어 관련 주의사항: 저는 클래식 벡터 (classic vector) 구현을 줄여서 "RAG"라고 부르고 있습니다. 엄밀히 말하면, OKF 인덱스를 탐색하는 에이전트 또한 RAG 파이프라인입니다. 다만 벡터 검색 (vector retrieval) 대신 구조화된 검색 (structured retrieval)을 사용할 뿐입니다. 정확한 프레임워크는 "클래식 벡터 RAG vs OKF 기반의 구조화된 검색"입니다. 누군가 이 점을 정확히 지적해 주었습니다. 전체 코드, 코퍼스 (corpus), 번들 및 원본 results.txt: https://github.com/JoaquinRuiz/rag-vs-okf git clone + uv sync를 통해 재현할 수 있습니다. 더 큰 모델을 사용했을 때 다른 수치가 나오는지 궁금합니다. 저의 경우 질문 4번은 실행할 때마다 결과가 불안정했습니다. submitted by /u/jokiruiz [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기