뉴스 정보 뉴스 컴퓨터 소프트웨어 및 개발 Min-jun (민준) 10월 31, 2025 0 Comments

중요한 사항 측정: GitHub MCP 서버의 오프라인 평가 작동 방식

MCP(모델 컨텍스트 프로토콜)는 AI 모델(LLM)이 API 및 데이터와 통신하는 간단하고 일반적인 방법입니다. 범용 플러그처럼 생각하면 됩니다. 양측이 MCP를 지원하면 함께 연결하고 작동할 수 있습니다. MCP 서버는 “MCP를 말하며” 모델이 사용할 수 있는 도구를 제공하고 도구 목록, 각 도구의 기능, 각 도구에 필요한 입력(매개변수)을 게시하는 모든 서비스 또는 앱입니다.

GitHub MCP 서버는 GitHub 내부와 외부 모두에서 많은 GitHub Copilot 워크플로의 기반입니다. GitHub MCP에서 작업하는 엔지니어링 팀으로서 우리는 항상 새로운 기능을 제공하는 동시에 회귀를 방지하고 모든 반복에서 품질을 향상시키기 위해 노력하고 있습니다. 그리고 도구 이름을 지정하고, 도구의 기능을 설명하고, 매개변수를 설명하는 방법은 모델이 올바른 인수를 사용하여 올바른 도구를 올바른 순서로 선택하는지 여부에 직접적인 영향을 미칩니다.

작업에 있어서는 작은 편집이 중요합니다. 설명을 강화하거나, 도구를 추가 또는 제거하거나, 몇 가지 유사한 도구를 결합하면 결과가 크게 바뀔 수 있습니다. 설명이 꺼져 있으면 상담원이 잘못된 도구를 선택하거나, 단계를 건너뛰거나, 잘못된 형식으로 인수를 보내거나, 인수를 완전히 삭제합니다. 결과는 약하다. 우리는 MCP를 변경하고 상황이 실제로 악화되지 않고 좋아졌는지 알 수 있는 안전한 방법이 필요합니다. 오프라인 평가가 이루어지는 곳입니다.

오프라인 평가는 사용자가 보기 전에 회귀를 포착하고 피드백 루프를 짧게 유지하므로 실제로 성능을 향상시키는 변경 사항을 제공할 수 있습니다.

이 문서에서는 평가 파이프라인을 살펴보고 이러한 목표를 달성하는 데 도움이 되는 측정항목과 알고리즘을 설명합니다.

자동화된 오프라인 평가의 작동 방식

우리의 오프라인 평가 파이프라인은 도구 프롬프트가 다양한 모델에서 얼마나 잘 작동하는지 확인합니다. 도구 지침은 간단하고 정확하게 유지되므로 모델이 올바른 도구를 선택하고 올바른 매개변수를 채울 수 있습니다. LLM은 도구를 사용하는 방법이 다양하므로 각 모델과 MCP 쌍을 체계적으로 테스트하여 호환성, 품질 및 격차를 측정합니다.

우리는 벤치마크로 사용하는 선별된 데이터 세트를 보유하고 있습니다. 모든 벤치마크에는 다음 매개변수가 포함됩니다.

입력: 자연어로 표현된 사용자 요청입니다.
예상 도구: 호출될 것으로 예상되는 도구입니다.
예상 인수: 각 도구에 전달될 것으로 예상되는 인수입니다.

다음은 몇 가지 예입니다.

특정 기간에 얼마나 많은 이슈가 생성되었는지 묻기

입력: 2025년 4월 동안 github/github-mcp-server 저장소에 몇 개의 문제가 생성되었습니까?
예상 도구: 목록_문제 인수:

owner: github 
repo: github-mcp-server 
since: 2025-04-01T00:00:00Z

풀 요청 병합

입력: “업데이트 설치 가이드”라는 제목의 스쿼시 병합을 사용하여 github/docs에서 PR 123을 병합합니다.
예상 도구: merge_pull_request와 인수:

owner: github
repo: docs 
pullNumber: 123 
merge_method: squash 
commit_title: Update installation guide

