Track3) QnA 시스템 개발 실제 적용사례(작성중)

소개

S사 모바일 보안 솔루션의 SDK개발자 가이드 검색 시스템

다양한 어플리케이션별로 제작에 필요한 모바일 디바이스의 API 메소드 정보를 제공

 

 

문제정의

1. 고객 특화(Customer-specific) - 검색의 소스가 되는 것이 고객의 특화데이터(LLM의 학습 과정에서 사용되지 않았던 데이터)에 대한 대응을 할 수 있어야 함 

2. 주기적인 업데이트 정보를 즉각적으로 반영할 수 있어야 함 

3. 답변에는 거짓이 없어야 함

-> 고객특화데이터를 기반으로 거짓이 없는 Q&A시스템을 만드는 것

 

 

해결전략

1, 2. 고객 특화 데이터 및 주기적인 업데이트에 대한 대응

-> RAG(Retrieval Augmented Generation)을 통한 해결

- 고객 특화 문제만 있었다면 파인 튜닝 또한 해결방법이 될 수 있었을 것

- 잦은 업데이트 주기까지 고려하면 파인튜닝보다는 RAG가 적합

RAG에 대한 설명

* RAG란?

- Retrieved Augmented Generation

- 고객에게 특화된 데이터(LLM의 학습과정에서 활용되지 않았던 정보)에 대해서도 잘 대답할 수 있는 Q&A시스템을 만드는 것이 목표였다

- Context를 통해 해결(질문에 대한 답변 정보를 컨텍스트 형태로 LLM에 제공), 학습이 되지 않은 정보에 대해서도 답변할 수 있도록 만듦

- 질문에 대한 컨텍스트를 어떻게 선택하느냐에 대한 이슈가 발생

- 질문과 다큐먼트 간의 임베딩 벡터 유사도를 통해 질문과 연관성이 높은 다큐먼트를 선택할 수 있음

 

3. 거짓없는 응답(Halucination)

- 짧은 시간 동안 엄청난 기술적 진보가 있었음

- 모든 방법을 적용하기보다는 문제에 적합한 해결방법을 잘 선별하는 것을 목표로 함

 

- 활용도가 높은 5가지 패턴

1. Hybrid - Fusion: 시맨틱 서치와 렉시컬 서치를 동시에 활용함으로써 각각의 부족한 부분을 서로 보완해줄 수 있는 형태, 검색 성능을 향상시킬 수 있음 

2. RAG-Fusion: 유저로부터 입력받은 쿼리를 다양한 형태로 변경하여 시맨틱 서치로 진행, 이 과정에서 질의 관점의 다양화를 통해 성능 향상을 이끌고 있음 

3. HyDE: 가상답변을 기반으로 시맨틱 서치를 진행하는 방법, 질의와 답변 사이의 시맨틱 갭을 줄임으로써 성능을 향상시키고 있음

4. parent document: 일반적으로 청크는 그 사이즈에 의해 답변의 퀄리티가 달라짐(ex) 청크사이즈가 작은 경우에는 시맨틱 meaning을 잘 캡쳐할 수 있다는 장점이 있지만, 전체적인 맥락을 놓치는 정보손실이 발생할 수 있음, 반대로 청크사이즈가 긴 경우에는 맥락 정보의 손실을 줄일 수는 있지만 길이의 정보로 인해 각각의 문장의 의미가 희석될 수 있다는 단점이 있음), 이러한 상황에서 Parent Document는 각각의 장점만을 활용함으로써 단점을 극복하고자 하는 방식, 이를 위해 다큐먼트를 페어런츠와 차일드 관계로 구성하고, 이후 검색은 청크사이즈가 짧은 차일드를 대상으로 함으로써 시맨틱 서치 성능을 올릴 수 있고 결과는 매핑되는 페어런츠를 리턴함으로써 정보손실 또한 줄일 수 있음

5. Reranker: 리턴된 다큐먼트들에 대해 query와의 관련성을 다시 한 번 측정하여 context에 들어갈 document의 rank를 바꿔주는 기법, 이 방법은 LLM이 가지고 있는 "Lost in Middle" 문제를 해결하는 데 도움을 주어 성능을 향상시킬 수 있음

 

 

방법

