VLM : 논문리뷰 : Video Question Answering with Procedural Programs

쉬운 설명

ProViQ의 핵심 아이디어는 복잡한 video 질문을 받았을 때, 혼자서 모든 걸 해결하려는 만능 "요리사"(end-to-end model)에게 맡기는 대신, "총괄 셰프"(LLM)가 명확한 레시피(Python 프로그램)를 작성하는 것과 같습니다. 이 레시피는 각 분야의 전문 "보조 셰프"(visual modules)들에게 전달됩니다. 예를 들어, "주황색 바지를 입은 스키어의 재킷 색깔은?"이라는 질문에, 총괄 셰프는 다음과 같은 레시피를 작성합니다.

1. "A 보조 셰프, 비디오에서 '주황색 바지를 입은 스키어'를 찾아내세요." (filter_object)
2. "B 보조 셰프, 찾아낸 스키어에게서 '재킷'을 찾아내세요." (find)
3. "C 보조 셰프, 그 재킷의 '색깔'이 무엇인지 알려주세요." (video_query)

이 방식의 장점은 작업 과정이 투명하고(interpretable), 각 보조 셰프가 자신의 전문 분야에만 집중하여 더 정확한 결과를 내며, 새로운 요리 기술(새로운 모듈)이 필요할 때 해당 기술을 가진 보조 셰프를 쉽게 추가할 수 있다는 점입니다.

 

 

용어 설명 (Glossary)

• ProViQ (Procedural Video Querying): 이 논문에서 제안하는 핵심 method. LLM을 사용해 video에 대한 질문을 해결하는 Python 프로그램을 생성하고 실행하는 zero-shot video question answering framework.
• Procedural Reasoning: 복잡한 문제를 해결하기 위해 문제를 순차적인 단계(procedure)로 분해하여 추론하는 방식. ProViQ는 이 방식을 코드 생성으로 구현함.
• Visual Modules: ProViQ가 생성하는 프로그램이 호출할 수 있는 시각적 기능들의 API 집합. 특정 시각적 하위 작업을 수행하는 "도구" 역할을 함.
  • filter_property/filter_object: 특정 속성이나 객체가 있는 frame들을 필터링.
  • video_query: video clip에 대한 질문에 답하는 VQA 모듈.
  • get_summary: 긴 video의 내용을 요약하여 서사(narrative)를 생성하는 모듈.
  • find: 이미지 내 특정 객체의 bounding box를 찾아냄.
• Code Generation Model: 주어진 질문과 API를 바탕으로 이를 해결하기 위한 Python 프로그램을 생성하는 Large Language Model (LLM).
• In-Context Examples: LLM이 더 정확한 프로그램을 생성하도록 prompt에 함께 제공되는 몇 가지 질문-프로그램 예시. RAG(Retrieval-Augmented Generation) 방식을 통해 질문과 가장 유사한 예시를 선택.
• Video-Centric Modules: 단순히 frame별로 작동하는 image 기반 모듈과 달리, video의 시간적(temporal) 특성, 서사(narrative), 효율성을 고려하여 설계된 모듈.

Purpose of the Paper

기존 video QA 연구의 한계를 극복하고 새로운 접근 방식을 제시하는 것을 목표로 함.

• 기존 End-to-End 모델의 한계:
  • 복잡한 compositional reasoning (여러 단계를 조합하는 추론)에 취약함.
  • 동작 방식이 불투명하여(black box) 결과의 해석이 어렵고, 오류가 발생했을 때 원인 파악이 힘듦.
• 기존 Procedural Image QA 모델 (ViperGPT 등)의 한계:
  • Image에 특화되어 있어 video에 바로 적용하기 비효율적임. Frame 단위로 반복 실행해야 하므로 매우 느리고, video의 시간적 연속성이나 temporal reasoning을 제대로 처리하지 못함.
  • 긴 video의 high-level narrative를 이해하는 능력이 없음.
• 이 논문의 접근 방식:
  • Image QA에서 성공한 procedural programming 접근법을 video에 성공적으로 확장하는 것을 목표로 함.
  • 이를 위해, video의 특성을 효과적으로 다룰 수 있는 video-centric 모듈 API를 새롭게 설계하고, LLM이 이 API를 활용해 효율적이고 해석 가능한 프로그램을 생성하도록 함.

Key Contributions & Novelty

1. ProViQ: Video를 위한 최초의 LLM 기반 코드 생성 QA Framework 제시
   • Contribution: LLM이 video-centric API를 호출하는 Python 코드를 생성하여 zero-shot으로 video QA를 수행하는 ProViQ framework를 제안.
   • Novelty: 기존 procedural reasoning을 video 영역으로 확장하면서, video의 고유한 특성(시간, 서사)을 다룰 수 있는 최초의 체계적인 code generation 기반 video QA 방법론임.
2. Novel Video-Centric Visual Modules 설계
   • Contribution: filter_property (시간적 필터링), get_summary (긴 video 요약), get_script (음성-자막 활용) 등 video 처리에 최적화된 새로운 모듈들을 개발.
   • Novelty: 이 모듈들은 ViperGPT처럼 단순히 image tool을 frame에 반복 적용하는 것이 아니라, video의 시간적, 서사적 구조를 직접 다루도록 설계되어 효율성과 성능을 극대화함. (e.g., Figure 5에서 ViperGPT의 복잡한 for loop과 ProViQ의 간결한 함수 호출을 비교)
3. 다양한 Benchmark에서 State-of-the-Art (SOTA) 달성
   • Contribution: 짧은 video, 긴 video, open-ended, multiple-choice 등 다양한 VQA 데이터셋에서 zero-shot 설정으로 SOTA 성능을 달성.
   • Novelty: 별도의 fine-tuning 없이 supervised SOTA 모델의 성능을 상회하는 결과를 보여줌으로써, 제안한 procedural reasoning 접근법의 강력한 일반화 성능과 효율성을 입증.
4. QA를 넘어선 확장성(Extensibility) 입증
   • Contribution: 동일한 ProViQ framework를 수정 없이 사용하여 multi-object tracking, basic video editing과 같은 다른 video task도 수행 가능함을 보임.
   • Novelty: LLM이 모듈을 창의적으로 조합하여 코드를 생성하는 방식 덕분에, 별도의 학습 없이도 새로운 task에 유연하게 적용할 수 있는 procedural 접근법의 잠재력을 보여줌.

Experimental Highlights

