DEVOCEAN

안녕하세요! SKT AI Fellowship 6기에서 LLM Performance Evaluation 과제를 맡은 ttf 팀입니다! 😃

이번 포스트에서는 중간 발표를 마친 상태에서 어디까지 과제가 진행되었는지 짧게 공유 드리겠습니다!

1. 개요

이전과 같이 저희 팀은 평가의 효과가 떨어지는 기존의 벤치마크의 문제점을 인식하고,

기존의 Question-Answering Evaluation의 벤치마크를 벗어나 능동적으로 모델을 평가할 수 있는 LLM-based Evaluation 구조를 제시하고자 합니다!

기존의 Question-Answering Evaluation과 LLM-based Evaluation의 차이점은 뭘까? 🤔

위와 같은 의문점을 간단한 예시를 가지고 해결해드리겠습니다!

"당근은 과일인가요? 아니면 채소인가요?"

와 같은 질문이 있을 때, 평가 대상 LLM의 답변은 왼쪽 그림의 LLM_A, LLM_B와 같을 수 있습니다.

기존 방식 같은 경우에는 이러한 두 평가 대상 LLM의 답변에 대해서 둘 다 당근이 채소임을 내포하고 있기 때문에 정답이라는 평가를 할 것입니다.

자세히 보면, 이 두 가지 답변은 질적인 차이가 있습니다만, 기존 방식은 이러한 부분을 고려하기 어렵습니다.

그러나 오른쪽 그림에 묘사된, 저희 팀이 제안하는 방법의 경우, 주어진 Question에 대해서 평가 모델이 가능한 최선의 출력(정답)을 생성하고,

이를 평가 대상 LLM의 출력과 비교할 뿐만 아니라 그 자체로 어떤 점이 차이가 있는지 평가할 수 있습니다!

이와 같은 생성형 평가 모델(Generative Evaluation Model) 방법론을 SPEED라고 부르기로 했습니다.

SPEED: LLM Performance Evaluation with Structured Peer discussion and Expert's Evaluation on specific Domain

2. 전체 파이프라인

이 장에서는 방법론의 전체적인 파이프라인에 대해서 단계별로 설명드리겠습니다. 이전 포스트의 내용과 달라진 점에 유의하여 읽어주시면 좋겠습니다!

먼저 수정이가 코막힘과 오한, 식은땀의 증상을 보이고, 인후통을 호소하고 있다는 정보와 함께 Networking Camp에서 에어컨을 틀고 잔 수정이가 걸린 병이 무엇인지 물어보는 질문이 주어집니다.

해당 질문에 대해 평가 대상 LLM은 답변을 내놓게 됩니다. 질문은 SPEED에게도 넘어갑니다.

주어진 질문은 Answer Generation 단계에 들어갑니다.

여기서 Domain Expert는 각 도메인에 대해 신뢰성 있는 지식을 가지고 있다고 가정하는 모델입니다.

이 전문가 모델이 먼저 해당 질문에 대한 답변을 생성합니다.

저희 팀은 우선적으로 Medical Domain에 대한 Expert Model을 튜닝하고 있는데, Supervised Fine-tuning + Parameter-Efficient Fine-Tuning(LoRA)로 진행 중입니다.

모델은 답변만 생성하는 것이 아니라, 답변을 낸 이유인 Chain of Thought도 함께 생성하게 됩니다.

이는 이전 포스트에도 말씀드린 바와 같이 답변 품질을 높이고자 하는 목적도 있지만, 이후 Evaluation에 대한 배경지식으로도 제공됩니다.

저희 팀은 학습과정에서의 tuning 뿐만 아니라 더 높은 품질의 정답을 만들기 위해 Random Few-shot, Choice Shuffling, Ensemble Refinement도 사용합니다.

이 Inference Techniques들을 통해 도메인 모델은 더 풍성한 답변을 도출하게 됩니다.

Functional Expert는 정답 후보들과 그 CoT(Chain of Thought)를 기반으로 답변의 문제점을 찾고, 그에 대한 이유를 제공하는 방식으로 Domain Expert의 단점을 보정합니다.

