스크립트
00:00:00안녕하세요, 여러분. 오늘 와주셔서 감사합니다. '아무것도 아닌 것'에 관한 강연에 오신 걸 환영합니다. 아, 죄송합니다.
00:00:21'검색(Retrieval)'에 관한 강연이죠. 제 이름은 유발이고 AI 연구소인 AI21에서 근무하고 있습니다.
00:00:29오늘 저는 대부분의 사람이 이야기하고 싶어 하지 않는 주제인 청킹(Chunking)에 대해 말씀드리고자 합니다.
00:00:37발표가 끝날 때쯤이면 청킹이 아직 죽지 않았고 이를 통해 할 수 있는 게 많다는 점을 납득시켜 드리고 싶네요.
00:00:45실제로 X나 링크드인 등 어디를 보든 RAG는 끝났다는 이야기를 자주 접하셨을 겁니다, 맞죠?
00:00:53최근에는 MCP도 끝났다고들 하더군요. 그리고 RAG도 또다시 끝났다고 하면서 오가닉 검색,
00:01:00오가닉 서치가 영원하길 외치죠. 그러다 보면 대체 RAG는 몇 번이나 죽어야 하는지 의문이 들 때가 옵니다.
00:01:07그렇지 않나요? 심지어 LlamaIndex의 CEO인 제리처럼 “RAG는 죽지 않았다”고 말하는 사람조차도
00:01:14무언가는 끝났다고 선언해야만 합니다. 그리고 그 대상은 바로 청킹인 듯하죠. “거기에 투자하지 마라,
00:01:23하지 마라”라면서요. 사람들이 청킹이 끝났다고 말하는 이유는 이제 누구나
00:01:30에이전틱 검색을 사용하기 때문입니다. grep, ls, find 명령어가 있죠. 다 훌륭하지만
00:01:36데이터가 방대하고 쿼리가 다양하다면 이것만으로는 여전히 충분하지 않습니다.
00:01:46잠시만요. 좋습니다. 많은 이들이 청킹에 대해 이야기하기 싫어하는 주된 이유는
00:01:51재미있는 부분이 아니기 때문일 겁니다. 모든 RAG나 파일 시스템에는
00:02:00두 단계가 있습니다. 첫 단계는 말하자면 지루한 단계인데요. 초반에 작업하는 단계로,
00:02:07방대한 데이터를 전처리하고 청크 크기를 결정해야 합니다. 그런 다음에는
00:02:13모든 것을 벡터 DB에 저장해야 하죠. 반면 다른 부분은 검색 단계인데, 기본적으로
00:02:20쿼리마다 발생하는 작업입니다. 이건 훨씬 다루기 쉽죠, 그렇죠? 최적화하기가
00:02:25훨씬 수월합니다. 다양한 쿼리를 사용하면서 max K, 아니 top K 값을 조절해 볼 수도 있고
00:02:32하이브리드 검색 같은 걸 시도해 볼 수도 있죠. 검색 튜닝을 만지는 편이 훨씬 재미있지 않습니까?
00:02:40그래서 저는 무언가를 끝내야 한다면, 무언가 생명을 다해야 한다면 그건 아마도
00:02:47검색 튜닝일 것이라고 주장합니다. 맞습니다, 에이전틱 검색이 아마 그걸 없앴을 겁니다. 하지만 에이전틱 검색이
00:02:55검색 튜닝을 대체했다는 사실을 인정하더라도 데이터가 방대할 때는 여전히 역부족입니다.
00:03:02비용도 많이 듭니다. 이 부분은 굳이 더 언급할 필요도 없겠죠. 토큰 맥싱은
00:03:09요즘 모두가 이야기하는 문제입니다. 게다가 그 이면에 깔린 근본적인 문제는, 데이터 자체가
00:03:17폴더나 디렉터리에 적절한 방식으로 정리되어 있지 않다면 여전히 비효율적인 결과가
00:03:25초래된다는 점입니다. 시의적절한 예시를 한번 생각해 볼까요? 지금 FIFA 월드컵 기간이죠.
00:03:33FIFA 월드컵에 관한 모든 정보가 담긴 데이터셋이 있다고 상상해 봅시다. 각 디렉터리가 가령
00:03:4098년도, 2002년도 등등으로 구분되어 있다고 해보죠. 그런데 질문이 “어느 팀이 월드컵에서 가장 많이
00:03:50우승했는가?”라면 폴더 하나만 열어서 접근할 수는 없습니다. 모든 폴더에 들어가 누가 우승했는지 확인한 뒤
00:03:57취합해야 하니 매우 비효율적이죠. 바로 답을 드리자면 브라질입니다, 적어도
00:04:03이 발표가 진행되는 시점 기준으로는요. 그러니 검색은 실제로 끝난 게 아닙니다. 오늘 강연에서
00:04:13무언가의 명줄을 끊으려는 건 아니고요. 검색은 일종의 배관 작업(Plumbing)처럼 변했습니다. RAG 시스템을
00:04:21다뤄본 분이라면 다들 이 기분을 아실 텐데요. 첫날, 첫 주, 철저한 분이라면 첫 달쯤에
00:04:29적당한 청크 크기를 하나 정합니다. 예를 들어 512 정도로요. 그리고 아마 오버랩을
00:04:3610%, 20% 정도 준 뒤 전부 인덱싱하고는 완전히 잊어버리죠. 고정 크기 청킹 전략에 대해
00:04:43이야기를 많이 나누는데, 만약 청크 크기가 너무 크다면
00:04:49전체적인 그림을 파악하기엔 좋겠지만 세부적인 뉘앙스를 많이 잃게 됩니다. 그리고 모든
00:04:54청크가 유의미한 임베딩을 얻지 못하겠죠. 반대로 청크 크기를 너무 작게 설정하면
00:05:00전체적인 맥락을 놓치게 됩니다. 실질적인 효율도 떨어지고요. 즉, 이것이 시사하는 바는
00:05:07청킹이란 근본적으로 손실 압축이라는 점입니다. 어떤 방식을 취하든 무언가는 잃게 마련이죠.
00:05:15저는 정답인 청크 크기란 존재하지 않는다고 주장합니다. 데이터를 다뤄보신 분 중 다수는
00:05:23“아니다, 우리에겐 말뭉치와 데이터셋이 있고, 그 데이터에 최적화하여 시스템이
00:05:29아주 잘 작동하도록 맞췄다”고 말씀하시겠죠. 저희도 그렇게 생각했습니다. 다양한 유형의 에이전트와
00:05:35시스템, 워크플로를 다루며 풍부한 경험을 쌓았으니까요.
00:05:40벤치마크를 떠올려보면 모델을 특정 벤치마크에 과적합시키는 건 얼마나 쉬운 일입니까?
00:05:48하지만 RAG에서는 그렇게 되지 않습니다. 데이터셋별로 완벽히 최적화할 수가 없죠. 저는 청킹이
00:05:54쿼리 의존적이라는 것을 확인하는 방법을 보여드리고자 합니다. 제가 어떻게 이렇게 확신하며 주장할 수 있을까요?
00:06:00직접 실험을 거쳐 검증했기 때문이며, 이제 그 결과를 보여드리겠습니다. 그래서 저희는
00:06:06데이터별 최적의 청크 크기가 무엇인지 추측하는 대신 직접 확인해 보기로 했습니다. 데이터셋을 하나 가져와
00:06:14여러 번 복제했죠. 이 실험에서는 6벌을 만들었습니다. 복제본마다,
00:06:23즉 각 인스턴스마다 청크 크기를 다르게 설정했습니다. 청크 크기 2,000짜리 데이터베이스,
00:06:281,000짜리 데이터베이스 등을 구축한 것이죠. 이를 여러 데이터셋에 걸쳐 적용했습니다.
00:06:36회의록 데이터셋인 QMSUM, 소설 기반 질의응답 데이터셋인 Narrative QA,
00:06:41그리고 '아무것도 아닌 것'에 관한 퀴즈인 사인펠드(Seinfeld) 데이터셋까지요. 사실 농담이고,
00:06:49시트콤 사인펠드의 대본에 관한 퀴즈 질문들입니다. 저희가 자체 제작한 일종의 장난스러운 데이터셋이죠.
00:06:56끝나고 링크를 원하시면 공유해 드릴 수 있도록 공개도 해두었습니다. 이 모든 데이터셋에서 어떤 결과가 나오는지 테스트했습니다.
00:07:03우선 각 데이터셋마다 어떤 청크 크기가 가장 적합한지 확인하고자 했습니다. 지금
00:07:10보시는 것은 사인펠드 데이터셋의 예시인데요, 본질적으로 성격이 다른
00:07:16두 쿼리가 청크 크기에 따라 서로 다른 결과를 얻는 모습을 보여줍니다. 첫 번째 질문은
00:07:24“제리가 가장 좋아하는 셔츠의 이름은?”입니다. 보시다시피 매우 집중되고 구체적인 질문이죠.
00:07:28이에 대한 답변 역시 매우 제한적인 범위에 있을 것입니다. 이런 질문은 청크 크기가 작을 때
00:07:33가장 성능이 좋습니다. 100토큰 고정 청크 크기에서 순위 1위를 차지한 반면,
00:07:43다른 크기에서는 50위 밖으로 밀려나는 것을 볼 수 있죠. 반면 “제리가 자신의 숙적이자 순수한 악이라고 묘사한 인물은 누구인가?”라는 질문은,
00:07:50저도 사인펠드의 대단한 팬은 아니지만 답이 뉴먼이라는 건 알고 있습니다. 하지만 대본 전체를
00:07:56살펴보면 그렇게 쉽게 찾을 수 있는 내용이 아닙니다. 결과가 확연히 달라지는 게 보이시죠? 작은 청크
00:08:02크기를 사용하면 답을 찾지 못합니다. 그래서 이 모든 실험을 수행한 후 저희가 취한 방식은,
00:08:10“만약 각 쿼리마다 검색에 가장 적합한 청크 크기를 알려주는 오라클, 일종의 요정이 있다면 어떨까?”라는 가정을 해본 것입니다.
00:08:19그게 바로 이 오라클 실험입니다. 최대 잠재력을 확인해 보고 싶었기 때문이죠. 이건 당장 구현 가능한 시스템을
00:08:25구축하겠다는 것이 아니라, 우리가 얻을 수 있는 잠재력이 어느 정도인지 확인하려는 의도였습니다.
00:08:33여기 그래프에서 보시는 것처럼, 우선 y축은 재현율(Recall)이며 높을수록 좋습니다.
00:08:38x축은 검색된 청크의 수입니다. 즉 k에 따른 Recall@k를 나타내죠. 파란색 선들은
00:08:46서로 구분하기 어려울 수 있지만, 각각 특정 고정 청크 크기의 성능을 의미합니다.
00:08:52반면 주황색 선은 오라클 곡선입니다. 매 쿼리마다 이 크기들 중 가장 최적의 크기를 선택한 결과죠.
00:09:01이러한 현상이 여러 데이터셋에 걸쳐 동일하게 나타납니다. 수많은 데이터셋에서 파란색 선들이
00:09:09서로 교차하는 것을 볼 수 있는데, 이는 특정 청크 크기 하나가 항상 우세하지는 않음을 뜻합니다.
00:09:16더 흥미로운 점은 잠재력이 엄청나다는 것입니다. 주황색 선과 다른 파란색 선들 사이의
00:09:24격차가 매우 큽니다. 크다고 말씀드린 건, 단지 청킹 전략 하나만으로
00:09:3020~40%가량 차이가 난다는 뜻입니다. 그것도 매우 단순한 전략을 썼을 때 말이죠.
00:09:38이 격차가 바로 512나 1,000 같은 임의의 수치를 선택했을 때 치러야 하는 대가입니다.
00:09:47여기서의 문제는 조금 까다로운데, 각 단계에서 필요한 정보가 부족한 정보 문제에 가깝기 때문입니다.
00:09:56무슨 뜻이냐 하면, 청크 크기를 제어할 수 있는 인덱싱 단계에서는
00:10:07어떤 쿼리가 들어올지 알지 못합니다.
00:10:12추측하거나 가늠해 보고 시도할 수는 있어도 어떤 쿼리일지 확신할 수 없으니
00:10:18청크 크기를 그에 맞춰 조정할 수가 없습니다. 반대로 쿼리가 주어지는 검색 단계에서는
00:10:25청크 크기를 조절할 수 없죠. 이미 고정되어 있으니까요. 매 쿼리마다 전체
00:10:31프로세스를 처음부터 다시 수행할 수도 없는 노릇이고요. 그래서 저희는 각 청크를 강화하는 Anthropic의
00:10:37콘텍스추얼 검색(Contextual Retrieval) 같은 선행 연구나, 각 청크의 잠재 공간(Latent Space)을 개선하려는
00:10:47다른 시도들을 살펴보았습니다. 하지만 저희가 택한 방향은 그게 아니었습니다. 그 연구들은 모두
00:10:54고정된 청크 크기를 사용하는 틀 안에 머물러 있었던 반면, 저희는 다른 접근 방식을 취했죠.
00:11:01하나만 고집할 필요 없이 여러 개를 사용하면 되지 않겠습니까? 저희는 이를 '멀티스케일 인덱싱'이라 부릅니다.
00:11:08기본적으로 앞서 보셨던 방식을 그대로 적용한 것인데요. 데이터베이스를 확인한 뒤
00:11:16이를 복제하여 다양한 청크 크기나 윈도우 크기로 분할합니다. 이것이 인덱싱 단계에서 일어나는 일이고,
00:11:26검색 시점에는 그 모든 인덱스를 대상으로 쿼리를 날립니다. 즉 n개의 데이터베이스 복제본과 윈도우 크기가 있다면
00:11:34이제 쿼리당 6개의 서로 다른 검색 호출을 실행해야 합니다. n이 6이라고 할 때요.
00:11:43그렇다면 이 결과들을 어떻게 병합할까요? 당연히 오라클을 쓸 수는 없습니다, 맞죠? 오라클은 잠재력을 확인하기 위한 것일 뿐,
00:11:52실제 환경에서는 정답을 알지 못하니까요. 대신 저희가 할 수 있는 일은 적절한 병합 알고리즘을 찾는 것입니다.
00:11:57이렇게 보면 어떤 문제가 발생할 수 있는지 궁금하실 텐데요. n개의 순위 결과가 나오지만
00:12:06그 순위는 청크들에 대한 순위라는 점입니다. 서로 다른 크기의 청크는 직접적인 비교가
00:12:13어렵죠, 그렇지 않나요? 그래서 저희는 요즘 꽤 널리 쓰이는 방식을 택했습니다.
00:12:19실제로 많은 RAG 시스템이 이렇게 동작하는데, 청크만 가져오는 대신
00:12:25RAG 시스템이 실제로 이렇게 작동하는데, 청크만 검색하는 대신 청크를
00:12:30가져올 때 문서 전체를 검색하는 방식이죠. 컨텍스트 창이 커짐에 따라 더 많은
00:12:35컨텍스트를 제공하고자 하니까요. 이제 이 경우에는 더 이상 청크 단위가 아니기 때문에
00:12:44동일한 문서들에 대한 n개의 순위가 생성됩니다. 이건 서로 비교가 가능하죠. 이 경우 검색은 본질적으로
00:12:50투표와 같다고 생각하시면 됩니다. 순수하게 하나의 랭킹만 매기는 게 아니죠. 하나의 랭킹을 매긴 뒤
00:12:56재순위화하는 것이 아니라, 관련 문서들에 대해 n개의 서로 다른 순위를 얻고 이를
00:13:03하나로 종합하는 것입니다. 그래서 저희는 꽤 단순한 공식인
00:13:11RRF(상호 순위 융합)라는 방식을 사용하고 있습니다. 여러 시도를 해봤지만 이게 가장 효과적이었죠. 보시다시피 이건
00:13:17별도의 모델이 아닙니다. 특별히 복잡한 작업을 거쳐야 하는 것도 아니고요. 그저 실행하는 데
00:13:23시간이 전혀 걸리지 않는 간단한 스크립트일 뿐입니다. 전체 시스템의 구성은 이렇습니다. 우선
00:13:32인덱싱을 n번 수행하고, 모든 데이터베이스에서 각 쿼리를 검색한 뒤 RRF를 사용해 이를 하나로
00:13:40통합합니다. 그리고 결과는 예상하시겠지만 아주 좋습니다. 그렇지 않았다면 제가 여기에 서서
00:13:48이렇게까지 자신만만하게 말하지 못했겠죠? 보시다시피 QMSum,
00:13:56Narrative QA, Seinfeld, Finance Bench 등 여러 데이터셋에서 테스트했습니다. 이 모든 데이터셋에서 저희 방식은 최고 성능의
00:14:05고정 크기 청크와 대등하거나 이를 능가했습니다. 그래프로 살펴보죠. 여기서는 조금 보기 어려우니 천천히 설명해 드릴게요. 각 행은
00:14:12청크 크기입니다. 50, 100 등 여러 수치가 보이죠. 맨 아래 행이 저희 방식입니다. 모든 크기에서
00:14:21검색한 뒤 하나로 결합하는 방식이죠. 그리고 각 열은 특정 k 지점에서의 재현율입니다. 즉, Recall@1부터
00:14:312, 3, 최대 10까지를 나타냅니다. 여기서 확인할 수 있는 점은 두 가지입니다. 우선 어떤
00:14:39Recall@k 기준에서도 저희 방식이 여전히 앞선다는 것입니다. 당연해 보일 수도 있지만, 이 모든 것을
00:14:46하나로 결합해야 한다는 점을 고려하면 결코 단순한 일이 아닙니다. 또한 검색 품질이
00:14:53실제로 향상된다는 점도 확인할 수 있습니다. 히트맵을 보면 훨씬 더 짙은 초록색을 띠고 있죠. 다시 말씀드리지만 이건
00:14:58크게 확대해서 보여드리고 싶었던 것뿐입니다. 여기 보시는 4개의 데이터셋 모두에서 저희는
00:15:06더 나은 결과를 얻었습니다. 여러 항목에서 실제로 20%, 30%, 심지어 40%까지 향상되었죠. 또한 여기에는
00:15:14보여드리지 않았지만 MTab에 대한 결과도 있습니다. 나중에 링크를 공유해 드릴 저희 블로그에서 확인하실 수 있는데,
00:15:22거기서도 데이터셋에 따라 약 10%에서 40% 사이의 상당한 성능 향상을 보였습니다.
00:15:30그렇다고 제가 순진하게 이 방식에 아무런 비용이 들지 않는다고 주장하려는 건 아닙니다. 당연히 대가가 따르죠.
00:15:36세상에 공짜 점심은 없으니까요. 모든 것에는 트레이드오프가 있습니다. 맞습니다, 추가 메모리가 필요합니다.
00:15:43데이터베이스의 사본들을 모두 보관해야 하므로 상수 배율로 약 2배에서 5배, 즉 O(1) 수준의
00:15:51추가 메모리 비용이 발생합니다. 하지만 지연 시간 관점에서 생각해 보면, 이에 따른 영향은
00:15:59거의 없습니다. 검색 과정을 모두 병렬로 처리할 수 있고, RRF 단계 자체도 시간이 거의 걸리지 않기 때문입니다.
00:16:10이번 연구는 저희가 진행한 매우 흥미로운 프로젝트였고, 정말 멋진 결과를 얻었다고 말씀드리고 싶습니다.
00:16:16물론 개선할 부분도 있습니다. 보완해야 할 점도 있고 향후 연구 과제도 남아 있죠. 구체적으로는
00:16:23얼마나 많은 청크 크기가 필요하고 어떤 크기를 선택해야 하는지 알아내고자 합니다. 50, 100,
00:16:32200 등으로 설정했던 건 솔직히 꽤 자의적이었습니다. 따라서 이를 어떻게 계산할지,
00:16:40정확히 몇 개의 복사본이 필요한지 파악하는 방법이 필요합니다. 또한 RRF를 넘어서는 방법도 찾아야겠죠.
00:16:46저희가 RRF를 쓴 것은 시도해 본 방법 중 가장 효과적이었기 때문이지, 이것보다 더 나은 방법이
00:16:52없다는 뜻은 아니니까요. 마지막으로 여러분께 전하고 싶은 메시지가 있다면, 에이전트가 등장했다고 해서 검색이
00:16:59끝난 건 아니라는 점입니다. 사라진 것은 아무것도 없습니다. 인프라일 뿐이죠. 안타까운 점은 그것이
00:17:072022년 수준의 인프라라는 것입니다. 매우 간단한 방법만으로도 기존 RAG 시스템이나 데이터를
00:17:17저장하고 검색하는 모든 시스템의 성능을 지나치게 복잡한 기법 없이도 20%에서 40%까지 끌어올릴 수 있습니다.
00:17:26자세한 내용이 궁금하시다면 블로그를 확인해 보세요. 예제 코드와
00:17:34Seinfeld 데이터셋도 함께 공개되어 있습니다. 여기까지입니다. 저는 유발이었습니다. 참석해 주셔서 정말 감사합니다.
00:17:47다음에 또 뵙겠습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기