네이버에서 최초의 대화형 검색 서비스인 ‘지식인터랙티브’, 클로바 스피커의 ‘똑똑사전’ 서비스를 아시나요? ChatGPT 보다 먼저 LLM 기반의 채팅서비스를 내었지만 결국 wow 포인트가 없었던 이유로 ChatGPT만큼 빛을 보지는 못했습니다 하하.. 네이버에서는 2년전 HyperCLOVA가 처음 나왔을 때부터 RAG 구조를 기반으로 하는 LLM 서비스 고민들을 많이 해왔습니다. 때문에 최근에 CUE 라는 서비스까지도 빠르게 만들수 있었지 않았나 싶습니다. 그래서 요즘들어서 어디서건 RAG, RAG 하는게 신기하기도 합니다. 어쩌면 2년전 LLM 모델들의 Hallucination은 더 심각했으니, RAG 없이 QA 시스템을 만들기엔 답이 없는 상태이긴 했습니다. 하지만 그때에도 집요하게 엔지니어링하고 품질을 끌어올려 서비스를 했던 것이 ‘지식인터랙티브’와 ‘똑똑사전’ 서비스였습니다. 해당 서비스를 위해 실험하고 고민했던 부분들을 정리해서 발표한 deview 2021 자료를 다시 끌올해서 공유드리려고 합니다. LLM으로 서비스를 고민하시는 분들에게는, 지금봐도 도움이 되는 것들이 있지 않을까 싶습니다. 발표자료: https://deview.kr/2021/sessions/436 LLM으로 프로덕트를 만들때 우선 서비스 기획적으로 Hallucination을 피하는 방법이 있는데요… 모델이 잘하는 특정 영역이나 정답이 없는 creative한 영역, 혹은 모델이 틀려도 excuse가 될만한 도메인으로 대상 도메인을 줄입니다ㅋㅋ 지식인터랙티브나 똑똑사전도 그래서 공룡, 우주, 동물 등 어린이들을 타겟팅한 도메인을 잡은 측면도 없지않아 있습니다. 착한 어린이들은 AI가 틀려도 논란을 만들진 않겠죠?ㅎㅎ 그러면 이제 서비스를 만들면서 기술적으로 공유드릴만한 점들은 아래와 같습니다. 1. 쿼리 도메인 분류기 예를들어 공룡대상의 지식관련 대화 시스템인데 ‘욕해봐’, ‘방구껴봐’ 질의가 은근 많습니다… 그래서 타겟하는 도메인의 질문들만 시스템 입력으로 판별해주는게 필요했습니다. 2. Inference 캐싱전략 (online/offline) 지금도 LLM은 비싸지만 그때에 작은 LLM일 때에도 inference 시간과 비용은 너무 컸습니다. Online으로 raw input에 대한 response caching도 있겠지만, 좀더 커버리지를 넓히기 위해 Encoder류 임베딩 기반으로 질문 매칭을 통해 미리 구축해놓은 질문-답변 DB를 활용한 Offline caching 전략도 사용했습니다. Encoder류의 임베딩은 그래도 싸고 빠르니까요. 3. Prompt engineering 이때에 prompt engineering이라함은 거의 few-shot example을 얼마나 어떻게 주느냐였습니다. 지금처럼 instruction-following 능력이란 것이 없었기 때문에.. 그래서 fewshot은 몇개를 넣어주면 좋은지, random한 example보다 input과 관련된 fewshot example을 주면 얼마나 효과가 있는지 등의 분석이 중요했습니다. 이때에도 input 질문과 관련된 fewshot을 넣어주려면 대상 질문들 pool을 만들어야하고, 검색용 임베딩 모델이 또 쓰이죠. 4. RAG 구조 검색기는 BM25 + DPR 하이브리드로 사용했는데, 지금은 DPR 보다 훨씬 더 좋은 검색 임베딩 모델이 많아졌죠. 그래도 아직은 BM25도 강력합니다. LLM에 검색 문서를 넣으려면 역시 고려사항으로 따라왔던 점이 chunk size였습니다. 그래서 구체적으로는 다음의 4가지 방법들로 시도해봤습니다. 1) 250글자 길이로 chunking 2) 3문장 단위로 chunking 3) 100-word chunking 4) 문단 단위 청킹하되, 문단이 긴 경우 Byte-level BPE 길이 기준으로 chunking 그리고 질문을 검색에 적합한 쿼리형태로 변환하는 과정도 필요했구요, 더 나아가면 지금의 CUE나 딥마인드의 Sparrow와 같이 질의확장을 사용하면 더 좋은 검색을 할 수 있습니다. 5. SFT, PEFT 지금 돌이켜보면 이때 저희는 전문가들을 통해 양질의 도메인 QA 데이터를 만들어서 학습시켰었는데, 그게바로 ChatGPT에서 설명하는 SFT 이었더군요. Instuction 데이터는 아니었지만 도메인 데이터로 추가 학습을 시켰더니, forgetting 현상은 조금 일어나지만 knowledge가 확실히 학습이 많이 되었습니다. 그리고 RAG 구조의 인풋에 대해 LLM을 joint learning 했을때 효과도 좋았습니다. SFT도 full-finetuning 뿐 아니라 당시에도 Adapter류의 다양한 PEFT 방법론들이 나와서 P-tuning, LoRA 모두 비교 실험해본 결과도 있습니다. LoRA가 현재에도 PEFT의 원탑이 될줄은… 6. 답변 검증 (fact verification / guadrails) 갖가지 hallucination을 막기위한 방법들을 써도, 결국엔 마지막 한번더 질문에 대한 답변을 확인하는 과정이 필요했습니다. 결국은 모델이 커져서 어느 정도 해결된다면 없어도 될 부분이긴 하겠습니다만, 답변의 정확도가 중요하다면 커버리지를 잃더라도 도입해야할 부분이 될 수 있는 것 같습니다. 7. 마무리 저는 약간 회고의 느낌으로 작성을 해봤습니다. 요즘은 RAG나 LLM 기반으로 서비스를 많은 곳에서 만들어보면서 공유되는 꿀팁들이 많이 있는것 같습니다. 저도 많은 도움을 받았기 때문에, 소소하게나마 이 내용도 도움이 되시는 분이 있길 바랍니다:)