이를 위해 저희는 LLaMa3-70B를 활용해서 Knowledge, Question, Answer에 대한 Reason을 생성하고 Functional Expert(LLaMa3-8B)의 Dataset으로 만들었습니다.

이렇게 학습한 Functional Expert는 Domain Model이 만든 정답 후보와 CoT에 대해 Peer Discussion을 수행합니다.

multi-turn Peer Discussion이 이루어지고, 이를 통해 Functional Expert가 지적한 문제점을 보완하여 정답이 되는 출력을 완성합니다.

이제 마지막 단계인 Expert's Evaluation입니다. 평가 대상 LLM의 답변을 앞에서 만든 정답과 CoT를 기준으로 평가합니다.

정성평가와 정량평가 둘 다 User에게 제공하는 방법을 고려하고 있습니다.

정성평가의 경우 Expert들의 의견을 조합해서 제공, 정량평가의 경우 Score 계산을 통해 제공됩니다.

정량평가를 위한 Score로는 현재 카카오에서 만든 RDASS라는, 원래 요약 평가에 활용되던 Score에서 아이디어를 얻어서 이를 변형해 사용할 예정에 있습니다.

3. 진행 상황

현재 저희 팀은 Peer Discussion을 위한 전문가들을 Tuning하는 과정까지 완료했습니다.

먼저, 학습하고 있는 Domain Expert는 Medical Expert에 해당합니다.

PubMedQA는 초록에 대한 Q&A로 이루어진 Dataset이며, 저희는 해당 Dataset에 대한 long text format의 답변을 생성하도록 학습했습니다.

해당 Dataset은 Yes / No / Maybe 에 대한 label도 가지고 있기 때문에 이러한 객관식 답변 task에 대해서는 학습 없이 추론을 진행하기도 했습니다.

단순히 Supervised Fine-tuning만 된 결과는 객관식 답변 자체를 생성하지 못했지만 Inference 기술을 적용한 이후 Zero-shot Task에 대해서 65.8%의 정확도를 보였습니다.

학습된 주관식 답을 내는 task의 경우, GPT LLM Judge를 활용하여, 3가지 기준에 대해서 각 10점, 총 30점 만점으로 평가했습니다.

생성 실패 개수는 90개이고 inference 성능 향상 이후로는 실패 개수가 77개, 평균 점수는 약 1.714점 늘었습니다.

MedMCQA는 실제 의학 시험 QA로 이루어진 객관식 문제입니다.

단순 Supervised Fine-tuning을 끝낸 결과의 평균 정확도는 55%였으나, Inference 성능 향상 중 Prompting과 Ensemble Refinement를 적용한 경우 66.7%,

거기에 Random Few-shot과 Choice Shuffling을 추가한 경우 89.9%의 정확도를 보이는 것을 확인할 수 있었습니다.

PubMed RCT dataset의 경우 초록(Abstract)으로 이루어진 데이터셋이고 Conclusion을 예측하도록 학습했습니다.

일반적인 tuning 같은 경우 task가 일반적인 QA와 다르게 어렵다 보니 거의 생성이 안됐지만, Prompting과 Ensemble Refinement를 적용한 후 1000개 중 730개 생성에 성공했습니다.

Hallucination Expert의 경우 LLaMa3-70B 모델을 통해서 5만 개의 Knowledge, Query, Label을 주고 Label에 대한 Reason을 생성하도록 했습니다.

Toxic 또한 동일한 방식으로 30만 개에 대한 Reason을 생성했습니다.

이후 생성된 Reason을 이용하여, Knowledge와 Query가 주어졌을 때 Reason을 생성하는 task를 학습했습니다.

학습된 모델의 생성 예시는 위 그림들과 같습니다.

Background Knowledge와 평가 대상 LLM의 Response가 주어졌을 때, 저희 Hallucination Expert의 결과는 그림의 말풍선에

4. 앞으로 해야할 과제

중간 발표 이후로는, 완성된 Expert들의 Discussion을 통해 정답을 만들고, 정답을 기준으로 Evaluation하는 과정을 진행할 예정입니다.

