회사의 문서와 대화하는 AI 어시스턴트를 구축하고 싶으신가요? 먼저 한 가지 질문에 답해야 합니다: 당신의 데이터에서 실제로 가장 잘 작동하는 RAG 방법은 무엇인가?

RAG (Retrieval-Augmented Generation, 검색 증강 생성)는 대략 다음과 같이 작동합니다: 문서를 읽고, 작은 조각(chunks, 청크)으로 나누며, 각 조각을 데이터베이스에 저장되는 수치 벡터(embedding, 임베딩)로 변환합니다. 사용자가 질문을 하면, 시스템은 가장 관련성이 높은 조각들을 찾아 모델에 전달합니다. 모델은 전체 문서를 보는 것이 아니라, 중요한 부분만을 봅니다. 이를 통해 정확도는 올라가고 비용은 내려갑니다.

어려운 점은 다음과 같습니다: 모든 단계마다 수십 가지의 옵션이 존재합니다. 어떤 파서(parser)를 사용할 것인가? 청크 크기(chunk size)는 얼마로 할 것인가? 어떤 임베딩 모델(embedding model)을 사용할 것인가? 리랭커(reranker)를 사용해야 하는가? BM25, 벡터 검색(vector search), 또는 하이브리드(hybrid) 중 무엇을 선택할 것인가? 정답은 데이터셋마다 달라지며, 모든 사람에게 적용되는 단 하나의 "최적" 조합은 없습니다.

좋은 소식은, 테스트를 통해 당신을 대신해 정답을 찾아주는 오픈 소스 도구들이 있다는 것입니다. 저는 그중 세 가지를 깊이 있게 조사했습니다.

1. AutoRAG (Marker-Inc-Korea)

원시 문서(raw documents)에서 시작합니다: 파싱(parsing), 청킹(chunking)을 수행하며, 심지어 합성 Q&A 테스트 세트(synthetic Q&A test set)를 생성합니다. 그런 다음 당신의 데이터를 바탕으로 다양한 임베딩(embeddings), 검색 방법(retrieval methods), 리랭커(rerankers)의 점수를 매기고 "이것이 당신의 데이터에 가장 적합한 파이프라인입니다"라고 알려줍니다. YAML로 구성되며, 대시보드가 제공되고, 승리한 파이프라인을 API로 배포할 수 있습니다.

2. RAGBuilder (KruxAI)

베이지안 최적화(Bayesian optimization)를 사용하여 동일한 작업을 수행합니다. 모든 조합을 무차별 대입(brute-forcing)하는 대신, 이전 시도로부터 학습하여 가장 유망한 설정(configs)을 향해 나아갑니다. 청크 크기부터 리랭커에 이르기까지 모든 것을 훑습니다. 직관적인 UI가 제공되어, 옵션의 체크를 해제하면 해당 브랜치 전체가 건너뛰어집니다.

3. Red Hat AutoRAG (OpenShift AI)

엔터프라이즈용 솔루션입니다. 2단계 마법사를 통해 테스트할 구성(configurations)의 수를 선택할 수 있습니다. 시스템은 파싱(parsing), 청킹(chunking), 임베딩(embeddings), 검색(retrieval), 프롬프트(prompt)에 이르는 전체 체인에 걸쳐 조합을 벤치마킹하고, 당신의 데이터에 가장 적합한 것을 찾아냅니다.

이 세 가지 도구를 사용하면 추측이 아닌 측정에 기반하여 RAG 시스템을 구축할 수 있습니다. 테스트 없이 결정하지 마세요. 이 도구들은 당신의 데이터에서 실제로 무엇이 작동하는지를 수치로 보여줍니다.

그렇다면 이 도구들은 완벽할까요? 아니요.

그리고 가장 치명적인 공백은 문서 읽기(document reading)에 있습니다.

세 도구 모두가 공유하는 가장 눈에 띄는 약점은 문서 읽기 / OCR (Optical Character Recognition, 광학 문자 인식) 레이어입니다. 청킹 (chunking) 이후의 모든 과정 — 임베딩 (embedding) 선택, 검색 (retrieval), 재순위화 (reranking), 지표 평가 (metric evaluation) — 은 성숙해 있으며 자동화되어 있습니다. 하지만 OCR 측면은 몇몇 고정되고 구식인 엔진들에 묶여 있습니다.

이 도구들이 제공하는 OCR은 오래된 버전에 고정되어 있습니다. 예를 들어, 라이선스 준수 문제로 인해 몇 년 전에 만들어진 PaddleOCR의 오래된 포크 (fork) 버전이 실제로 내부에서 실행됩니다. PaddleOCR의 최신 다국어 모델이자 훨씬 더 정확한 모델들은 기본적으로 지원되지 않습니다. 마찬가지로, 차세대 클라우드 OCR API들도 문서화된 모듈 목록 어디에서도 찾아볼 수 없습니다.

Gemini나 OpenAI와 같은 멀티모달 (multimodal) 모델의 비전/OCR 기능 또한 직접적으로 지원되지 않습니다. 오직 AutoRAG만이 제3자 클라우드 파서 (parser)를 통해 간접적인 유료 (토큰 기반) 채널을 제공할 뿐입니다. 하지만 이는 일류 수준의 "Gemini OCR" 또는 "OpenAI OCR" 모듈이 아니며, RAGBuilder와 Red Hat은 그 정도의 유연성조차 제공하지 않습니다.

결론적으로, 이 도구들의 OCR/파싱 메뉴는 몇몇 레거시 (legacy) 로컬 엔진과 소수의 클라우드 파서로 구성된 폐쇄적이고 고정된 목록입니다. 이들은 최신 로컬 OCR 모델이나 Gemini/OpenAI 비전과 같은 클라우드 멀티모달 OCR을 기본적으로 제공하지 않습니다. 만약 그것들을 원한다면, 엔진을 직접 통합해야 합니다.

요약하자면: 최적의 RAG 방법을 찾는 것은 더 이상 추측의 영역이 아닙니다. 이 세 가지 도구로 측정하십시오. 하지만 스캔된 문서나 혼합된 문서를 다룬다면, 처음부터 OCR 레이어를 직접 강화해야 한다는 점을 명심해야 합니다.

링크

• AutoRAG: [https://github.com/Marker-Inc-Korea/AutoRAG]
• RAGBuilder: [https://github.com/KruxAI/ragbuilder]
• Red Hat AutoRAG: OpenShift AI → AutoRAG (docs.redhat.com)

LinkedIn, Threads, r/Rag 및 Hacker News에 더 짧은 버전으로 크로스 포스팅되었습니다.