다양한 기법들의 조합에 대한 latency, accuracy와 같은 evaluation index의 비교과정을 통해 최종적으로 선정됨

1. Hybrid-Fusion

- 시맨틱 서치만 통해서 '코끼리 식당'을 검색할 경우, 이용자는 '코끼리 식당'이라는 이름을 가진 식당을 검색하기를 원하지만, 실제로는 단어의 의미에 집중하여 '코끼리'에 관련된 내용이 검색될 수 있음(시맨틱 서치만으로는 완벽하지 않다)

- 시맨틱 서치의 부족한 부분은 Lexical Search를 통해 보완함

* Lexical Search란 텍스트를 기반으로 하는 전통적인 검색, 의미 기반 검색의 단점을 채워줌

- 실제 활용 방법은 하나의 쿼리에 대해 두 가지 방식으로 동시에 검색을 하고, 그 결과를 합치는 방식

- 두 가지 방식을 모두 지원하는 openSearch를 Knowledge base로 활용함

 

2. Reranker 

- Reranker의 필요성을 이해하기 위해서는 LLM이 가지고 있는 특성을 먼저 확인해야 함

- 2023년에 출판된 한 논문에 따르면, 질문에 대한 답변의 정확도는 컨텍스트 내의 정답의 순서와 관련이 있음

- 컨텍스트 내에서 정답의 순위가 내려갈수록 답변의 정확도가 떨어짐 

- 이런 문제를 Lost-In-Middle 문제라고 함

- 질문에 대한 답변의 퀄리티는 컨텍스트 내 정답의 유무뿐만 아니라 그 순서에도 영향을 받는다는 것을 알 수 있음

- 컨텍스트 내에서 정답의 순위가 상위권에 위치할 수 있도록 노력해야 한다

- 이러한 맥락에서 유사도 점수가 얼마나 정교한가 고려할 필요가 있음

- 일반적으로 컨텍스트 내에서 청크들의 순서는 질문과 청크 사이의 유사도를 기반으로 sorting되어 있음

- 이 순서 상에서 과연 상위랭커 문서는 하위랭커 문서보다 질문에 대한 대답을 얼마나 잘할 수 있냐가 문제이다

- 질문과 답변 사이에 semantic gap, Approximation이 들어간 Vector Search방식, bi-encoder 기반의 유사도 계산 방식을 고려했을 때는 그렇지 않을 가능성이 충분히 있다

- 이러한 상황에서 Reranker의 컨트리뷰션은 질문에 대한 정답이 컨텍스트 상위권에 위치할 수 있도록 문서 랭킹을 재정렬하는 데 있음

- Reranker의 구조는 질문과 문서를 나누지 않고 동시에 input으로 피딩을 하는, 크로스 인코더 형태를 띄고 있음

- 이 과정에서 질문과 문서를 통합한 셀프 어텐션을 통해 보다 정교한 관련성 체크가 가능해지는 것

- 이를 통해 관련성 있는 문서를 상위권으로 올릴 수 있게 됨

 

3. Parent Document

- 청크 사이즈에 따른 검색 성능과 정보 포함 간의 trade-off 문제를 해결하기 위한 기법

Parent-Document 기법의 예시

- "너와 내 친구가 연인이 된 건 언제부터?" 라는 질문에 대해서 그에 대한 적절한 대답은 "너와 내가 심하게 다툰 날" 이후로 짐작할 수 있다

- 그러나 답변이 질문과 의미상으로 유사하지 않다는 점에 주목해야 함

- 오히려 "너와 내 친구는 어느새 다정한 연인이 되어 있었지"라는 표현이 의미상으로 더 가까움

- 그러나 이것은 굉장히 자연스러운 현상, 왜냐하면 RAG에서는 질문과 의미상으로 가까운 문장을 찾게 되면 그 주변에 답변이 있을 것이라는 가정을 하고 있기 때문

- 그러나 예시처럼 두 문서에서 검색했을 경우에는 상황이 달라진다, 실제로 질문에 대해서 semantic, lexical search를 해 보면 두 번째 문서가 더 관련성이 높다는 결과를 얻을 수 있음, 그 이유는 첫번째 문서의 경우 관련 문장 뿐만 아니라 다른 문장들도 포함되어 있기 때문에 이 내용들이 Vector Representation에 녹아들면서 관련문장의 의미를 희석시키기 때문

