Retrieval Augmented Generation at Planet Scale 아티클
논문은 아니고, RAG 관련 글에 대한 번역
Sep 14, 2023
논문은 아니고, RAG 관련 글에 대한 번역
LLM Application에서 어떤식으로든 해자를 만들어낼 수 있는게 있을 까 혹은 결국 모델만이 해자가 될 수 있을까(모델 학습을 위한 데이터도 포함)에 대한 생각이 있었는데, 마침 RAG를 좀 더 깊게 고민해본 글이 있길래 읽어봤다.
![notion image](https://inblog.ai/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fhttps%253A%252F%252Fprod-files-secure.s3.us-west-2.amazonaws.com%252F6886ba6d-9c8b-4735-8263-f5137e1473ea%252F321a0ed7-0e83-42e0-8223-8f5ce39091d1%252FScreen_Shot_2023-09-13_at_11.03.40_PM.png%3Ftable%3Dblock%26id%3D4629b2cf-57cf-4c3f-9644-10dca149a052%26cache%3Dv2&w=3840&q=75)
무슨 회사인지는 정확히 모르겠는데 유저의 입력 프롬프트를 받아서 더 잘 수행하기위해 가해지는 모든 테크닉을 Prompt Enrichment라고 이름 붙였다.
Prompt Enrichment(RAG라고 봐도 될 듯 하다)는 유저가 관련있는 좋은 퀄리티의 데이터를 외부 혹은 내부 데잍서 소스에서 가져와서 컨텍스트에 추가해주는 것을 의미한다.
여기서는 유저의 내부 데이터 저장소 뿐만 아니라 외부에서, 큰 스케일로 RAG를 한다.
이 과정을 통해서, 우리는 자연스럽게 RAG의 스케일 확장 문제에 맞닥뜨린다. 본 아티클에서는 LLM을 위해서 planet-scale로 데이터 리트리벌을 해야하는 시나리오를 다룬다.
유저에게서 자연어를 입력으로 받아 답변을 생성해내는 LLM은 항상 필요한 정보를 가지고 있지 않기 때문에 Augment가 필요하다.
Hallucination도 방지할 수 있다.
![notion image](https://inblog.ai/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fhttps%253A%252F%252Fprod-files-secure.s3.us-west-2.amazonaws.com%252F6886ba6d-9c8b-4735-8263-f5137e1473ea%252F275f7674-bd83-4f3c-8bd2-fd8823fa5396%252FScreen_Shot_2023-09-13_at_11.13.51_PM.png%3Ftable%3Dblock%26id%3Da169182f-e99a-4f2d-80a8-a24344f1ff5a%26cache%3Dv2&w=3840&q=75)
RAG는 보통 embedding search와 함께 구현된다. 텍스트는 벡터로 벡터디비에 저장되고 query와의 similarity에 따라 retrieval 된다. 즉, semantic meaning에 따라 찾게된다.
하지만 텍스트 임베딩 모델은 context window 제한이 있기 때문에 전체 문서가 아니라 text snippet을 임베딩 할 수 밖에 없다. → chunk 단위로 잘리고, 임베딩 되어 저장된다.
이렇게되면 retrieve된 청크가 context에 추가되어 LLM이 답변하는데 이용된다.(아래그림)
![notion image](https://inblog.ai/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fhttps%253A%252F%252Fprod-files-secure.s3.us-west-2.amazonaws.com%252F6886ba6d-9c8b-4735-8263-f5137e1473ea%252F5bafa10e-4384-4d2d-acff-5ce38db85657%252FScreen_Shot_2023-09-13_at_11.18.12_PM.png%3Ftable%3Dblock%26id%3D3bc1e7c2-0e55-47f8-a480-f73102266d06%26cache%3Dv2&w=3840&q=75)
여기서 문제! 문서가 한두개가 아니라 billion 단위라고 생각해보자. 이러면 몇가지 문제가 생긴다.
Incomplete Content Representation: 잘린 청크는 전체 문서의 정보를 포함하지 못하고 일부분의 정보만 갖게된다. 이건 context, 정보가 소실되는 것과 같다.
법 관련 문서라고 했을 때, 사건에 대한 정보와 판결에 대한 정보가 각각 다른 청크에 들어가게 되면 1) “어떤 상황에서 어떤 판결을 내린다”라는 정보는 손실될 수 있다. 혹은 2) 같은 판결이라도 어떤 재판의(문서) 판결인지 정보가 손실된다.
Inaccurate Chunk Similarity Search: 데이터의 양이 많아지면 retrieval 시 노이즈가 exponential하게 증가한다. 이건 성능 향상을 일으킨다. 맞는 말이다.
Arcus에서 생각한 방법
Multi-tiered Approach
두가지 스테이지로 나누어서 연관있는 청크를 찾게된다. 첫번째 티어는 각 문서(전체가 요약된 벡터)가 되고, 두번째 티어는 문서안의 각 청크가 된다.
찾을 때도 우선 관련있는 문서를 찾고, 그 안에서 또 관련있는 청크를 찾게 된다.. 전통적인 DB의 인덱싱, k-NN 방법과 비슷하다. 두개의 티어가 아니라 여러개의 티어로도 할 수 있다. 2)의 문제는 해결되었지만, 1)의 문제는 해결 안되었네
![notion image](https://inblog.ai/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fhttps%253A%252F%252Fprod-files-secure.s3.us-west-2.amazonaws.com%252F6886ba6d-9c8b-4735-8263-f5137e1473ea%252F5e981b0f-c0eb-4a5d-818d-b342248a1de1%252FScreen_Shot_2023-09-13_at_11.25.48_PM.png%3Ftable%3Dblock%26id%3D2e9dc7c9-8a0c-4479-aec8-ff97d3b82ded%26cache%3Dv2&w=3840&q=75)
Semantic Tiering
위 처럼 티어를 나눌 때, semantic information에 따라서 나눈다. 단순히 문서단위로 구성하는게 아니라, 서로 다른 문서안의 청크더라도 의미적으로 같은걸 얘기하면 큰 카테도리 아래에서 묶는다. 혹은 문서 단위에서 비슷한 문서끼리 묶는다.
쓰리 티어 시스텀을 예로 들면 첫 번째 계층을 사용해서 검색 공간을 문서가 속하는 주제와 카테고리로 좁히고, 두 번째 계층을 사용하여 관련 주제 또는 카테고리에 대한 개별 문서를 검색하고, 마지막 계층을 사용하여 해당 문서에 대한 개별 청크를 검색한다.
이렇게 되면 문제는 어떻게 그룹을 구성할 것이냐가 된다. 의미를 잘 추출해서 그룹을 잘 구성할수록 성능이 좋아진다.
예시)
![notion image](https://inblog.ai/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fhttps%253A%252F%252Fprod-files-secure.s3.us-west-2.amazonaws.com%252F6886ba6d-9c8b-4735-8263-f5137e1473ea%252F10b0c1a5-571d-458e-832b-0b6e925c22f2%252FScreen_Shot_2023-09-13_at_11.31.24_PM.png%3Ftable%3Dblock%26id%3D705c5964-70ea-4249-b18d-ebea37af7ab8%26cache%3Dv2&w=3840&q=75)
결국 retrieval을 잘하기 위한 방법들에 관한 정보였다. 크게 특별한게 없었네
Share article
Subscribe to our newsletter