코드 검토 요청

입력: team/project-alpha의 PR 67에 대해 alice456 및 bob123에게 리뷰 요청
예상 도구: update_pull_request를 사용하여 인수:

owner: team 
repo: project-alpha 
pullNumber: 67
reviewers: ["alice456", "bob123"]

입력: facebook/react 저장소에서 토론 33801의 의견을 요약하세요.
예상 도구: get_discussion_comments with 인수:

owner: facebook
repo: react
discussionNumber: 33801

평가 파이프라인에는 세 가지 단계가 있습니다. 이행, 평가그리고 요약.

이행: 우리는 여러 모델에 걸쳐 각 벤치마크를 실행하여 모든 요청에 대해 사용 가능한 MCP 도구 목록을 제공합니다. 각 실행마다 모델이 호출한 도구와 모델이 제공한 인수를 기록합니다.
평가: 우리는 원시 출력을 처리하고 지표와 점수를 계산합니다.
요약: 데이터 세트 수준의 통계를 집계하고 최종 평가 보고서를 생성합니다.

평가 지표 및 알고리즘

우리의 평가는 두 가지 측면을 목표로 합니다. 올바른 도구를 선택합니다 그리고 그것이 올바른 인수를 제공합니다..

도구 선택

벤치마크에 단일 도구 호출이 포함된 경우 도구 선택 로 감소 다중 클래스 분류 문제. 각 벤치마크에는 예상되는 도구가 표시되어 있으며 각 도구는 “클래스”입니다.

이 분류 작업을 수행하는 모델은 다음을 사용하여 평가됩니다. 정확성, 정도, 상기하다그리고 F1 점수.

정확성 올바른 분류의 비율을 보여주는 가장 간단한 척도입니다. 우리의 경우 이는 예상된 도구 호출로 이어진 입력의 비율을 의미합니다. 이는 전체 데이터 세트에서 계산됩니다.
정도 도구가 호출된 전체 사례 중 도구가 올바르게 호출된 경우의 비율을 나타냅니다. 정밀도가 낮다는 것은 도구가 호출될 것으로 예상되지 않는 경우에도 모델이 도구를 선택한다는 것을 의미합니다.
상기하다 주어진 도구 호출이 예상되었던 모든 경우 중에서 올바르게 호출된 도구의 비율을 보여줍니다. 재현율이 낮으면 모델이 도구를 호출해야 한다는 사실을 이해하지 못하고 도구를 호출하지 못하거나 대신 다른 도구를 호출한다는 의미일 수 있습니다.
F1 점수 정밀도와 재현율 측면에서 모델이 얼마나 잘 작동하는지 보여주는 조화 평균입니다.

모델이 두 도구를 혼동하는 경우 해당 도구에 대한 정밀도가 낮아지거나 재현율이 낮아질 수 있습니다.

자주 혼동되었던 두 가지 유사한 도구가 있습니다. list_issues 그리고 search_issues. 10개의 벤치마크가 있다고 가정해 보겠습니다. list_issues 10가지 벤치마크 search_issues. 상상하다 list_issues 10개 사례 모두에서 올바르게 호출되었으며, search_issues를 호출해야 하는 경우 중 30%가 가장 높습니다.

이는 우리가 더 낮은 리콜을 갖게 될 것임을 의미합니다. search_issues 정밀도가 낮습니다. list_issues:

정도 (list_issues) = 10 (도구가 올바르게 호출된 경우) / (10 + 3 (도구가 대신 호출된 경우) search_issues)) = 0.77

상기하다 (search_issues) = 7(도구가 올바르게 호출됨) / 10(도구가 호출될 것으로 예상되는 경우) = 0.7

어떤 도구가 서로 혼동되는지 확인하기 위해 혼동 행렬을 구축합니다. 혼란 행렬 search_issues 그리고 list_issues 위 예의 도구는 다음과 같습니다.

예상 도구 / 호출 도구	검색_문제	목록_문제
검색_문제	7	3
목록_문제	0	10

