안녕하세요 HN 커뮤니티에, 저희는 continuous-eval(https://github.com/relari-ai/continuous-eval)을 개발한 Relari의 창업자들입니다. 이 평가 프레임워크는 GenAI 시스템을 구성 요소별(component level)로 테스트할 수 있게 해주며, 문제가 발생하는 지점을 정확하게 찾아낼 수 있습니다.

저희가 은행원용 코파일럿(copilot)을 구축하는 과정에서 이 필요성을 느꼈습니다. 사용자 의도를 분류하는 쿼리 분류기(query classifier), 여러 소스에서 정보를 가져오는 다중 검색기(multiple retrievers), 컨텍스트를 재정렬/압축하는 필터링 LLM(filtering LLM), 금융 함수를 호출하는 계산기 에이전트(calculator agent), 그리고 최종 답변을 제공하는 합성기 LLM(synthesizer LLM) 등 여러 구성 요소를 추가하면서 RAG 파이프라인의 복잡성이 폭발적으로 증가했습니다. 이 요소들을 하나씩 추가할수록 신뢰성을 확보하기가 점점 더 어려워졌습니다.

답변 평가자(answer evaluator)가 잘못된 응답을 감지하면, 어떤 구성 요소가 실수를 했는지 이해하기 위해 여러 단계를 거슬러 올라가야 했습니다. 하지만 이는 몇 가지 샘플 이상에서는 빠르게 확장 불가능해졌습니다.

저는 자율주행 차량의 결함 탐지(fault detection) 분야에서 박사 학위를 받았고, 오늘날 LLM 파이프라인의 복잡성과 자율 주행 소프트웨어 간에 강력한 유사성을 발견했습니다. 자율 주행 시스템에서는 센서, 인식(perception), 예측(prediction), 계획(planning), 제어(control) 모듈들이 모두 연결되어 있습니다. 시스템 수준의 안전을 보장하기 위해 각 모듈의 성능을 개별적으로 측정하는 세분화된 지표(granular metrics)를 사용합니다. 차량이 예상치 못한 결정을 내리면, 이 지표들을 사용하여 문제점을 특정 구성 요소로 짚어냅니다. 그래야만 체계적이고 목표 지향적인 개선을 할 수 있습니다.

이러한 사고방식에 기반하여 저희는 처음으로 continuous-eval 버전을 자체적으로 개발했습니다. 그 이후로는 다양한 유형의 GenAI 파이프라인에 맞게 더 유연하게 만들었습니다. Continuous-eval은 사용자가 자신의 파이프라인과 모듈을 프로그래밍 방식으로(programmatically) 설명하고, 각 모듈에 대한 지표를 선택할 수 있게 해줍니다. 저희는 검색(retrieval), 텍스트 생성(text generation), 코드 생성(code generation), 분류(classification), 에이전트 도구 사용(agent tool use) 등을 포괄하는 30가지 이상의 지표를 개발했습니다. 현재 금융 코파일럿, 엔터프라이즈 검색, 코딩 에이전트 등 복잡한 파이프라인을 테스트하기 위해 저희를 사용하는 여러 기업들이 있습니다.

예를 들어, 한 고객은 RAG 시스템이 트렌드 분석 쿼리에서 왜 성능이 떨어지는지 이해하려고 했습니다. continuous-eval을 통해 그들은 '검색기(retriever)' 구성 요소는 관련 청크의 80% 이상을 검색했지만, '재정렬기(reranker)' 구성 요소가 '관련 없는' 컨텍스트를 필터링하는 과정에서 이 비율이 50% 미만으로 떨어지고 있다는 것을 깨달았습니다. 이를 통해 그들은 문제를 해결할 수 있었습니다.