RAG만으로는 부족하다

한동안 AI 검색 이야기를 하면 거의 공식처럼 따라붙는 말이 있었어.
문서를 쪼개고, 임베딩하고, 벡터 검색해서 LLM에 넣으면 끝이라는 이야기야.

실제로 많은 기본형 RAG 시스템은 이런 구조로 만들어졌어. 문서를 작은 조각으로 나누고, 임베딩을 만들고, 질문과 비슷한 문서를 벡터 유사도 검색으로 찾아서 LLM에 넣는 방식이야. GraphRAG 문서에서도 이런 기본적인 RAG 구조를 설명하고 있어.

그런데 여기서 문제가 생겨.
질문이 단순하면 이 방식도 꽤 잘 작동했어. 예를 들어 “이 기능이 뭐야?” 같은 질문은 잘 찾는 편이야.

하지만 여러 문서에 흩어진 정보를 엮어야 하는 질문에서는 이야기가 달라져. 예를 들어 이런 질문이야.

“이 프로젝트에서 A 시스템과 B 시스템이 왜 연결됐지?”
“이 기능이 처음 생긴 이유가 뭐야?”

이런 질문은 문장 하나를 찾는 문제가 아니라 여러 정보 사이의 관계를 이해해야 하는 문제야.
기본 RAG는 문서 조각을 잘 찾는 데는 강하지만, 이런 관계형 질문에서는 종종 허둥대는 모습을 보였어.

 

[Source: ChatGPT 생성]

 

그래서 다시 등장한 BM25

이쯤 되면 다시 등장하는 검색 고수가 있어. 바로 BM25야.

BM25는 키워드 기반 검색 알고리즘인데, 사용자가 입력한 단어가 문서에 얼마나 잘 등장하는지를 계산해서 문서를 찾는 방식이야.

예를 들어 이런 경우에는 BM25가 아주 강해.

• 정확한 제품명 검색
• 에러 코드 검색
• 사내 약어 검색
• 기술 문서 키워드 검색

이런 검색은 의미 유사도보다 단어 정확도가 훨씬 중요하기 때문이야.

그래서 요즘 검색 시스템은 “벡터가 좋냐, BM25가 좋냐” 같은 싸움이 아니야.

대부분은 이렇게 말해. 둘을 섞어서 쓰는 하이브리드 검색이 더 좋다.

대표적인 검색 엔진인 Elasticsearch도 벡터 검색과 전통적인 키워드 검색을 함께 사용하는 하이브리드 접근을 설명하고 있어.

다만 여기서 기술적인 재미있는 문제가 하나 있어.

• 벡터 검색 점수는 보통 0~1 사이
• BM25 점수는 범위가 훨씬 넓음

그래서 두 점수를 단순히 더하면 결과가 이상해질 수 있어. 그래서 실제 서비스에서는 점수 튜닝이나 재정렬 같은 작업이 꽤 중요해.

 

그런데 진짜 문제는 검색 엔진이 아니다

여기서 많은 팀이 착각하는 지점이 있어. BM25 붙이면 해결이네?

그런데 현실은 그렇지 않은 경우가 많았어. 검색 품질을 가장 많이 흔드는 건 사실 검색 알고리즘이 아니라 데이터 상태였기 때문이야.

예를 들어 이런 상황을 생각해보면 쉬워.

• 문서 제목이 제각각임
• 같은 개념을 부서마다 다른 단어로 씀
• 오래된 문서와 최신 문서가 뒤섞여 있음
• 메타데이터가 없음
• 파일 이름이 final_v3_real_final.docx

이 상태는 마치 책장이 엉망인 도서관 같은 거야. 여기에 사서를 한 명 더 넣는다고 책이 갑자기 잘 찾아질까? 대부분은 아니야.

그래서 실무에서는 종종 이런 질문을 먼저 해. 우리 데이터는 검색 가능한 상태인가? 이 질문을 건너뛰면 검색 엔진을 아무리 바꿔도 결과는 계속 흔들리기 쉬워.

 