- 그러나 실제 문서의 답은 첫번째 문서에 있기 때문에 이런 경우 시스템이 답변을 제대로 하지 못하는 상황이 발생

- 이러한 문제를 해결하기 위해 Parent Document는 다음과 같은 해결방안을 제시함

1. 하나의 문서에 대해 잘게 쪼개는 작업을 진행

2. 쪼개기 전을 부모 문서, 쪼갠 후의 것을 자식 문서로 정의, 이 둘 사이의 Hierarchy 또한 저장해 둠

3. 문장의 의미가 희석되는 것을 막기 위해 검색은 자식문서에 대해 진행, 결과는 매핑되는 부모 문서를 전달함 

- 검색의 성능을 올리면서 정보의 손실을 줄일 수 있다

전체 아키텍쳐

- 임베딩, LLM은 베드락을 사용, 리랭커는 세이지메이커로 호스팅, 하이브리드 퓨전을 위해 렉시컬/시맨틱서치를 동시에 지원하는 오픈서치 사용, 전체 플로우에 대한 오케스트레이션은 EC2를 통해 구성 

 

 

평가

- 검색 증강 생성 아키텍쳐는 Advanced 기술의 등장으로 환각을 줄이기 위한 최신 정보를 유지하며 도메인별 지식을 활용할 수 있기 때문에 챗봇 개발의 업계 표준으로 빠르게 자리잡고 있음

- LLM 커뮤니티에서는 강력한 LLM을 사용하여 LLM 결과물에 대한 평가를 수행하고 있으나 Human annotator와 LLM Judge간의 일치 수준을 확인하기 위해서는 편향을 방지하고 신뢰를 개선하기 위해 실제 평가에 어려운 점들이 많음

- 모든 방법에 Standard하게 적용 가능한 공통의 합의점이 없다는 것이 LLM 커뮤니티 

- LLM Judge로 베드락 모델을 이용한 Systematic-based와 Human judge로는 Human-based로 두가지를 평가 방법으로 정확도를 예측함

- Systematic 평가 방식에서 사용될 질문과 답변 역시 모델을 사용하여 생성 후 비교함 

- 1번은 청크소스파일은 고객이 제공한 컨텍스트, 2번의 베드락 내 LLM 모델인 Claude v2.1을 통해 질문을 생성

- 편향적 결과로 공정성을 해치지 않기 위해 다른 베드락 내 Jurrasic 모델로 3번에 해당하는 정답인 Ground-Trunth를 생성

- 이 Ground-Trunth는 '우리가 정한 답변'으로, '우리의 모델이 우리가 원하는 답으로 예측해주기를 바라는' 답

- 4번은 Generated Question을 입력으로 넣어, 베드락 Claude-v2.1이 예측한 답변이 생성하게 됨

- 마지막으로 3, 4번으로 생성된 Answer와 Prediction의 컨텍스트 유사도의 정확도를 5번 Correctness로 판별하여 이 내용이 같은지(True), 다른지(False) 결정

- 위 예시는 앞서 생성한 질문과 답변, 도큐먼트 ID, 도큐먼트 내용의 샘플

- 정보검색평가는 Advanced Context Retrievers로 앞서 설명한 5가지 방식, 즉 Hybrid, Reranker, RAG-fusion, HyDE, Parent-Document를 다양한 방식으로 조합하여 각 메소드 별로 생성한 presicion(정밀도), MRR(meanreciprocal rank)과 similariry-reranker와 correctness-langchain 값을 비교함 

- 레이턴시 타임은 first token latency가 아닌 답변이 나오는 시간을 의미함

- Average는 최종 정확도

- 4번에 해당하는 Hybrid-Reranker-HyDE의 경우 정확도가 가장 높았으나, Latency trade-off를 고려하여 최종적으로 하이브리드, Reranker, Parent-Document방식을 선택함(5번)

최종적으로 Human-based 평가와도 비교, 틀린 하나는 How do를 How to로 바꾸면 정답이 나오는 것으로 확인

- 챗봇으로 생성된 답변은 Summary Hyperlink를 통해 제공하므로 고객이 최종적으로는 검색결과 사이트로 빠르게 이동할 수 있도록 함

 

 

요약