• 압도적인 Zero-shot 성능:
  • 다양한 VQA 벤치마크(TGIF, MSRVTT, iVQA, NeXT, TVQA, EgoSchema)에서 기존 zero-shot SOTA 모델들을 큰 차이로 능가.
  • 특히, 긴 비디오를 다루는 EgoSchema에서 25%, TGIF-QA에서 15%의 큰 성능 향상을 기록.
  • iVQA, NeXT-QA에서는 zero-shot 모델임에도 supervised SOTA 모델을 능가하는 놀라운 결과를 보임. (Table 1)
• Ablation Study를 통한 모듈의 효과 검증:
  • 단순 image QA 모듈에서 시작해 video_query, filter, find 등 video-centric 모듈을 점진적으로 추가할수록 대부분의 데이터셋에서 성능이 향상됨을 보임. (Table 2)
  • 이는 새롭게 제안한 video-centric 모듈들이 성능 향상의 핵심 요인임을 증명.
• In-Context Examples의 중요성:
  • Prompt에 예시를 전혀 제공하지 않았을 때(0-shot)는 성능이 매우 낮았지만, 단 1~3개의 예시만으로도 성능이 급격히 향상됨. (Figure 6)
  • 이는 LLM이 올바른 형식의 코드를 생성하도록 유도하는 데 in-context learning이 결정적인 역할을 함을 시사.

Limitations and Future Work

• Limitations:
  1. Module Dependency: ProViQ의 성능은 제공된 API 모듈의 능력에 크게 의존함. 만약 API에 정의되지 않은 새로운 유형의 질문이 들어오면 해결하기 어려움.
  2. Execution Speed: End-to-end 모델과 비교했을 때, code generation과 program execution 단계가 추가되어 추론 속도가 상대적으로 느림.
• Future Work:
  1. Module 확장성: 새로운 task나 질문 유형에 맞춰 필요한 모듈을 자동으로 생성하거나 적응시키는 연구를 통해 현재의 module dependency 한계를 극복할 수 있음.
  2. 속도 최적화: code generation 및 execution 파이프라인을 최적화하여 추론 속도를 개선하는 방향으로 발전 가능.

Overall Summary

이 논문은 LLM을 이용해 video에 대한 질문을 해결하는 Python 프로그램을 생성 및 실행하는 zero-shot VQA framework인 **ProViQ**를 제안합니다. 핵심은 video의 시간적, 서사적 구조를 효율적으로 다루는 video-centric 모듈 API를 새롭게 설계하여, 기존 image 기반 procedural 접근법의 한계를 극복한 것입니다. 그 결과, ProViQ는 별도의 학습 없이도 수많은 VQA 벤치마크에서 supervised 모델을 뛰어넘는 SOTA 성능을 달성했으며, video editing과 같은 다른 태스크로의 확장성까지 입증했습니다. 이 연구는 복잡한 video understanding 문제를 해결하는 데 있어 procedural reasoning을 통한 코드 생성이 매우 강력하고 해석 가능한 접근법임을 보여주는 중요한 기준점을 제시합니다.

 

Abstract

우리는 final answer를 얻기 위해 visual subtasks를 해결하는 짧은 procedural programs를 generation하여 video에 대한 question에 답하는 것을 제안합니다. 우리는 prompt에 있는 입력 question과 visual modules의 API로부터 그러한 programs를 generate하기 위해 large language model을 사용하고, 이를 executes하여 output을 얻는 Procedural Video Querying (ProViQ)를 제시합니다. 최근의 유사한 procedural approaches는 image question answering에 성공적인 것으로 입증되었지만, image-centric modules와 temporal reasoning 능력의 부족으로 인해 video에 대한 question에 효과적으로 또는 효율적으로 답할 수 없습니다. 우리는 video understanding을 위해 고안된 새로운 modules를 ProViQ에 제공하여 추가적인 training 없이 다양한 video에 generalize할 수 있도록 함으로써 이 문제를 해결합니다. 결과적으로, ProViQ는 긴 video에서 관련 순간을 효율적으로 찾고, causal 및 temporal reasoning을 수행하며, complex questions에 답하기 위해 긴 시간대에 걸쳐 video를 summarize할 수 있습니다. 이 code generation framework는 추가적으로 ProViQ가 question answering을 넘어 multi-object tracking이나 기본 video editing과 같은 다른 video tasks를 수행할 수 있게 합니다. ProViQ는 다양한 benchmarks에서 state-of-the-art 결과를 달성했으며, short, long, open-ended, multiple-choice 및 multimodal video question-answering datasets에서 최대 25%의 향상을 보였습니다.

 

 

이미지 내용 설명

이 이미지는 논문의 Figure 1로, ProViQ라는 method가 video에 대한 question에 어떻게 답하는지 그 과정을 시각적으로 보여줍니다.

이미지 상단에는 "주황색 바지를 입은 스키어는 어떤 색 재킷을 입었나요? (Query: What color jacket did the skier with orange pants wear?)"라는 질문과 함께, 스키를 타는 장면이 담긴 video의 여러 frame들이 나열되어 있습니다.

이미지 하단은 이 질문을 해결하기 위해 ProViQ가 수행하는 3단계의 절차적 과정을 보여줍니다.

1. Find the skier with orange pants (주황색 바지를 입은 스키어 찾기) video에서 "주황색 바지를 입은 스키어"를 찾으라는 code를 실행하여 해당 장면이 포함된 video clip을 찾아냅니다. (Code: skier_clip = video.filter_object("skier with orange pants"))
2. Find the jacket (재킷 찾기) 이전 단계에서 찾은 clip 속 스키어에게서 "jacket"을 찾으라는 code를 실행합니다. 이미지에서는 초록색 상자로 스키어를 특정하여 보여줍니다. (Code: jacket_boxes = skier_clip.find("jacket"))
3. Find the color of the jacket (재킷의 색상 찾기) 찾아낸 재킷 부분에 "이 재킷은 무슨 색이야?"라고 query를 실행하여 최종적으로 "Blue"라는 response(응답)를 얻습니다. (Code: response = jacket_boxes.video_query("What color jacket is this?"))

이미지 하단의 설명(caption)은 "우리의 method인 ProViQ는 visual subtasks를 해결하는 Python programs를 generating하고 executing하여 video에 대해 procedurally reasoning하며, 이는 인간이 문제에 접근하는 방식을 모방한 것입니다."라고 요약하고 있습니다.

1 Introduction

Figure 1의 video를 생각해 보십시오. 주황색 바지를 입은 스키어는 어떤 색 재킷을 입었습니까? 이 question에 답하기 위해, 사람들은 각 frame에서 스키어를 찾고, 그 frame들에서 주황색 바지를 입은 스키어를 검색한 다음, 그들이 어떤 색 재킷을 입었는지 확인할 것입니다. 이 예처럼, 인간은 문제를 일련의 단계로 나누어 절차적으로 해결하는 경향이 있으며, 각 단계는 구체적인 결과를 가집니다. 우리는 이러한 유형의 reasoning을 사용하는 것이 video question answering (QA)의 performance를 크게 향상시킬 수 있다고 가정합니다.

