생성형 AI 비서, 정량적 품질 측정과 성능테스트 전략

1. 해당 강연을 선택한 이유
   • 최근 AI에 대한 관심도가 높아지며 회사에서 자체적인 AI 를 생성하는 경우가 많다.
   • 이와 관련하여 AI를 활용하는것 뿐 아니라 어떻게 검증을 하는 것이 좋은지에 대한 관심을 가지고 있었다.
   • 개인적으로 회사 내에서 활용할 수 있는 AI를 만들어보고 싶은데, 이때 어떤 점들을 고려하면 좋을지 궁금했다.
   • 결론적으로 실 서비스에서 AI QA 를 할 때 많은 부분을 활용할 수 있을것 같았고, 개인 프로젝트에서도 활용할 수 있는 많은 부분을 도움받을 수 있어서 도움이 되었다.
2. 주요 주제
   • AI 서비스의 품질 검증
   • AI 악용 케이스와 예외 케이스 대응 방법
   • 성능확인을 위한 API 부하테스트와 AI 자동화에 대한 대책과 방법
   • AI QA 프로세스와 실 서비스에서의 팁

---

1. Generative AI
   
   1. Getnerative AI 란?
      • 텍스트, 이미지, 오디오, 비디오 등 새 콘텐츠를 창조할 수 있는 모델을 의미함.
      • LLM, Text to image, TTS 등을예시로 볼수 있다.
   2. AI 품질 검증의 한계
      • 일반적인 기능과 달리 매번 다른 결과를 생성하므로, 더 예외적인 케이스를 확인해야 한다.
      • 특히 윤리, 편향, Hallucination, prompt injection, 답변품질 평가를 기준으로 평가 가능.
2. Quality testing for LLM
   1. 윤리
      • 문제점 : 시뮬레이션, 롤을 부여했을 때 비속어나 비윤리적인 답변이 가능하다.
      • 해결 방안
        • 답변을 생성하기 전, LLM을 활용하여 한번 더 검토를 진행한다.
        • 답변 생성할 때 비속어를 마스킹 처리한다.
        • 다양한 시뮬레이션 상황 및 언어, 여러 분야로 테스트 한다.
        • 특히 연사자님 (SOOP) 에서는 스마일게이트 api인 언스마일 데이터셋을 활용했다고 한다.
   2. 편향
      • 문제점 : 학습데이터가 편향되어 있다면 동일한 결과가 나온다 (ex. 고소득 직종 얼굴이 백인으로만 묘사됨)
      • 해결 방안 
        • 학습된 데이터에 편향성이 없는지 검증이 필요하다.
   3. Hallocination
      
      • 문제점 : 그럴듯한 답변을 거짓으로 생성한다. 금융권이나 공공기관의 경우, 굉장히 크리티컬한 부분.
      • 해결 방안
        • 담당 서비스에 맞게 교묘하게 바꾼 질문으로 테스트를 진행해본다.
        • 프롬포트 지시사항이나 RAG 등을 통해 억제할 수 있다.
   4. Prompt injection
      • 문제점 : 프롬포트를 통해 고객 정보나 서버 정보같은 민감한 시스템 권한 접근을 시도한다.
      • 해결 방안
        • 개발자분들이 편의성을 위해 유저용 prompt 에 시스템 정보를 조금씩 넣거나 참고하여 답변하게 제공하는 경우 있다.
        • 답변 범위를 제한하거나 답변을 회피하도록 대응한다.
        • 서버에 대한 정보나 유저에 대한 정보를 유추할 수있는 질문을 시도해본다.
   5. Ground Truth
      • 문제점 : 유저가 원하는 좋은 답변을 제공하지 못함.
      • 해결 방안
        • 정답지와 그와 관련된 질문 세트를 준비한 뒤에 LLM이 생성한 답변과 비교.
   6. 답변의 유사성을 판단하기 위한 지표
      • BERT Score
        • 단어별 벡터 공간 위치를 비교하는 품질 지표로서, 의미적으로 유사한 단어일수록 점수가 상승.
        • Ground Truth 에 의미가 비슷한 단어가 많이 포함될수록 점수가 상승한다.
        • 다만, 답변이 의미적으로 유사하다는 것은 파악할 수 있지만, 심층적인 분석이 어렵다는 단점이 있다.
      • LLM as a Judge
        • BERT Score의 한계를 극복하기 위해 생긴 개념.
        • 기존의 평가 지표를 보완한 AI가 AI를 평가하는 방식.
        • 요구사항이나 나와야 하는 답변 포맷을 최대한 자세하게 적어서 활용한다.
        • 이를 세부 지침으로 설정한 뒤 점수를 매기는 것이 좋다.
   7. 위 지표를 사용하여 측정할 수 있는 항목
      
      • Answer Relevancy
        • 사용자질문에 맞는 (관련성이 높은) 답변을 했는지 측정
        • 질문과 LLM 답변, Ground Truth 3가지 요소를 활용하여 유저의 질문에 얼마나 연관성이 있는 답변을 했는지를 측정한다.
      • Hallucination score
        • 실존하지 않는 정보를 제공하는 지 검증하는 지표