혼동 행렬을 사용하면 특정 도구에 대한 정밀도와 재현율이 낮은 이유를 확인하고 설명을 조정하여 혼동을 최소화할 수 있습니다.

인수 정확성

올바른 도구를 선택하는 것만으로는 충분하지 않습니다. 모델은 또한 올바른 인수를 제공해야 합니다. 우리는 특정 문제를 정확히 찾아내는 일련의 인수 정확성 측정항목을 정의하여 회귀 분석을 쉽게 진단하고 수정할 수 있도록 했습니다.

우리는 네 가지 인수 품질 지표를 추적합니다.

인수 환각: 모델이 도구에 대해 정의되지 않은 인수 이름을 제공하는 빈도입니다.
예상되는 모든 인수가 제공되었습니다. 예상되는 모든 인수가 존재하는지 여부.
모든 필수 인수가 제공되었습니다. 모든 필수 인수가 포함되어 있는지 여부입니다.
정확한 값 일치: 제공된 인수 값이 예상 값과 정확하게 일치하는지 여부입니다.

이러한 측정항목은 올바르게 선택된 도구에 대해 계산됩니다. 최종 보고서는 네 가지 측정항목 전체에 걸쳐 각 도구의 성능을 요약합니다.

기대하고 부족한 부분을 채워가세요

현재 평가 프레임워크는 선별된 데이터 세트에 대한 도구 성능에 대한 확실한 정보를 제공하지만 여전히 개선할 여지가 있습니다.

많을수록 좋다

벤치마크 볼륨은 오프라인 평가의 약점이다. 클래스(도구)가 너무 많기 때문에 보다 강력한 도구별 적용 범위가 필요합니다. 단지 몇 가지 사례만으로 평가하는 것은 신뢰할 수 없습니다. 더 많은 벤치마크를 추가하는 것은 분류 평가 및 기타 지표의 신뢰성을 높이는 데 항상 유용합니다.

다중 도구 흐름 평가

현재 파이프라인은 단일 도구 호출만 처리합니다. 실제로 도구는 순차적으로 호출되는 경우가 많으며 이후 호출은 이전 호출의 출력을 사용합니다. 이러한 흐름을 평가하려면 MCP 도구 목록을 가져오는 것 이상으로 평가 중에 실제로 도구 호출을 실행(또는 해당 응답을 모의)해야 합니다.

요약도 업데이트하겠습니다. 오늘 우리는 도구 선택을 다음과 같이 취급합니다. 다중 클래스 분류이는 입력당 하나의 도구를 가정합니다. 단일 입력이 여러 도구를 트리거할 수 있는 흐름의 경우 다중 라벨 분류 더 잘 맞습니다.

이것을 가지고 가세요

오프라인 평가는 MCP를 반복하는 빠르고 안전한 방법을 제공하므로 모델은 올바른 인수와 함께 올바른 GitHub 도구를 선택합니다. 엄선된 벤치마크를 도구 선택을 위한 분류 점수와 논쟁 품질을 위한 목표 검사와 같은 명확한 지표와 결합함으로써 우리는 모호한 “더 좋아 보인다”를 측정 가능한 진행 상황과 실행 가능한 수정 사항으로 바꿉니다.

우리는 여기서 멈추지 않습니다. 우리는 벤치마크 적용 범위를 확장하고, 도구 설명을 개선하여 혼란을 줄이고, 실행 또는 충실한 모의를 통해 실제 다중 도구 흐름을 처리하도록 파이프라인을 확장하고 있습니다. 이러한 투자는 회귀 횟수 감소, 더 명확한 통찰력, 개발자가 더 빠르게 움직일 수 있도록 돕는 더 안정적인 에이전트를 의미합니다.

가장 중요한 것은 이 작업이 배송 속도를 늦추지 않고 제품 품질의 기준을 높인다는 것입니다. 우리가 제품군을 확장하고 평가를 심화함에 따라 GitHub MCP 서버에 대한 꾸준한 개선과 이를 통해 구축하는 모든 사람에게 더 좋고 예측 가능한 경험을 기대할 수 있습니다.