기존의 video QA methods는 이 접근법을 따르지 않습니다. video understanding의 주된 paradigm은 supervised end-to-end model을 train하는 것이며, 일반적으로 Kinetics나 Ego4D와 같은 대규모 video datasets에서 pre-training한 후, 상대적으로 작은 QA benchmarks에서 fine-tuning합니다. FrozenBilM이나 SeViLa와 같은 일부 zero-shot 및 few-shot QA methods는 pre-trained video backbones와 language models를 결합하여 어느 정도 성공을 거두었지만, 여전히 procedural reasoning을 명시적으로 수행할 수는 없습니다. GPT-4V나 Gemini와 같은 최근의 large multimodal language models는 매우 강력한 performance를 보이지만, closed-source이며 실행 비용이 비싸고 쉽게 intepretable하지 않습니다.

반면에, ViperGPT나 VISPROG와 같은 최근 연구들은 large language models (LLMs)를 사용하여 바로 이러한 유형의 reasoning을 위한 짧은 programs를 generate하여 compositional image tasks에서 강력한 결과를 달성했습니다. visual subtasks를 해결하는 modules의 API가 주어지면, 이러한 methods는 이 modules를 호출하는 programs를 generate하고 그 program을 execute하여 final answer를 얻습니다. LLMs가 작동하고 정확한 code를 generate할 수 있고, 제공된 modules가 대규모 image datasets에서 pre-trained된 models에 의존하기 때문에, 이는 training이 필요 없습니다.

이러한 연구들이 images에서 강력한 결과를 보여주지만, video로 잘 이전되지는 않습니다. 이들은 images에 대해 reason하도록 설계되었기 때문에, 여러 frames에 걸쳐 정보를 aggregate하거나, 긴 video에서 정보를 효율적으로 찾거나, high-level narrative를 이해할 명확한 방법이 없습니다. 간단히 말해, 그들의 modules는 video에 대해 reasoning할 수 없습니다. 예를 들어, ViperGPT는 생성된 code에서 개별 predicates를 충족시키기 위해 video의 각 frame을 반복해야 하며, 어떤 reasoning 조각에 대해서도 단일 frame만 고려할 수 있습니다. 이것은 매우 느릴 뿐만 아니라, underlying modules의 noisy predictions에 취약합니다. 더욱이, 이러한 underlying large pretrained image models를 유사한 video models로 교체하는 것은 간단하지 않습니다. 큰 computational burden과 training data의 상대적인 부족으로 인해, 고품질의 video models는 훨씬 적게 사용 가능하며, 사용 가능한 것들도 동일한 수준의 performance를 제공하지 않습니다.

우리는 이러한 단점들을 해결하는 Procedural Video Querying (ProViQ)를 소개합니다. ProViQ는 video-centric modules의 API, input query, 그리고 관련 in-context examples를 LLM에 제공합니다. 그러면 LLM은 video modules를 사용하는 Python program을 generate하고, 이를 execute하여 query에 대한 final answer를 얻습니다. 개별 video modules 자체만으로는 query에 직접 답할 수 없지만, ProViQ는 question answering을 위한 subtasks를 해결하기 위해 이들을 programmatically 결합함으로써 보완합니다. 특히, 우리는 video retrieval, captioning, summarization, multi-object tracking을 가능하게 하는 modules와 object detection, segmentation, captioning과 같은 image-based tasks를 위한 modules를 포함합니다. 이러한 modules는 frame-level, clip-level, video-level reasoning을 가능하게 하여, ProViQ가 video에 대한 question에 효율적이고 효과적으로 답할 수 있도록 합니다.

ProViQ의 videos에 대한 procedural reasoning은 여러 가지 이점이 있습니다. 첫째, 이전의 visual programming 연구들처럼, ProViQ는 추가적인 training이 필요 없습니다. 이는 task-specific modules의 원활한 통합을 가능하게 하여, fine tuning 없이 새로운 유형의 question을 해결하기 위한 capabilities를 간단히 추가할 수 있게 합니다. 둘째, program의 reasoning은 interpretable합니다: program의 각 라인은 specific modules에 대한 오류를 귀속시키는 데 도움이 될 수 있습니다. 셋째, LLM은 modules를 자유롭게 compose할 수 있어 question-answering을 넘어서는 capabilities를 가능하게 합니다. 우리는 object detector와 tracker modules를 결합하면 query-based multi-object tracking system이 생성되고, retrieval module은 단 몇 줄의 code를 generate하는 것만으로 기본적인 video editing에 사용될 수 있음을 보여줍니다.

ProViQ는 이러한 이점들을 활용하여 광범위한 zero-shot video question answering benchmarks에서 상당한 향상을 이룹니다: 우리는 ActivityNet, iVQA, MSR-VTT-QA, MSVD-QA, TGIF-QA, NeXT-QA에서 추가 training 없이 최대 25%의 향상을 이루었으며, 일부 datasets에서는 supervised state-of-the-art를 능가하기도 합니다. 우리는 또한 도전적인 EgoSchema benchmark에서 25%의 향상을 통해 long egocentric videos를 이해하는 데 강력한 performance를 보여주었으며, multimodal understanding에 있어서도 TVQA dataset에서 state-of-the-art performance를 달성했습니다.

요약하자면, 우리의 contributions는 다음과 같습니다.

1. 우리는 새로운 video tools의 사용을 통해 visual programming을 video QA로 성공적으로 확장하는 method인 ProViQ를 제시합니다.
2. 이러한 새로운 modules를 사용하여, 우리는 광범위한 video QA benchmarks에서 큰 accuracy 향상을 달성했으며, experiment와 포괄적인 ablations를 통해 입증된 바와 같이 open-ended, multiple choice, long video tasks에서 state-of-the-art를 설정했습니다.
3. ProViQ는 multi-object tracking이나 기본 video editing과 같이 question answering을 넘어서는 추가적인 tasks를 수행할 수 있습니다.

 

 

ProViQ Introduction 정리노트 (for AI Researchers)

ProViQ 개요

ProViQ (Procedural Video Querying)는 LLM을 활용하여 video에 대한 질문에 답하는 zero-training framework이다. 기존의 end-to-end 방식이나 image-centric procedural 방식의 한계를 극복하기 위해 제안되었다.

핵심 아이디어 (Core Idea)

