3-Way 비교: Graph-VLM vs Frame Baseline vs Describe-Once

TL;DR

Describe-Once 압승: 80.7% — VLM description을 그대로 context로 사용하는 것이 가장 강함
Graph의 고유 정답: 560개 중 단 20개(3.6%)만 Graph 단독 정답 — 주로 EM3(시간), T2(상태), T3(인과)
결정적 발견: 그래프는 같은 description의 lossy compression. query plan에서 정보가 fragmentation됨
유일한 동률: L4(장기기억) 75% = Describe 75%, EM4(요약) 71.1% = Describe 71.1% — broad query에서 손실 없음
Describe-Once 비용: $0.91 (560 calls) — context caching 없이도 저렴, letsur gateway caching 미지원 확인

67.9%

Graph (Norm1)

70.0%

Frame (20f)

80.7%

Describe-Once

Graph-unique

1 배경 / 목적

Frame baseline (20프레임 균일 샘플링)이 27.5분 영상의 90% 이상을 못 보기 때문에 불공정한 비교라는 문제 제기. Graph-VLM과 진짜 공정한 baseline을 비교하여 그래프 구조화 단계 자체의 부가가치/손실을 측정하고자 했음.

세 시스템 비교 구조: Graph-VLM: 영상 → VLM 분석 → description → 그래프 변환 → query → context → MCQ Frame baseline: 영상 → 20프레임 균일 샘플링 → 이미지 직접 입력 → MCQ Describe-Once: 영상 → VLM 분석 → description → 통째로 context → MCQ ↑ 차이점은 단 하나: "그래프 구조화" 단계

Context Caching 시도 실패: letsur gateway에서 /v1/caches, /v1beta/cachedContents 모두 404. extra_body={"cached_content": "test"}도 응답 None. Google API 직접 키 필요.

2 작업 내용

Describe-Once 구현 (/tmp/run_describe_baseline.py)

기존 QA 생성 시 만들어둔 data/qa/P01_01_0_1652_desc.json (28개 segment description) 재사용 — 추가 비용 0. 28개 segment를 시간순으로 합쳐 단일 텍스트 (~40K chars)로 구성. 각 질문마다 전체 description + 질문 + 4지선다를 VLM에 입력.

3-Way Overlap 패턴 분석

세 시스템 각각의 correct/incorrect를 매칭해 8가지 패턴(GFD, GF-, G-D, G--, -FD, -F-, --D, ---)으로 분류. 카테고리/난이도별 집계.

3 결과

전체 정확도 비교

시스템	정확도	비용	L1	L2	L3	L4
Graph-VLM (Norm1)	67.9%	$1.86	62.4%	62.0%	80.2%	75.0%
Frame Baseline (20f)	70.0%	$0.46	67.4%	65.5%	78.4%	66.7%
Describe-Once	80.7%	$0.91	79.6%	76.5%	87.4%	75.0%

카테고리별 비교

Category	Graph	Frame	Describe	최고	Graph vs Describe
EM1 (물건)	68.9%	73.1%	76.5%	D	-7.6%p
EM2 (행동확인)	56.4%	70.9%	81.8%	D	-25.4%p
EM3 (시간기억)	63.2%	57.5%	87.4%	D	-24.2%p
EM4 (요약)	71.1%	76.3%	71.1%	F	TIE
EM5 (과정)	80.5%	81.8%	83.1%	D	-2.6%p
T1 (시간특정)	48.3%	48.3%	69.0%	D	-20.7%p
T2 (상태)	63.5%	71.6%	87.8%	D	-24.3%p
T3 (인과)	79.3%	72.4%	81.0%	D	-1.7%p

3-Way Overlap 패턴 (560개)

패턴	의미	수량	비율
`GFD`	모두 맞음	273	48.8%
`G--`	Graph만 맞음	20	3.6%
`G-D`	Graph+Describe만	57	10.2%
`GF-`	Graph+Frame만	30	5.4%
`-FD`	Frame+Describe만 (Graph 실패)	67	12.0%
`--D`	Describe만	55	9.8%
`-F-`	Frame만	22	3.9%
`---`	모두 틀림	36	6.4%

Graph만 맞춘 20개 대표 사례

Q: 사람이 주키니를 씻는 데 얼마나 걸렸어? 정답 D: 12초 → Graph: D ✓ (action.duration = 12s) → Frame: 틀림 (20프레임으로 정확한 duration 추정 불가) → Describe: 틀림 (description의 시간 정보 해석 실패) Q: 흰색 셰이커 병이 요리 과정에서 언제 사용됐어? 정답 B: 주키니를 처음 저은 후 → Graph: B ✓ (action 시간순 + participates 엣지) → Frame: 틀림 | Describe: 틀림 Q: 다음 중 메인 요리 동작 요약? 정답 B: 양파 자르고 스토브에서 채소 저음 → Graph: B ✓ (action 노드 집계로 핵심 동작 추출)

Graph 고유 가치 영역: EM3(시간기억) 6건, EM5(과정) 3건, T2(상태) 3건, T3(인과) 3건. 공통점: 정확한 수치·순서·관계가 필요한 질문.

4 Takeaway

그래프는 같은 description의 lossy compression

세 시스템 모두 같은 VLM frame description에서 출발. Describe-once는 그대로 사용, Graph는 그래프로 변환 후 query로 일부만 추출. 결과: Graph가 12.8%p 손해 — 그래프 변환 + 쿼리 과정이 정보 손실을 만들고 있음.

EM3/T2가 그래프 강점이라 믿었는데 Describe에게 가장 크게 패배

EM3(시간기억): -24.2%p, T2(상태추적): -24.3%p. Describe는 description에 이미 시간/상태 정보가 텍스트로 있어서 그대로 답할 수 있음. Graph는 query plan이 해당 정보를 fragmentation 없이 추출하지 못하는 것.

L4/EM4 동률의 의미: Broad query에서는 그래프 변환 손실이 없음. 영상 전체에 걸친 집계/요약 질문에서는 그래프 context도 충분. 이게 그래프의 진짜 강점 영역.

현실적 평가: Describe-once는 자기가 만든 description에서 답을 찾는 cheating 측면이 있음. 그러나 같은 description에서 출발한 Graph가 더 못 답한다는 사실은 변하지 않음.

5 Next Steps

가설 검증 실험

Graph-Full Context: query plan 우회하고 그래프 전체를 텍스트로 변환해서 context 사용. 만약 Graph-Full ≈ Describe-once → query plan만 고치면 됨. 만약 Graph-Full < Describe-once → 그래프 빌드 자체가 손실.

Query Plan 개선

Multi-object query 구현 (participant([zucchini, diced_zucchini, ...])). Plan fail 시 점진적 fallback (participant → time range → all). Plan이 잡은 결과가 너무 작으면 자동 확장.

그래프 + frames 하이브리드

Graph context + 관련 keyframe 함께 제공. L1에서 그래프가 약한 시각 디테일 영역을 keyframe으로 보충. 이미 일부 구현됨 (vqa_pipeline.py) — 효과 측정 필요.