laya-triage 구축 파트 2: 오늘날의 이슈, 새로운 모델, 그리고 OpenAI Decisions API

첫 번째 게시물에서 저는 laya-triage를 공유했습니다. 이는 Actions runner 내부에서 미세 조정된 Laya 모델을 사용하여 새로 생성되는 이슈들을 버그(bug), 기능(feature), 질문(question), 또는 문서(docs)로 레이블링하는 GitHub Action입니다. API 키가 필요하지 않으며, 이슈 텍스트는 절대 GitHub를 벗어나지 않습니다.

v1.0은 NLBSE'23 벤치마크에서 88.8%를 기록했고, 저는 그 결과에 만족했습니다. 하지만 오늘날 사람들이 작성하는 실제 이슈들에 테스트해보니 79.8%로 하락했습니다. 이 게시물은 그 격차의 일부를 줄이는 것, 제가 v1.2에서 추가한 내용, 그리고 OpenAI의 새로운 Decisions API와 비교했을 때 어떤 일이 발생했는지에 대한 내용입니다.

저는 아직 이 분야를 배우고 있는 시스템 엔지니어 학생이므로, 모든 수치가 측정되어 레포지토리에 게시된, 무언가를 알아가고 있는 사람의 노트로 받아들여 주십시오.

벤치마크의 시대적 차이(Benchmarks age)

NLBSE'23은 훌륭한 벤치마크이지만, 대부분의 이슈들이 몇 년 전 것입니다. 모델이 오늘날의 레포지토리들을 어떻게 처리하는지 확인하기 위해, 저는 1,000개 이상의 스타를 받은 288개의 활성 레포지토리에 걸쳐 2025년과 2026년에 폐쇄된 이슈 10,026개를 수집했습니다. 저는 작성자나 템플릿이 아닌 유지 관리자(maintainer)가 레이블링한 이슈만 남겼으며, 이 레포지토리들은 학습에 사용되지 않았습니다.

이 데이터셋에서 v1.0은 79.8%를 기록했습니다. 같은 모델인데도 9%나 낮았습니다.

Accuracy on recent issues by training data

가장 큰 변화는 질문(questions) 처리에서 나타났습니다. v1.0은 이 중 43.7%를 인식했지만, v1.1에서는 58.3%를 인식합니다. 질문이 가장 어려운 클래스인데, 많은 질문들이 버그 보고서("제가 ~할 때 작동하지 않습니다.")처럼 읽히기 때문입니다.

v1.2: 유지보수자들이 요청한 기능들

v1.2는 v1.1 모델을 기반으로 하며 다음 기능을 추가했습니다.

• 백로그 모드 (Backlog mode). 한 번 수동으로 실행하면 이미 존재하는 열린 이슈들을 레이블링합니다. 확신하는 경우에만 처리하며, 이전 이슈에는 절대 코멘트를 달지 않습니다.
• 실행 요약 (Run summaries). 모든 실행은 결정 사항을 포함한 표를 워크플로우 요약(workflow summary)에 작성하므로, 로그 전체를 읽지 않고도 검토할 수 있습니다.
• 저장소 메모리 (Repository memory) (실험적). 모델이 두 가지 유형 사이에서 주저할 때, 저장소의 가장 유사한 닫힌 이슈 20개가 투표합니다. 약간 도움이 되지만(82.3%에서 82.7%), 더 많은 실제 저장소에서 테스트되기 전까지는 기본적으로 비활성화되어 있습니다.
• 더 많은 레이블 이름: Hacktoberfest 기간 동안 기여된 덕분에 defect나 usage 같은 항목이 올바른 유형에 매핑됩니다.

이후 OpenAI가 Decisions API를 출시했습니다

OpenAI는 9월 29일 Decisions API를 발표했습니다. 이 API는 질문과 고정된 답변 목록을 제공하면, 확률과 함께 하나의 답변을 반환합니다. 이는 Laya나 TypeSafe의 Jev와 같은 종류의 도구이므로, 저도 동일한 방식으로 측정했습니다.

• laya-triage가 학습했던 것과 동일한 문장 그대로의 질문;
• Jev가 답변했던 정확한 5,000개의 NLBSE'23 이슈;
• 단 한 번 사용된, 아무것도 조정되지 않은 recent-issues 세트;
• 2026년 세트와 14개 언어.

Decisions API는 아직 베타 버전이므로 이 수치들은 변경될 수 있습니다. 저는 2026년 10월 6일에 측정했습니다.

제가 가장 유용하다고 생각하는 숫자는 정확도(accuracy)가 아닙니다. 그것은 새로운 이슈 100개 중 발생하는 상황입니다.

Out of every 100 new issues

세 모델 모두 최근 이슈에 대해 약 77개를 맞힙니다. 차이점은 나머지 부분입니다. 호스팅된 API는 거의 모든 것을 라벨링하기 때문에, 20개 또는 21개의 이슈가 잘못된 라벨을 받습니다. laya-triage는 신뢰도가 최소 0.60일 때만 라벨링하므로, 12개에 잘못된 라벨을 붙이고 11개는 관리자에게 needs-triage 상태로 남겨둡니다. 저장소에서 작업하는 봇의 경우, 모든 것을 라벨링하기보다 적게 틀리는 것이 더 중요합니다.

제가 배운 점

1. 벤치마크 점수는 시작점일 뿐입니다. 알려진 벤치마크에서는 88.8%였던 것이 오늘날의 저장소에서는 79.8%가 되었습니다. 새로운 데이터로 측정하는 것은 제가 작업한 내용을 바꾸어 놓았습니다.
2. 작고 전문화된 모델도 충분히 경쟁력이 있습니다. OpenAI의 모델은 일반적입니다. 거의 모든 것을 결정할 수 있죠. laya-triage는 백만 개 이상의 예제를 가지고 단 하나의 질문에 대해 훈련되었습니다. 그 한 가지 질문에 대해서는 전문가가 더 잘합니다.
3. 언제 멈춰야 하는지 아는 것이 중요합니다. 보정된 신뢰도는 액션이 추측하는 대신