ProViQ의 핵심은 LLM이 Python program을 동적으로 generating한다는 점에 있다. 이 program은 사전에 정의된 video-centric visual modules의 API를 호출하여, 복잡한 질문을 여러 visual subtask로 분해하고 순차적으로 해결한다. 이는 image 분야에서 성공한 ViperGPT와 같은 visual programming 접근법을 video 영역으로 성공적으로 확장한 것이다.

주요 특징 및 장점

• Video-Centric Modules: 기존 image-based 접근법과 가장 큰 차별점. ProViQ는 video의 시간적, 서사적 맥락을 이해하기 위해 다음과 같은 새로운 modules를 도입했다.
  • Video retrieval 및 summarization
  • Multi-object tracking
  • Clip-level 및 video-level reasoning 지원
• Zero-Training 및 Interpretable:
  • 사전 fine-tuning이 필요 없어 새로운 module을 추가하는 것만으로 손쉽게 기능 확장이 가능하다.
  • LLM이 생성한 code가 곧 reasoning 과정이므로, 각 단계의 성공 여부 및 오류 원인 파악이 용이하여 interpretable하다.
• Task Extensibility (Compositionality):
  • LLM이 modules를 자유롭게 조합하여 Question Answering 이외의 task 수행이 가능하다.
  • 예시: object detector와 tracker를 조합하여 query-based multi-object tracking 시스템 구현, retrieval module을 활용한 basic video editing.

성능 (Performance)

• 다양한 zero-shot video QA benchmarks (ActivityNet-QA, EgoSchema, TVQA 등)에서 state-of-the-art (SOTA) 달성.
• 기존 supervised SOTA 모델을 능가하는 성능을 보이며, 일부 dataset에서는 최대 25%의 성능 향상을 기록했다.

핵심 Contributions

1. Visual Programming의 Video 영역 확장: 새로운 video tools를 통해 visual programming을 Video QA에 성공적으로 적용.
2. SOTA 달성: 새로운 modules를 활용하여 open-ended, multiple-choice, long video 등 광범위한 Video QA task에서 SOTA 달성.
3. QA를 넘어서는 확장성: Multi-object tracking, video editing 등 추가 task 수행 가능성을 입증.

---

쉬운 설명:

사람이 "주황색 바지를 입은 스키어가 입은 재킷 색깔은?"이라는 질문을 받으면, 머릿속으로 '1. 주황색 바지를 입은 사람을 찾는다. 2. 그 사람이 입은 재킷을 본다. 3. 재킷의 색깔을 확인한다.' 와 같이 순서대로 생각합니다.

기존의 AI들은 비디오 전체를 한 번에 보고 답을 '찍는' 방식에 가까워서, 이렇게 여러 단계를 거쳐야 하는 복잡한 질문에 약했습니다.

ProViQ는 AI가 사람처럼 순서대로 생각하도록 가르치는 새로운 방법입니다. 똑똑한 AI(LLM)에게 비디오를 처리할 수 있는 여러 '도구'(visual modules)가 담긴 '공구함'을 줍니다. 이 공구함에는 '특정 장면만 찾아주는 도구', '움직이는 물체를 계속 따라가는 도구', '비디오 내용을 요약해주는 도구' 등이 들어있습니다.

질문을 받으면, ProViQ는 스스로 '작업 계획서'(Python program)를 작성합니다. 위 질문의 경우, "1. '주황색 바지 스키어 찾기' 도구를 써라. 2. 찾았으면 '재킷 찾기' 도구를 써라. 3. 마지막으로 '색깔 분석' 도구를 써라." 와 같은 계획서를 만드는 것이죠.

이렇게 스스로 짠 계획서와 공구함을 이용해 문제를 차근차근 해결하기 때문에 훨씬 정확하고 복잡한 질문에도 답을 잘 찾아냅니다. 또한, AI가 어떤 순서로 생각해서 답을 찾았는지 '작업 계획서'를 통해 쉽게 알 수 있고, 새로운 도구를 공구함에 넣어주기만 하면 AI를 처음부터 다시 학습시킬 필요 없이 새로운 능력도 가질 수 있게 됩니다.

 

 

 

 

 

 

이미지 내용 설명

이 이미지는 논문의 Figure 2로, ProViQ method의 전체적인 작동 방식을 보여주는 다이어그램입니다.

이 시스템은 Code Generation Model(LLM)을 중심으로 동작하며, 다음과 같은 과정을 거칩니다.

1. 입력 (Inputs to LLM): LLM은 질문에 대한 답을 찾기 위해 세 가지 정보를 입력받습니다.
   • Query: 사용자가 던진 실제 질문입니다. (예: "사람이 요거트를 젓는 데 무엇을 사용했나요? / What did the person use to beat the yogurt?")
   • Visual Module API: LLM이 video를 분석할 때 사용할 수 있는 함수(도구)들의 목록과 설명서입니다. 예를 들어, video에서 특정 속성을 가진 객체를 찾는 filter_property나, 특정 장면에 대해 질문하는 video_query 같은 함수들이 정의되어 있습니다.
   • Relevant Examples (RAG): LLM이 어떤 형식으로 program을 만들어야 할지 참고할 수 있도록, 비슷한 질문과 그에 대한 정답 program 예시들을 함께 제공합니다.
2. Code Generation Model (LLM): LLM은 위 세 가지 정보를 바탕으로, 주어진 Query를 해결하기 위한 맞춤형 Python program을 실시간으로 생성합니다.
3. Generated Program: LLM이 생성한 Python program의 예시입니다. 이 program은 질문을 다음과 같은 논리적인 단계로 분해합니다.
   • 먼저 video에서 person(사람)을 찾는다.
   • 그다음, 찾은 person의 video segment 안에서 yogurt를 찾는다.
   • yogurt가 있는 segment 안에서 "사람이 요거트를 젓고 있는" 장면을 찾는다.
   • 마지막으로, 그 장면에 "사람이 무슨 도구를 사용하고 있나?"라고 질문하여 답을 찾는다.
4. Python Interpreter 및 실행: 이렇게 생성된 program은 Python Interpreter로 전달됩니다. Interpreter는 Input Video를 실제로 보면서 program의 명령어를 한 줄씩 실행합니다.
5. Output: program 실행이 완료되면 최종 결과인 "spoon"(숟가락)이라는 정답이 Output으로 나옵니다.

이미지의 설명(caption)은 이 과정을 "ProViQ는 code generation model의 prompt에 입력 question, visual API, 그리고 관련 examples를 제공한다. LLM은 API의 modules를 사용하여 question에 답하는 짧은 Python program을 generates한다. 우리는 video를 input으로 사용하여 이 program을 execute하여 final output을 얻는다"라고 요약합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

2 Related Work

2.1 Video Question Answering