3. performance testing for LLM
   1. LLM api 요청을 반복적으로 전송하여 부하 측정
      
      • AI가 GPU기반으로 돌아가기 때문에 최소 30분에서 1시간까지 지속적 부하 테스트가 필요하다.
      • 1초당 처리할 수 있는 LLM 요청 건수 (RPS) 측정
      • 이때, Requests가 누적되며 성능 저하가 크게 발생할 수 있다.
   2. Latency 측정
      • End to End request Latency
        • 유저의 요청에 대한 답변이 완성되는 때까지 걸리는 시간을 측정한다.
      • Time to first token
        • 유저의 요청에서 첫번째 답변 문장이 생기기 시작한 시점을 측정한다.
      • 측정 기준
        • Chat GPT와 같이 응답이 빨라야 하는 서비스는 timeto first token위주로 측정한다.
        • Perplexity 와 같이 정확한 정보를 찾는것이 중요한 서비스는 최종 응답이 오는 시간과 속도를 측정한다.
        • 개발조직과 긴밀하게 협업하면서 모델 세팅, 교체 등과 벤치마크 테스트 등을 위주로 평가한다.
4. Discussion
   1. Ground Truth data set 구축의 어려움
      • AI 가 회사 서비스를 모르기 때문에 어디까지 알아야하고, 어디까지 모르도록 학습시키는지 가이드라인을 만들고 테스트용 질문을 만들어야 함.
      • 즉 수동작업이 많이 필요하기 때문에 LLM pipeline 자동화를 위한 다양한 연구가 필요하다.
   2. 이슈 재현의 어려움
      • 생성형 AI 특성상 이슈 재현이 어렵기 때문에 증거를 확보해야 한다.
      • 특히 사용자에게서 들어오는 cs의경우, 로그가 남도록 설정하여 확인 후 추가 학습을 진행한다.
   3. 이슈 수정의 어려움
      • 특정 질문에 대한 핫픽스나 모델 교체를 진행했을 때, 다른 분야의 질문 품질에 대한 트레이드 오프를 고려해야 함.
      • 즉, 신중한 접근이 필요하며 가능하다변 자동화를 구축하여 전반적인 답 질문 퀄리티를 체크할 수 있도록 파이프라인 구축.
   4. 최종 AI QA 프로세스 추천
      
      • 주요 업데이트 시점마다 데이터셋을 확보 후 품질 지표를 선정하고 윤리 검증, 답변 품질 검증 순으로 진행하는 것이 좋다.
      • 특히 윤리를 검증할 때 통과하지 못하는 경우가 많다.
        예를 들어 흑역사나 인신 비하 등과 관련된 답변을 하는 경우를 막기 위해 시간이 소요됨
      • 벤치마킹 테스팅의 경우, 모델 관련 수정이 있는 경우 테스트하는 것이 좋다.