이 글은 저희가 VideoDB Labs 블로그에 작성했던 연구 노트의 수정된 단축 버전입니다. 저는 VideoDB 팀에서 근무하고 있습니다. 원문 포스트와 오픈 소스 리포지토리(repo)는 하단에 링크되어 있으며, 이 기사는 원문으로 연결되는 캐노니컬(canonical) 태그가 설정되어 있습니다.

실수: 추상적인 상태에서 모델을 벤치마킹하는 것

대부분의 "어떤 VLM이 가장 좋은가"에 대한 비교는 실제로 아무도 궁금해하지 않는 질문에 답하고 있습니다. 실제 비디오 워크플로우(workflow)에서 출력값은 모델 단독에 의해 결정되지 않습니다. 그것은 세그멘테이션 전략(segmentation strategy), 프레임 샘플링(frame sampling), 해상도(resolution), 프롬프트(prompt), 모델(model), 추론 예산(reasoning budget), 지연 시간 제한(latency limits), 그리고 이후에 실행되는 모든 후처리(post-processing)에 따라 달라집니다. 이 중 어느 하나라도 바꾸면 수치는 변합니다.

따라서 비교해야 할 단위는 모델 A 대 모델 B가 아닙니다. 그것은 귀하의 데이터에서, 귀하가 실제로 감당할 수 있는 품질, 지연 시간, 비용 조건하에서의 구성 A(configuration A) 대 구성 B(configuration B)입니다.

스택을 건드리기 전에 작업을 정의하세요

검색(Retrieval), 모니터링(monitoring), 요약(summarization), 중재(moderation), 메타데이터 추출(metadata extraction), 그리고 질의응답(Q&A)은 서로 다른 작업입니다. 이들은 서로 다른 출력을 생성하며 서로 다른 오류를 허용합니다. 모델을 선택하기 전에 다음 네 가지를 작성하십시오:

• 시스템이 무엇을 생성하는가 (순위가 매겨진 클립 목록, 알림, 요약, 답변, 구조화된 메타데이터).
• 실제 상황에서 성공이란 무엇인가 (미검출(miss)과 오탐(false alarm) 중 어느 실패가 더 비용이 많이 드는지 포함).
• 작업이 어떤 신호(signal)에 의존하는가 (정적 프레임, 움직임, 음성, 장면 전환, 화면상의 텍스트).
• 어떤 제약 조건 하에서 실행되는가 (실시간(real time), 배치(batch), 저비용, 품질 우선).

이러한 답변들이 어디서부터 시작해야 할지를 알려줍니다. 수명이 짧은 동작은 더 밀도 높은 샘플링과 더 많은 프레임을 요구합니다. 대부분 정적인 비디오는 더 가벼운 추출 방식으로도 충분합니다. 지연 시간이나 비용 압박이 있다면 벤치마크 초기에 저렴한 구성들을 배치해야 합니다.

프로덕션 결정에 맞춰 데이터셋을 구축하세요

데이터셋은 평가 (eval)의 중심입니다. 공개 벤치마크 (Public benchmarks)는 무결성 검사 (sanity check) 용도로는 괜찮지만, 팀들이 실제로 궁금해하는 질문, 즉 '이것이 자신들의 영상 (footage)에서도 작동하는가?'에 대한 답은 주지 못합니다.

유용한 데이터셋에는 일반적인 사례 (normal cases), 어려운 사례 (hard cases), 아슬아슬하게 틀린 부정 사례 (near-miss negatives), 지루한 구간 (boring stretches), 그리고 이미 알고 있는 실패 모드 (failure modes)가 포함되어야 합니다. 보안 감시 (Surveillance) 데이터에는 폐쇄 (occlusion), 저조도 (low light), 모션 블러 (motion blur), 빈 장면 (empty scenes), 그리고 혼잡한 장면 (crowded scenes)이 포함되어야 합니다. 회의 (Meeting) 데이터에는 대화 중복 (crosstalk), 화면 공유 (screen shares), 불량한 오디오 (poor audio), 그리고 긴 정적 구간 (long static sections)이 포함되어야 합니다. 라벨링하기 쉬운 것을 중심으로 데이터셋을 구축하지 마세요. 당신이 내려야 하는 결정 (decision)을 중심으로 구축하세요.

단일 숫자가 아닌 태스크 (task)를 점수화하세요

검색 (retrieval)의 경우, 질문은 '올바른 순간이 나타나는가', '순위가 얼마나 높은가', 그리고 '유사하지만 틀린 클립이 제외되는가'입니다. 알림 (alerting)의 경우, '알림 스트림이 사용 가능한가'가 관건입니다. 요약 (summarization)의 경우, '사실적으로 정확하며 허구의 내용을 만들어내지 않는가'가 중요합니다. 메타데이터 추출 (metadata extraction)의 경우, 필드별로 점수를 매기는 것이 더 나은 경우가 많습니다. 놓친 이벤트 (missed events)와 오보 (false alarms) 중 어느 것이 더 큰 비용을 초래하는지 초기에 결정하세요. 이는 학술적인 문제가 아니라 제품 (product)의 선택 문제입니다.

모든 결과를 추적 가능하게 유지하세요

벤치마크는 단순한 점수가 아닙니다. 어떤 정확한 입력 (input)이 이 출력 (output)을 만들었는지, 어떤 구성 (configuration)이 이를 생성했는지, 어떻게 점수가 매겨졌는지, 그리고 두 번의 실행 (run) 사이에 무엇이 변했는지를 알고 싶을 것입니다. 항목별 컨텍스트 (per-item context: 비디오 ID, 장면 시작 및 종료, 프레임 URL, 추출 구성, 프롬프트, 모델, 출력, 점수)를 유지한다는 것은, 성능 퇴보 (regression)가 발생했을 때 이를 미스터리가 아닌 원인으로 지목할 수 있음을 의미합니다. 저희는 이 저장소 (repo)에서 이 계층을 위해 Langfuse를 사용하지만, 이 원칙은 어떤 트레이싱 (tracing) 설정에서도 동일하게 적용됩니다.

출력을 사용하여 결정을 내리세요

목표는 리더보드 (leaderboard)를 만드는 것이 아닙니다. 실행이 끝날 때쯤이면 어떤 설정이 기본 경로 (default path)가 될지, 어떤 가벼운 설정이 쉬운 케이스에 충분한지, 어려운 슬라이스 (hard slices)를 위해 어떤 더 강력한 설정을 남겨두어야 할지, 그리고 시스템이 여전히 어디에서 실패하는지를 알고 있어야 합니다. 그리고 품질이 부족할 때, 더 큰 모델을 찾기 전에 가장 먼저 시도해야 할 해결책은 종종 모델에 더 많은 신호 (signal)를 제공하는 것 (더 조밀한 샘플링 (denser sampling), 더 많은 프레임 (more frames), 더 나은 장면 경계 (better scene boundaries))입니다.

자신의 데이터로 실행해 보세요

저희는 여러분이 자신의 비디오에 대해 동일한 프로세스를 실행하고, 자신만의 메트릭 (metrics)을 정의하며, 자신만의 모델을 교체하고, 스택 (stack)을 다시 구축하지 않고도 설정을 비교할 수 있도록 파이프라인 (pipeline)을 오픈 소스로 공개했습니다.

• 원본 연구 노트 (canonical): https://labs.videodb.io/research/how-to-evaluate-multimodal-vlms-for-your-video-use-case
• 리포지토리 (Repo): https://github.com/video-db/benchmark-vlms

워크플로우 (workflow)나 트레이드오프 (tradeoffs)에 대한 질문이 있다면 댓글로 기꺼이 답변해 드리겠습니다.