다른 video tasks와 비교할 때, video question-answering datasets는 상대적으로 작습니다. Image QA에서와 마찬가지로, video QA의 주된 paradigm은 Kinetics, Ego4D, HowTo100M, 또는 YouTube-100M과 같은 large datasets에서 models를 pretrain한 다음, 더 작은 annotated QA datasets에서 fine-tune하는 것입니다. InternVideo, InternVid, mPLUG-Owl과 같은 최근 연구는 이러한 유형의 training을 상당히 확장했지만, 여전히 training distribution을 벗어난 videos에 대한 questions에 zero-shot으로 잘 generalize하지는 못합니다. 최근에는 GPT-4V나 Gemini 1.5와 같은 거대한 multimodal language models가 zero-shot video QA에서 좋은 성능을 보이는 것으로 밝혀졌지만, train하고 run하는 데 엄청난 비용이 듭니다.

zero-shot video QA를 직접 다루는 연구는 비교적 적습니다. BLIP은 image-question-answer triplets으로 대규모 model을 train하고 video QA tasks로의 transfer를 평가하지만, fine-tuning step을 포함합니다. 현재의 methods는 일반적으로 audio나 speech transcripts가 weak language supervision을 제공하는 web-scale datasets에서 trained됩니다. 특히, FrozenBiLM은 frozen bidirectional language encoder를 trainable video model과 연결하고, WebVid10M에서 trains하며 zero-shot question-answering performance를 측정합니다. 더 최근에는 SeViLa가 input query에 관련된 video frames를 식별하고 answer를 generate하기 위해 BLIP을 fine-tunes합니다. 이러한 methods는 현재 state-of-the-art results를 얻고 있으며, 우리는 Section 4.2에서 이들과 비교합니다. 또 다른 최근 연구 흐름은 language models와 textual descriptions 또는 드문드문 sampled된 frames로부터의 CLIP features와 같은 visual inputs의 조합을 사용하여 videos에 대한 대화를 가능하게 하지만, standard benchmarks에서 강력한 quantitative results를 달성하지는 못합니다.

2.2 Modular Vision

Neural Modular Networks (NMNs)는 modular visual question answering approaches를 도입했으며, parsers를 사용하여 학습된 modules를 단일 trainable network으로 compose했습니다. NMNs의 후속 methods는 reinforcement learning과 weak supervision을 사용하여 layout generator와 visual modules를 jointly trained했습니다. 다른 여러 연구에서는 다양한 modalities와 tasks를 위한 modules를 포함하는 large models를 train하지만, 이를 자유롭게 compose하거나 layout을 변경할 수는 없습니다.

지난 한 해 동안, CodeVQA, VISPROG, ViperGPT는 language modeling의 큰 발전을 활용하여 modular VQA를 code generation으로 재정의했습니다. 이들은 code generation에 대한 GPT-3와 GPT-4의 강력한 performance를 사용하여 visual questions에 대한 답을 짧은 Python programs로 formulate함으로써, visual models의 outputs을 manipulate하기 위해 mathematical operations, if-statements, logical operators를 사용할 수 있게 했습니다. ViperGPT는 NeXT-QA dataset에서 강력한 results를 제공하지만, 추가 experiments의 limiting factors로 길이와 temporally reason할 수 없는 점을 언급합니다. 우리는 ViperGPT의 approach를 동일한 program generation framework로 직접 기반으로 하여 video QA로 성공적으로 확장합니다.

2.3 Prompting and Tool Use

large language models에 대한 관심이 최근 급증하면서, 많은 논문들이 fine-tuning이나 prompting을 통해 추가적인 tools를 효과적으로 통합하는 방법을 연구해왔습니다. Flamingo나 GPT-4와 같은 large multimodal models의 성공에 이어, 최근 methods는 language models에 visual capabilities를 추가하기 위해 LLAVA나 MiniGPT-4와 같은 multimodal language models를 train합니다. 그러나 이들은 large-scale video data에 대한 training의 어려움 때문에 videos를 성공적으로 통합하지는 못했습니다.

CodeVQA, VISPROG, ViperGPT를 따라, 우리는 object detection이나 image QA와 같은 visual functions를 위해 여러 pre-trained models를 사용합니다. text-conditioned object detection을 위해 GroundingDINO를, image captioning과 QA를 위해 BLIP-2를, 그리고 multi-object tracking을 위해 ByteTrack을 사용합니다. 또한 video-to-language generation을 위해 LaViLa를 사용하고, code generating과 summaries querying을 위해 GPT3.5를 사용합니다. Concurrent work는 긴 videos를 summarizing하기 위해 우리와 유사한 language-based strategy를 제안하며, 독자들이 이 분야에 대한 더 완전한 시각을 위해 해당 연구를 검토하기를 권장합니다.

 

 

 

쉬운 설명:

ProViQ라는 AI가 왜 새로운지 이해하려면, 다른 AI들이 비디오 질문에 어떻게 답해왔는지 먼저 살펴볼 필요가 있습니다.

1. 암기왕 AI (Video QA 연구): 이 AI는 시험공부 하듯이 수많은 비디오와 질문-답변 쌍을 통째로 외웁니다(pre-train, fine-tune). 공부한 것과 비슷한 문제가 나오면 잘 풀지만, 생전 처음 보는 유형의 비디오나 질문(zero-shot)에는 당황해서 오답을 내기 일쑤입니다. 물론 GPT-4V처럼 모든 걸 아는 천재도 있지만, 이 천재를 부르려면 비용이 너무 많이 듭니다.
2. 레고 조립가 AI (Modular Vision 연구): 이 AI는 질문을 받으면, '물체 찾기 레고', '색깔 찾기 레고' 등 특수 레고 부품(module)들을 조립해서 답을 찾는 로봇을 만듭니다. 예전에는 이 레고들을 붙이기가 너무 까다로웠습니다. 최근에 ViperGPT라는 똑똑한 '레고 마스터'(LLM)가 등장해서, 어떤 질문이든 그에 맞는 레고 조립 설명서(code)를 뚝딱 만들어주는 혁신이 일어났습니다. 하지만 이 레고 마스터는 아쉽게도 평면 사진(image) 조립 설명서만 쓸 줄 알았고, 입체적인 영화(video) 설명서는 쓸 줄 몰랐습니다.
3. 앱 까는 AI (Tool Use 연구): 요즘 유행하는 방식입니다. AI에게 모든 걸 가르치는 대신, 똑똑한 AI 비서(LLM)에게 '물체 인식 앱', '움직임 추적 앱' 같은 여러 유용한 앱(tool)들을 스마트폰에 깔아주고 필요할 때마다 앱을 실행해 답을 찾게 하는 것입니다.

