RAG는 꼭 필요한 것인가

RAG, 머릿속에 남은 세 단어

top-K, RRF, 청킹. 제가 RAG의 기본 개념에 대해서 알고 있는 누군가에게 RAG에 대해서 더 설명하기 위해서 급하게 이것저것 알아봤지만, 이 글을 쓰면서 아직까지 기억에 남은 단어는 저 세 가지입니다. RAG는 AI와 함께 출몰한 기술 중에 하나인 걸로 알고 있습니다.

• top-K — 유사도 상위 K개를 추려오는 검색 단계
• RRF (Reciprocal Rank Fusion) — 벡터 검색 결과와 키워드 검색 결과를 섞을 때 쓰는 랭크 결합 기법
• 청킹(chunking) — 긴 문서를 임베딩 가능한 단위로 쪼개는 전처리

이미 제 블로그도 임베딩을 쓰고 있습니다

제 기술 블로그에도 RAG 까지는 아니더라도, 임베딩과 관련된 기술을 활용한 곳이 두 곳이 있습니다. 하나는 검색 쪽이고, 나머지 하나는 기술 글 상세 페이지의 관련 글 영역입니다.

단순하게 키워드들을 분석해서 비슷한 것을 찾는 게 아니라, 키워드들의 의미가 비슷한 — 이를테면 토끼와 강아지가 있다고 하면 "동물"이라는 맥락에서 연관성을 찾아야 할 때 찾을 수 있도록 하는 게 RAG에서도 필요한 기술 중의 일환이라고 보시면 됩니다.

임베딩은 매력적입니다, 그런데…

키워드가 아니라 뭔가 맥락을 통해서 특정 데이터를 더 정확하게 조회할 수 있다는 결론만 놓고 보면, 임베딩을 활용한 코사인 유사도 기반 데이터 조회는 굉장히 매력적으로 보입니다.

그러나, 생각해보면 우리는 임베딩을 해서 벡터값을 비교해 유사도를 따질 만큼 데이터를 엄격하게 검토해야 할 일이 그렇게 많지 않다는 것을 알아야 할지도 모릅니다.

키워드 검색으로 충분한 경우가 더 많을지도 모릅니다

임베딩을 활용하는 게 아닌, 기존 키워드 분석을 통한 비교 방식으로도 문제가 대부분 해결될지도 모른다는 얘기입니다. 임베딩을 활용하면 물론 더 높은 정확도의 결과 데이터를 조회할 수 있을지 모르겠지만, 임베딩을 하기 위해 추가적으로 처리하는 공정들에 비해 얻는 수확이 그렇게 크지 않을지도 모른다는 얘기입니다.

추가 인프라·모델 호출·스토리지·레이턴시까지 감수하면서 끌어올리는 그 정확도가, 우리 서비스에서 정말 그만큼 가치 있는 차이를 만들어내는가?

잠정 결론 — RAG가 정말 빛나는 곳은 어디일까

아직까지는 제가 잘 이해하지 못해서 그런 것일지도 모르겠으나, RAG를 활용하기 적합한 것은 챗봇 정도 밖에 없는 게 아닌가 하는 생각이 들었습니다.