그리고 더 중요한 것: 평가

또 하나 중요한 게 있어. 바로 평가 데이터셋이야. RAG를 개선할 때 평가셋 없이 작업하면 거의 항상 이런 상황이 생겨.

“왠지 좋아진 것 같아.” 이건 굉장히 위험한 상태야. 왜냐하면 다음을 구분할 수 없기 때문이야.

• 검색이 좋아진 건지
• 프롬프트가 우연히 맞은 건지
• 특정 질문만 좋아진 건지

그래서 실무에서는 점점 RAG 평가셋 구축이 중요한 작업으로 올라오고 있어.

 

그래서 등장한 GraphRAG

최근 주목받는 접근 중 하나가 바로 GraphRAG야. 이 방식은 기존 RAG와 조금 다르게 접근했어. 텍스트에서 다음 정보를 추출해.

• 엔티티
• 관계
• 핵심 주장

그리고 이걸 지식 그래프로 만들어. 그래프를 만들면 이런 질문이 훨씬 쉬워져.

• 어떤 회사가 어떤 제품을 만들었는지
• 어떤 프로젝트가 어떤 팀과 연결됐는지
• 어떤 사건이 어떤 결과로 이어졌는지

또 GraphRAG는 여러 검색 방식도 제안했어. 대표적으로 이런 방식이 있어.

• Global Search: 전체 문서 흐름을 이해하는 검색
• Local Search: 특정 엔티티 주변을 깊게 파는 검색
• DRIFT Search: 관계를 따라 확장하는 검색

이 접근의 핵심은 하나야. 문서를 찾는 게 아니라 정보 사이 관계를 찾는 것이야. 그래서 프로젝트 히스토리, 정책 문서, 고객 데이터처럼 관계가 중요한 데이터에서는 훨씬 설득력 있는 방향이 될 수 있어.

 

온톨로지가 다시 주목받는 이유

여기서 또 하나 같이 등장하는 개념이 있어. 바로 온톨로지야. 온톨로지는 간단히 말하면 이런 거야. 데이터의 의미와 관계를 미리 정의하는 규칙. 예를 들어 이런 질문을 미리 정의하는 거야.

• 고객이란 무엇인가
• 제품과 서비스의 관계는 무엇인가
• 프로젝트와 팀의 관계는 무엇인가

기업 AI에서 온톨로지가 중요한 이유는 조직 안의 용어를 표준화하기 때문이야. 같은 개념을 부서마다 다르게 부르면 검색도 추론도 흔들리기 쉬워. 그래서 요즘은 이런 구조가 점점 중요해지고 있어. 지식 그래프 + 온톨로지 - 이걸 생활 비유로 설명하면 이렇다.

그래프는 누가 누구와 연결돼 있는지 보여주는 지도

온톨로지는 이 지도에서 건물, 도로, 지하철을 어떻게 구분할지 정하는 규칙

지도만 있으면 복잡해지고 규칙만 있으면 연결이 안 보여.

그래서 요즘은 GraphRAG와 온톨로지를 같이 보는 흐름이 강해지고 있어.

 

결국 중요한 것은 데이터와 평가

정리해보면 RAG의 다음 단계는 기술 이름 하나 더 붙이는 일이 아니야.

• BM25는 여전히 강력하고
• 벡터 검색도 여전히 필요하고
• GraphRAG는 관계를 더 잘 다루게 해줘.

하지만 진짜 차이를 만드는 건 따로 있어. 잘 정리된 데이터 그리고 제대로 된 평가 체계

이 두 가지야. 내가 이 주제를 한 문장으로 줄이면 이렇게 말하고 싶어. RAG를 고도화한다는 건 검색기를 바꾸는 일이 아니라 데이터를 이해하고 평가하는 수준을 끌어올리는 일이야.

기술은 계속 화려해지고 있어. 그런데 성능을 결정하는 건 여전히 단순해. 데이터와 평가야.