[SK TECH SUMMIT 2023] RAG를 위한 Retriever 전략

👉 영상: [SK TECH SUMMIT 2023] RAG를 위한 Retriever 전략

👉 발표 자료: https://sktechsummit.com/sessions/sessionsList.do

SK TECH SUMMIT 2023

---

연사자

Allganize AI ICT 융합 CAIO(Chief AI Officer)

---

강의 내용

1. Retrieval Augmented Generation

2. RAG가 왜 어려운가?

3. Document parsing - Table

4. Retriever 전략

---

1. Retrieval Augmented Generation

✅ RAG는 2021년(GPT 3 시절) 등장한 개념. 등장 당시에는 생성은 하나, 놀라운 성능 보이지 못했음

✅ OpenAI에서 모델 발표한 이후, Generator 성능 엄청나게 높아지며 활용 가능성에 관심 🆙

✅ 기업 내부 문서, 나만이 알고 있는 문서에 대한 답변 생성 등의 측면에서 도입 고려

---

✅ 프롬프트에 내가 물어본 질문 답변 후보들을 프롬프트에 집어넣는 방식

✅ 문제? 기업 내부 문서 기반 답변은 잘 되지 않음

✅ 어려운 이유? 리트리버 성능 잘 안 나옴. + 간과되고 있는 Document parsing

---

2. RAG는 왜 (아직도) 어려운가?

OpenAI Assistant API - Retrieval

✅ OpenAI에서 Assistant API에 Retrieval 발표

✅ (좌측) 전자장치 부착명령 법령 문서를 (우측) OpenAI Assistant API 활용한 결과, 사용자 질문에 답변 잘 못해주고 있음

✅ 표에 기입된 숫자 내용 틀리고(2008년 미부과 건수는 250건, 2012년 3,213 건으로 증가), 답변 내용도 틀림

✅ 왜 OpenAI인데도 성능이 좋지 못할까? 📄 문서의 문제

---

Internal Document(다루는 문서)

✅ 주요 기업 내부 문서? PDF, Word, Excel, 아래 한글 등

---

✅ 문서 작성용이 아닌 조판용 시스템(출력용 시스템)

✅ 레이아웃 알 수 없음

✅ Header, Footer 정보 없고, 목차(Table of Contents, ToC)는 가끔 메타 정보로 존재하나, 없는 경우가 대부분

✅ Table? 그냥 글씨에다가 그림 입혀놓은 것

---

✅ 조판 시스템인 PDF 보다는 낫지만, 현실에서 마주하는 기업용 문서는 사실상 조판 시스템과 동급

✅ 워드 문서 열어보면 제목도 있고, 시스템적으로 정리되어 있지만, 눈에 보이게만 그렇게 만든 문서들 상당히 많음

✅ 테이블? merged cell 많음. 예쁘게 align 맞추기 위해 테이블이 아닌데 테이블 안에 글씨 집어넣기도 함

 

---

✅ 태생이 Table인 엑셀도 마찬가지

✅ Table이 Table이 아님

➡️ 이런 문서들 가지고 답변해야 함. 글 위치도 모르고, Table 인지도 모르는 상태에서

---

OPENAI Assistant API - Retrieval

💡 이런 문제점 OpenAI에서도 똑같이 겪고 있었을 것

✅ citation이 깨지지 않는 CUDA API 문서 올려놓고 질문했더니 citaton이 잡힘

✅ citation 잡는 방식? 문서 목차 부분 찾아서 페이지 번호 제거. 일부분만 잘랐는데, 의미 있는 부분 자르지도 않음

✅ 잘 작동하지 않음

---

Alli Generative Answer

✅ 자사 제품인 Alli에 적용했더니 잘 나옴

✅ 답변 잘 나오기 위한 노하우? 문서 이해할 수 있는 방법,  굉장히 많은 노하우, 꼼수로 점철되어 있음 

---

3. Document parsing - Table

Table - Markdown

💡 Table 어떻게 다룰 것인가?

✅ OpenAI에 Table 넣을 때, 마크다운(Mark Down, MD) 형태로 넣으면 동작 잘 됨(많이 알려져 있음)

✅ 하지만, Table 조금만 커져도 답변 잘 되지 않는 상황 봉착