ProViQ의 위치: ProViQ는 바로 위에서 말한 '레고 조립가'와 '앱 까는 AI'의 장점을 합친 AI입니다. 드디어 **비디오 조립 설명서(code)를 쓸 줄 아는 '레고 마스터'(LLM)**가 된 셈이죠. 그리고 레고 부품들을 직접 만드는 대신, 이미 성능이 검증된 최고의 '앱'들(GroundingDINO, ByteTrack 등)을 내려받아 조립 설명서에 활용합니다. 덕분에 비싼 돈 들여 처음부터 공부할 필요 없이, 다양한 비디오 질문을 똑똑하게 해결할 수 있게 된 것입니다.

 

 

Related Work 정리노트 (for AI Researchers)

Video Question Answering 연구 동향 및 한계

• 주류 Paradigm: 대규모 dataset (Kinetics, Ego4D 등)에서 pre-train 후, 소규모 QA dataset에 fine-tune 하는 방식이 지배적이다.
• Zero-shot의 한계: Training 규모를 확장한 SOTA 모델들 (InternVideo 등)도 training distribution 밖의 video에 대한 zero-shot QA 성능은 부족하다. GPT-4V, Gemini 등 거대 multimodal 모델이 대안이 될 수 있으나, closed-source이며 막대한 computational cost가 발생한다.
• 본 연구의 비교 대상: 현재 zero-shot video QA의 SOTA는 FrozenBiLM이나 SeViLa와 같은 methods이며, 이 논문은 이들과의 직접적인 성능 비교를 통해 ProViQ의 우수성을 입증하고자 한다.

Modular Vision의 발전과 본 연구의 계승 지점

• 초기 Modular 접근법: NMNs (Neural Modular Networks)이 parser를 통해 module을 조합하는 아이디어를 제시했으나, joint training이 복잡하고 유연성이 떨어졌다.
• LLM 기반의 Paradigm Shift: 최근 ViperGPT, VISPROG 등이 LLM을 code generator로 사용하여 visual modules를 호출하는 Python program을 생성하는 방식으로 modular VQA를 재정의했다. 이는 기존 방식보다 훨씬 유연하고 강력하다.
• ProViQ의 핵심 포지션: 본 연구는 ViperGPT와 같은 code generation 접근법을 직접적으로 계승하고 발전시킨다. ViperGPT가 image에서는 성공적이었으나 video의 시간적 reasoning에는 한계가 있었던 반면, ProViQ는 이 program generation framework를 video 영역으로 성공적으로 확장했다는 점에서 핵심적인 contribution을 가진다.

Tool Use 관점에서의 ProViQ

• Prompting 기반 Tool Use: ProViQ는 LLM을 fine-tuning하는 대신, prompting을 통해 외부 tool을 효과적으로 사용하는 최신 연구 흐름에 속한다. large-scale video data에 대한 training의 어려움을 우회하는 실용적인 접근법이다.
• 활용하는 Pre-trained Models (Tools): ProViQ의 visual module API는 다음과 같은 SOTA pre-trained models의 조합으로 구성된다.
  • Object Detection: GroundingDINO
  • Image QA/Captioning: BLIP-2
  • Multi-Object Tracking: ByteTrack
  • Video-to-Language Generation: LaViLa
  • Code Generation Engine: GPT-3.5

---

 

3 Method

3.1 Program Generation

ProViQ의 input은 input video와 query입니다. 그 다음 우리는 application programming interface (API) 형태의 video modules 목록, input query 또는 task, 그리고 몇 가지 example programs를 포함하는 prompt를 구성하고, 이를 LLM에 입력합니다. 본 논문의 모든 experiments에는 gpt-3.5-turbo를 사용했지만, Appendix C에 open-source alternatives를 사용한 평가를 포함했습니다. LLM은 input query를 구체적인 단계로 decomposes하는 짧은 Python program을 생성하며, 각 단계는 API에 명시된 visual modules를 호출합니다. 생성된 program은 question, video frames, 그리고 multiple choice options 목록과 같은 기타 관련 정보를 input으로 받습니다. output이 generated되면, 우리는 Python의 내장 exec() 함수를 사용하여 프로그램을 compile하고 execute합니다. compiled된 함수는 input video에서 실행되어 task에 명시된 대로 final answer 또는 수정된 video를 output합니다.

3.2 Video Modules

제공된 API의 video modules 목록은 생성된 program이 질문을 decomposing하고 answering하는 데 사용하는 toolbox 역할을 하도록 의도되었습니다. 우리는 다양한 datasets와 가능한 questions을 포괄하기 위해 이러한 특정 methods를 사용했으며, LLM이 적절하다고 판단할 때 methods를 즉흥적으로 만들고 결합할 수 있는 여지를 두었습니다. 이 API가 반드시 모든 것을 포함하는 것은 아니지만, QA benchmarks에 있는 대다수의 질문에 답하기에 충분하다는 것을 발견했습니다. 우리는 이 modules 목록을 methods와 documentation의 형태로 prompt에 담아 LLM에 제공하며, 이는 Appendix E에 포함되어 있습니다. 모든 modules는 collections of frames에서 실행되도록 의도되었지만, single images에서도 작동하므로 singular frames뿐만 아니라 clips에 대한 reasoning도 가능합니다. 구체적인 modules는 다음과 같습니다.

filter_property "Is the person running?"과 같은 boolean predicate가 주어지면, 이 method는 video에서 해당 predicate를 만족하는 모든 frames를 찾습니다. 이는 input batch of frames에 대해 BLIP-2를 질문과 함께 호출하고, 답변이 'yes'인 모든 frames를 수집하는 방식으로 작동합니다.

filter_object yogurt와 같은 특정 object가 주어지면, 이 method는 video에서 해당 object가 존재하는 모든 frames를 찾습니다. 이 method는 input clip에 대해 object detector를 실행하고 주어진 object가 발견된 모든 frames를 반환합니다. filter_property도 이 기능을 처리할 수 있지만, 특정 objects를 찾는 데는 object detector를 사용하는 것이 훨씬 더 잘 작동합니다.

find 이 method는 text-conditioned object detector를 호출하여 collection of frames에서 발견된 input object의 각 crop을 반환합니다. 이 method는 시간에 따라 input object를 확대하는 데 유용하며, 이는 해당 object에 대한 visual queries의 성능을 향상시킬 수 있습니다.

track_objects continuous frames에 대한 detections 집합이 주어지면, ByteTrack을 사용하여 이를 함께 연결하고 scene의 각 tracked object를 반환합니다.