전문가의 경우 Functional Experts를 가져오는 경우도 있지만, Evaluation을 위한 전문가로 Context Expert를 새로 도입할 예정이며,

앞에 잠깐 언급 드렸던 정량평가 기준 또한 RDASS를 변형하는 방향으로 연구를 진행할 예정입니다.

5. 소중한 피드백

중간 발표 진행 이후, 너무나도 소중한 피드백들이 나왔습니다! 앞으로 주셨던 모든 피드백들을 참고해서 더 나은 SPEED를 개발하도록 하겠습니다!

피드백 + 어떻게 개선해야할지에 대해 아주 간단히 적어보았습니다!

• 강점 어필 관련

  • 기본 LLMOps 대비 개선점을 말하면 더 쉽게 프로젝트의 강점이 잘 어필

  • 구체적인 도메인에 대한 Evaluation 적용의 예로 하나가 제시되고 PIPELINE(SPEED) 솔루션의 각 단계가 설명되면, 연구하신 Evaluation 시스템의 강점이 잘 전달

  • 방법에 대해서 어떻게 할 것이라고 청사진만 제시하고 구체적으로 논하지 못하여 이 부분을 개량한다면 좋은 과제가 될 것으로 보임

  → 최종 발표에서는 한 질문을 가지고 Domain Expert가 도출한 정답을 Functional Expert가 어떻게 답변 개선을 도와주는지, 이로 인해 최종적으로 만들어진 답변이 무엇이고 이를 근거로 평가 대상 LLM의 답변을 어떤 방식으로 평가하는지에 대해서 단계적으로 제시하여 SPEED의 강점을 잘 전달하도록 개선하겠습니다!

• Expert 성능 관련

  • Expert Model 의 성능을 어떻게 평가할 것이고 그 자체는 얼마나 신뢰할 수 있는지에 대한 더 충분한 고민

  → 각 Expert마다 어떤 성능지표를 사용해서 어떻게 보여줄 수 있는지, 해당 성능지표가 SPEED의 최종 결과(정답)의 성능을 보여주는데 어떻게 사용될 수 있는 지에 대해 고민하겠습니다.

  이에 있어서 아래와 같이 계획하고 시행하겠습니다!

1. 각 Expert 모델에 대해서 적절한 성능 지표를 선정.

2. Peer Discussion 구현 단계(9월 중순 예정) 전까지 각 모델을 성능 지표에 따라서 성능 평가

3. 각 모델의 평가를 완료하고 해당 평가 결과와 SPEED의 최종 결과(CoT와 정답)의 성능과의 연관성 분석

4. 10월 초까지 평가 지표에 대한 분석 완료 후 성능 개선 시도

• 전문가 교체 관련

  • 전문가를 교체할 때 얼만큼의 비용(필요한 데이터 수, 학습에 필요한 FLOPs 등)이 발생하는지 알려주면, 확장성에 대한 설득력이 강화

  • 현업 적용을 위해서는 모델 생성 외에 누구나 도메인을 쉽게 교체해서 사용할 수 있게 프레임워크도 함께 제안 주시면 좋을 것 같습니다. 발표 자료만으로는 왜 확장성이 있는지에 대해 쉽게 납득이 되진 않았습니다.

  • 제각각의 도메인에서도 대규모 데이터셋을 구축해야 할 텐데, 이에 드는 시간과 자원을 고려할 때 비용이 상당히 많이 들 수도 있지 않을까

  → 최종 발표에 이미 만들어진 다른 도메인 모델을 사용한 결과를 제시, 도메인 교체 가능에 대한 추가적인 설명 필요 ("모델을 매번 새로 만들 필요가 없다" 에 대한 설득) 또는 현업 적용을 위해서 모델을 새롭게 만들 때 의료 도메인에 들어간 자원과 비교해서 필요한 자원 설명을 최종 발표에 추가하겠습니다!

칭찬해주신 점도 많았는데, 저희가 보완해야 할 점들만 우선 적었습니다. 응원 감사합니다!

저희 ttf 팀은 윤대훈, 이준학, 정지헌, 김의연 멘토님과 함께 최종 발표를 향해 더 힘차게 나아가도록 하겠습니다! 감사합니다!