✅ 실제 다루는 문서 Table 안에는 숫자뿐 아니라 글(enter, 특수 문자 등)이 포함되어 있어 MD 포맷이 깨짐

---

Table - Natural Language

💡 Table을 말처럼 싸볼까? 자연어로 처리

✅ Header만 알 수 있다면, 테이블 내용을 말로 기계적으로 설명하는 형태로 만들 수 있음

✅ 기계적으로 테이블을 자연어로 만들었을 때, 답변 품질 역시 올라가는 모습

✅ 장점? Merged cell, 큰 테이블, 복잡해진 Table에 대해서도 Header만 제대로 잡을 수 있다면 쉽게 처리가 가능

✅ 뒤에 설명할 리트리버에서도 더 좋은 성능 보임

---

Table Pipeline

✅ Table 다루기 위해서는 문서를 이해하는데 필요한 위의 다양한 기술들 들어갈 수밖에 없음

1️⃣ Table Detection: Table이 어디 있는지 확인

2️⃣ Table Recognition: Table 있는 영역을 셀 단위로 잘 뜯어서 구축

3️⃣ (Simple) Make markdown: 표가 간단할 경우 마크다운으로 처리

3️⃣ (Complex) Header detection: 표가 복잡할 경우, 헤더 탐색(일반적으로는 첫번째 열이지만, 일상에서는 merged cell, 헤더가 복수인 경우, 열 중간에 들어가는 경우 등)

---

4. Retriever 전략

✅ 문서 적당한 크기로 자르고, unstructured 데이터를 structure 잘 이해할 수 있도록 변경

✅ 질문했을 때, 질문에 답변이 될 만한 것들을 찾아 프롬프트에 넣어줘야 함

Retriever - Sparse retriever

💡 답변이 될 만한 내용 어떻게 찾을까?

✅ 가장 간단한 건 ES(Elastic Search)에 물어보는 것

✅ 등장한 키워드가 나오는 거니까 직관적으로 이해가 감

✅ 질문이 꼭 키워드가 나온 곳에서만 나올 수 없음

✅ Sparse retriever 한계 명확 -> Dense retriever들이 나옴(DPR - Dense Passage Retrieval, OpenAI Embedding) 

✅ 데이터셋별로 상이. 어떤건 BM25가 성능 좋고, ensemble이 좋을 때도 있고 등 

 

---

Retriever - Ensemble

그래프 - 색	설명
*BM25 - 파란색	Base Model
Embedding(Text) - 빨간색	OpenAI Embedding
Ensemble(BM25 + Text) - 노란색	BM25 + Text
Ensemble(BM25 + Text + Title) - 초록색	제목까지 앙상블

키워드 기반 랭킹 알고리즘 "BM 25"

참고: BM25

주어진 Query에 대해 문서와의 연관성 평가하는 랭킹 함수로 사용되는 알고리즘