video_query 이 method는 BLIP-2의 QA capability를 호출하여 "what is the person doing?"과 같은 collections of frames에 대한 질문에 답합니다. video의 각 frame에 대한 input question의 답을 계산하고 이를 collates합니다. 그런 다음 frame-wise voting을 사용하여 가장 두드러진 답변을 선택합니다. 단일 frame의 오류 가능성을 줄이기 위해 단일 frame의 값을 선택하는 대신 voting을 사용했습니다.

get_summary collection of frames가 주어지면, 이 method는 video의 불연속적인 부분에 video captioning model을 사용하고, video에서 일어난 사건에 대한 포괄적인 paragraph summary를 생성합니다. 이 기능에 대해서는 Section 3.3에서 더 자세히 설명합니다. 이 module은 video의 high-level narrative structure에 대한 질문에 답하는 데 유용하며, 특히 Ego4D의 clips와 같이 긴 clips에 유용합니다.

get_script Whisper를 사용하여 input video의 audio로부터 transcript를 계산하거나, transcript가 이미 존재하는 경우 이를 반환합니다. 이 method는 등장인물의 dialogue를 얻는 것이 질문 해결에 필수적인 TVQA와 같은 benchmarks에 특히 유용합니다.

get_caption input image 또는 set of frames에 대한 captions를 계산합니다. 이는 전체 scene의 visual context를 제공하는 데 유용하며, TVQA나 NeXT-QA와 같은 datasets에서 multiple choice answers를 선택하는 데 도움이 될 수 있습니다.

best_text_match video segment와 set of choices가 주어지면, video segment의 내용과 가장 잘 맞는 option을 반환합니다. 이는 각 개별 choice가 참인지 거짓인지 video segment에 querying하고, 가장 높은 score를 가진 option을 반환하는 방식으로 이루어집니다. option의 score는 segment에 대한 video querying module의 confidence를 평균하여 계산합니다. 이 module은 process-of-elimination reasoning을 시뮬레이션하는 데 도움이 될 수 있으므로 multiple-choice questions에 특히 유용합니다.

choose_option input context, question, options가 주어지면, LLM을 사용하여 가장 관련성 높은 답변을 선택함으로써 multiple choice question에 답합니다. input context는 caption이나 다른 modules의 visual outputs과 같은 visual 정보일 수도 있고, narrative summary나 transcript와 같은 textual 정보일 수도 있습니다. 이 method는 multiple choice benchmarks를 해결하고 get_script나 get_summary로부터의 input context에 대해 reasoning하는 데 결정적입니다.

3.3 Long Video Summarization

우리의 modular approach의 한 가지 장점은 특정 tasks에 더 잘 적응된 다른 modules를 정의할 수 있다는 것입니다. 우리는 이를 long-video question answering을 해결하는 데 사용합니다. 이는 가장 큰 models를 제외하고는 모두에게 어려운 task로 남아있습니다. "Which option best describes the overarching narrative of the video?"와 같이 higher-level semantics를 이해해야 하는 질문을 생각해 보십시오. human이라면 video의 mental narrative를 구성한 다음, 주어진 options 목록과 일치시킬 것입니다. 우리는 pretrained video-to-text models를 활용하여 video의 high-level story를 이해하는 get_summary() module을 구현하며, 이는 Figure 4에서 설명합니다. 이는 모든 길이의 videos에서 작동하여, Google의 최근 Gemini 1.5 Ultra를 제외한 기존의 어떤 model보다 훨씬 긴 5분짜리 videos를 summarize할 수 있습니다. 긴 video V와 contiguous segment of frames를 받아 caption을 outputs하는 pre-trained model M(예: LaViLa)이 주어지면, 우리는 V를 1초 크기의 동일한 chunks로 partition합니다. 각 chunk에 대해 M을 실행하여 caption과 chunk의 timestamp를 output하고, 결과적으로 timestep이 annotated된 captions 목록을 얻습니다. 그런 다음 이 caption stream을 LLM으로 paragraph summary로 aggregate하여 video의 "narrative"로 사용하며, 각 sentence는 5초 간격을 설명합니다. 중요하게도, 이 module은 high-quality video captioning model에 의존합니다. 이 approach는 EgoSchema dataset에서 강력한 결과를 보여주는데, 이는 underlying Ego4D dataset에 annotated narrations의 밀도가 높아 LaViLa와 같은 high-quality models가 trained될 수 있었기 때문입니다. 다른 datasets의 경우, 비교할 만한 품질의 video captioning models가 부족하여 이 approach는 덜 효과적입니다.

3.4 Prompting and In-Context Examples

오랜 연구들은 input prompt의 표현 방식과 사용된 examples 집합이 downstream tasks에 대한 LLM performance에 큰 영향을 미친다는 것을 보여주었습니다. ViperGPT는 API에 고정된 example programs 집합과 8개의 in-context examples를 포함하지만, 우리는 VISPROG와 CodeVQA를 따라 각 benchmark dataset에 대해 최대 5개의 example programs를 annotate합니다. inference time에는 input query와 embedding space에서 가장 가까운 queries에 해당하는 3개의 examples를 sample합니다. 모든 queries를 embed하기 위해 OpenAI의 text-embedding-3-small을 사용합니다. 이러한 in-context examples를 사용하면 훨씬 더 높은 품질의 generated programs가 생성됩니다. choose_option이나 get_summary와 같이 language models를 사용하는 개별 modules의 경우, prompts를 고정하고 정적인 example inputs 집합을 사용합니다. 모든 example queries와 answers는 downstream evaluation에서의 오염을 피하기 위해 benchmark datasets의 training splits에서 sampled됩니다. prompt components에 대한 자세한 ablations는 Section 4.3에서 제공하며, in-context examples와 prompt에 대한 더 자세한 내용은 Appendix D에 있습니다.

3.5 Open-Ended and Multiple-Choice Benchmarks

program의 output answer는 benchmarks와의 정확성을 평가하기 위해 고정된 vocabulary로 constrained될 필요가 있습니다. multiple-choice QA datasets에서는 'choose_option()' module에서 LLM에게 output을 input answers의 범위로 constrain하도록 prompting함으로써 이를 달성할 수 있습니다. 반면에, open-ended benchmarks는 일반적으로 K가 수천에 이르는 K-way classification problems로 공식화됩니다. 이를 해결하기 위해, 우리는 generated program에 의해 생성된 string에 semantically 가장 가까운 vocabulary answer를 선택합니다. 구체적으로, 우리는 video_query의 output string을 pretrained phrase embedding model로 embed하고, output vocabulary에서 embedding space상 가장 가까운 match를 찾습니다. 이 step에는 FastText를 사용했으며, generated program에 필요한 calls를 줄이기 위해 이 logic을 program execution에서 abstracted away했습니다. 또한, 여러 open-ended benchmarks는 질문을 "locations"나 "objects"와 같은 분리된 categories로 classify합니다. question type은 test time에 사용할 수 있으므로, 우리는 이 splits를 사용하여 각 category의 vocabulary를 constrain하기도 합니다. 이러한 components에 대한 ablate는 Appendix C에서 다룹니다.

 

 

ProViQ 동작 Pipeline

1. Prompt 구성: Input(video, query)이 주어지면, (1) Visual Module API 명세, (2) Query, (3) Embedding 기반으로 retrieval된 In-Context Examples를 조합하여 LLM (gpt-3.5-turbo)을 위한 prompt를 생성한다.
2. Program 생성: LLM은 이 prompt를 기반으로 query를 해결하기 위한 Python program을 동적으로 generates한다.
3. 실행 및 결과 도출: 생성된 program을 Python의 exec() 함수로 compile 및 실행하여 final answer를 도출한다.

핵심 Video Module API 상세

이 논문의 핵심적인 기술적 기여는 video의 시공간적, 다중 모드(multi-modal) reasoning을 가능하게 하는 module 설계에 있다.

• 필터링 및 탐지 (Filtering & Detection):
  • filter_property: BLIP-2를 활용해 "사람이 뛰고 있는가?"와 같은 boolean predicate를 만족하는 frame들을 필터링한다.
  • filter_object / find: GroundingDINO와 같은 object detector를 이용해 특정 object의 존재 여부를 확인하거나 해당 object의 crop을 반환한다.
  • track_objects: ByteTrack을 사용하여 continuous frames에 걸쳐 object의 identity를 유지하며 추적한다. (Temporal reasoning의 핵심)
• 정보 질의 및 요약 (Querying & Summarization):
  • video_query: BLIP-2의 QA 능력을 활용해 clip에 대한 질문에 답하며, frame-wise voting으로 robustness를 확보한다.
  • get_summary / get_script: LaViLa나 Whisper 같은 모델을 이용해 video의 high-level narrative를 요약하거나 audio를 transcript로 변환한다. (Long video 및 multimodal reasoning의 핵심)
• 선다형 문제 해결 로직 (MCQA Logic):
  • best_text_match: Video segment의 내용과 가장 잘 맞는 선택지를 찾는다. (Process-of-elimination 유사)
  • choose_option: 다른 module들로부터 얻은 visual/textual context를 종합하여 LLM이 최종 선택지를 고르도록 한다.

주요 기술적 해결책

• Long Video 처리 (Hierarchical Summarization): get_summary module은 긴 video를 짧은 chunk로 나누고, 각 chunk별 caption을 생성한 뒤, 이를 다시 LLM을 통해 하나의 narrative summary로 aggregate한다. 이는 context window 제약을 우회하는 확장 가능한 접근법이다.
• Program 생성 품질 향상 (Dynamic In-Context Learning): 고정된 prompt가 아닌, inference time에 input query와 embedding 공간상 가장 유사한 example programs 3개를 동적으로 sampling하여 prompt에 포함시킨다. 이는 code generation의 정확성을 크게 향상시킨다.
• Benchmark 평가 정합성 (Output Mapping):
  • Open-Ended: Program이 생성한 free-form string 답변을 FastText로 embed하여, benchmark의 vocabulary 내에서 semantically 가장 가까운 답변을 matching한다.
  • Multiple-Choice: choose_option module이 LLM의 output을 주어진 선택지 내로 constrain하도록 prompting한다.

---

쉬운 설명:

ProViQ가 어떻게 일하는지 아주 유능한 '프로젝트 매니저'(LLM)에 비유해 보겠습니다.

1. 프로젝트 계획 수립 (Program Generation): 매니저는 "주황색 바지 입은 스키어의 재킷 색은?"과 같은 복잡한 업무(query)를 받으면, 직접 일을 처리하는 대신 이 업무를 해결하기 위한 아주 상세한 단계별 계획서(Python program)를 작성합니다.
2. 전문가 팀 꾸리기 (Video Modules): 매니저에게는 각 분야의 전문가들(modules)로 구성된 팀이 있습니다. 매니저는 계획서에 각 전문가에게 할 일을 할당합니다.
   • 탐색 전문가 (filter_object): "주황색 바지 입은 스키어"처럼 특정 대상을 기가 막히게 찾아냅니다.
   • 추적 전문가 (track_objects): 한 번 찾은 대상을 놓치지 않고 영상 내내 따라갑니다.
   • 현장 탐정 (video_query): 특정 장면에 대해 "이 재킷 무슨 색이야?" 같은 구체적인 질문에 답을 찾아냅니다.
   • 기록 담당관 (get_summary, get_script): 긴 영상의 전체 스토리를 요약 보고서로 만들거나, 영상 속 대화를 모두 받아 적습니다.
   • 최종 결정권자 (choose_option): 모든 전문가의 보고서를 취합해서, "1. 파란색 2. 빨간색" 같은 선택지 중 최종 정답을 고릅니다.
3. 까다로운 장기 프로젝트 처리법 (Long Video Summarization): 만약 5분짜리 긴 영상 같은 큰 프로젝트가 주어지면, 매니저는 똑똑하게 일을 처리합니다. 먼저 기록 담당관에게 영상을 5초 단위로 잘라서 한 문장짜리 요약 보고서를 여러 개 만들게 합니다. 그런 다음, 매니저가 이 짧은 보고서들을 모두 읽고 하나의 완벽한 최종 요약 보고서를 완성합니다.
4. 완벽한 계획서를 위한 비결 (Prompting): 매니저는 계획서를 쓰기 전에, 과거에 성공했던 비슷한 프로젝트들의 계획서를 3개 정도 참고합니다. 심지어 가장 도움이 될 만한 과거 계획서를 똑똑한 검색 기능(embedding)으로 찾아오기까지 합니다.
5. 결과 보고 방식 (Output Mapping): 프로젝트가 끝나고 팀이 "푸른빛이 감도는 재킷"이라고 보고해도, 공식 보고서 양식(benchmark)에 "파란색"이라고 한 단어로 적어야 한다면, 매니저는 비서(FastText)를 시켜 가장 비슷한 표준 단어를 찾아 깔끔하게 보고서를 마무리합니다.

 

 

주인장 이해

1. 질문이 들어오면 '질문-정답 코드' 쌍 데이터 베이스에서 가장 가까운 예제 3개를 찾아냄.

2. LLM에게 예제와 함께 , module 목록이랑, 질문을 주고 계획을 세우라고함.

3. 걍 실행하면됨.

4. 그걸 가지고 최종 답변이 나오면 정제를 하든 뭘하든 암튼 끝