BM25 Score 산출식(출처: https://velog.io/@jkl133/BM25)

TF-IDF(Term Frequency-Inverse Document Frequency) 계열 검색 알고리즘 중, SOTA(State-of-the art)

TF-IDF는 한 문서에서 단어가 등장하는 빈도 높을수록 커지고(term frequency), 해당 단어를 포함하는 문서가 많을수록 반비례해서 작아짐(inverse docoument frequency)로, 현재 단어의 가중치 계산할 때 가장 자주 쓰이는 값

✅ 고객들의 문서, 질문 수집해 벤치마크 진행한 결과인데 결과가 천차만별

✅ 고객 문서, 질문에 따라 weight 자동으로 조절할 필요 있음

✅ 실제 현업에서 적용하기에는 어려움 있음

---

Retriever - Training Dense retriever

💡 DPR(Dense Passage Retriever) or Retriever 학습 현실 세계에 적용할 수 없을까❓

학습 방법 크게 2가지

1️⃣ Cross-Encoder

✅ 질문, context가 1개의 모델에 들어가서 답변 나오는 것

✅ 컨텍스트가 수십만~수백만 개인데 실시간으로 들어오는 질문마다 모델에 다 태운다는 것? 불가능

➡️ 애초에 Cross-Encoder는 고려 ❌

2️⃣ Bi-Encoder

✅ 질문, context가 각각 다른 모델에 들어가서 계산된 다음, 나중에 합쳐지는 방식

---

💡 Bi-Encoder는 모델 학습 잘 시킬 수 있을까?

✅ 성능 좋은 모델 배포해도 시간이 지나면 모델 재학습할 필요성 생김

✅ 10만개 되는 context vector, 100만 개 되는 context vector 다 업데이트하는 것은 사실상 어려움

✅ context 쪽 vector 역시 학습이 불가능함

---

 

✅ 위의 그래프 같은 모양이 될 수밖에 없음

✅ Question 쪽만 학습이 되는 구조

---

Retriever - Train data

💡 학습 데이터 만들기도 문제 

✅ 정답 데이터셋? 질문과 질문의 후보를 만드는 것(🐓닭과 🥚달걀의 문제)

✅ 리트리버가 똑똑하다면 대부분 맞출 거고, 틀린 것만 걸러내도 굉장히 좋은 답변 set 만들어낼 수 있음

✅ 하지만 보통 데이터셋 만드는 이유? 성능 안 좋아서 학습시키려고 학습 데이터셋 만드는 것

 

✅ 사람에게 질문 만들라고 하면 엄청 힘듦 -> GPT로 데이터 대량 생산 -> 근데 Negative 데이터는 어떡하지?

✅ GPT에게 "이 페이지에서 답변이 나오지 않을 만한 질문을 생성해 봐" 요청하면 답변 잘 나오지 않음

✅ Positve data는 GPT로 대량 생성 가능한데, Negative data는 생성이 어려움

 

✅ 1번 페이지에서 만든 정답을 2번 페이지 negative sample로 사용할 수 있지 않을까? 안됨. 사람 눈으로 하기에는 필요한 데이터가 너무 많음

✅ 그렇다 보니 Loss function은 벡터끼리 비교하는 MSE나 cosine embedding loss 지표 사용할 수밖에 없음

✅ binary-crossentropy 같은 경우로 사용하면 모델이 망가질 수밖에 없음. 왜냐하면 positive sample밖에 없으니까

---

Retriever - 이게 되는 거 맞나?

💡 실제로 진행해 본 결과

🟥: Question Embedding(질문에 대한 임베딩)

🟦: Context Embedding(문서에 대한 임베딩)

✅ Baseline은 OpenAI Embedding. 이유? 성능이 제일 좋아서가 아니라 context window가 제일 길어서

✅ (좌측) 2차원으로 PCA(차원 축소) 진행한 결과-> 명확하게 갈라져 있음

➡️ 빨간색을 파란색 쪽으로 보낼 수 있다면, 모델이 작동할 수 있겠다라는 생각

✅ (우측) 초록색이 실제로 모델 통과한 question 벡터들 

---

Retriever - 결과

✅ 결과는 데이터셋 종류에 따라 많이 달라질 수 있음

✅ 현실적으로는 Top-3나 Top-5 넘어갈 수 없음

✅ 논문에는 Top-100가 있긴 한데, 실제 환경에서는 prompt 넣어주는 것, 비용까지 고려해야 함

✅ 현실적으로 Top-3, Top-5 정도가 한계인데, 5~ 10% 정도 리트리버 성능 향상할 수 있었음

✅ 위의 결과는 앙상블 전으로, 앙상블하면 더 좋은 성능 개선 기대할 수 있을 것 

 

---

정리

1️⃣ LLM 뛰어날수록 Document parsing과 Retrieval 단계 중요(현주소)

✅ Retriever 성능이 Generative answer에서 중요한 component 되고 있음

---

2️⃣ 세상의 문서 형태는 다양해 형태별로 많은 노하우 필요

✅ 특히, 기업용 문서의 경우 경험이 많이 필요

---

3️⃣ Retriever는 sparse / dense ensemble로 갈 수밖에 없음

✅ 리트리버는 임베딩 사용하는 것보다는 앙상블 해야 됨

✅ 앙상블로도 성능 향상이 안된다면 train 해야 함

---

4️⃣ 그럼에도 불구하고, 문서/질문 set 구성 방식은 상황별로 다름

✅ 실제 데이터는 굉장히 많고, 지저분하고, 업데이트에 제약이 많음

---

5️⃣ (현실적으로) Trainable 한 dense retriever 구조는 제약 있을 수밖에 없음

✅ 학습할 수 있는 형태 자체에 많은 제약 있을 수밖에 없음