대규모 VLM 영상 추출 시스템의 프롬프트 최적화·구조적 한계
VLM(Vision Language Model)은 시각 정보와 언어 정보를 함께 처리하는 멀티모달 모델입니다.
이 글에서는 VLM에 영상 프레임을 입력해 장면을 자연어로 서술하는 방식으로 사용했습니다.
단순히 객체를 인식하는 것을 넘어, 누가 무엇을 하고 있는지를 문장으로 표현할 수 있어
영상 검색, 장면 분류, 자동 자막 생성 등에 활용됩니다.
초기에는 Custom Prompt만 잘 작성하면 원하는 장면을 추출할 수 있을 것이라 생각했으나,
실제로 진행해 보니 VLM 서술 방식, 고정 프롬프트, 후속 파이프라인의 동작 방식까지
예상보다 깊이 있게 고려해야 할 영역이 많았습니다.
이 글에서는 대규모 영상 AI 프로젝트에서 VLM Custom Prompt 최적화 과정을 정리합니다.
프롬프트 전략 비교, 테스트 자동화, 정량 평가, 인터페이스 설계 변경까지의 과정을 다룹니다.
본 포스팅의 프롬프트, 데이터, 수치는
실제 프로젝트 내용을 기반으로 일부 각색되었습니다.
1. 영상 추출에서의 VLM 활용
VLM의 아키텍처와 기본 개념은 폐쇄망 AI Solution 서비스 구성 및 배포에서 다뤘습니다.
이 글에서는 VLM을 영상 장면 추출에 적용할 때의 특성에 집중합니다.
이번 프로젝트에서 VLM은 프레임 묶음(10~20장)을 입력받아
해당 구간에서 무엇이 일어나고 있는지를 자연어로 서술합니다.
| 관점 | 영상 서술 기반 추출 |
|---|---|
| 입력 | 프레임 시퀀스(10~20장) |
| 태스크 | 장면을 요약해 텍스트로 표현 |
| 출력 | 검색/필터링용 설명 문장 |
| 프롬프트 역할 | 무엇을 중점적으로 볼지 지정 |
| 평가 | 정답 구간과 비교(IoU, F1 등) |
영상 서술에서는 프롬프트가 관찰 초점을 결정하므로, 프롬프트 설계가 추출 품질을 좌우합니다.
2. 프롬프트 엔지니어링 (Prompt Engineering)
프롬프트 엔지니어링은 AI 모델에 입력하는 지시문(프롬프트)을 설계·최적화하여
원하는 출력을 유도하는 기법입니다.
1. LLM 프롬프트 엔지니어링과의 차이
텍스트 전용 LLM에서의 프롬프트 엔지니어링은 주로 다음에 집중합니다:
- 역할 지정 (“너는 번역가다”)
- 출력 형식 지정 (“JSON으로 응답해”)
- Few-shot 예시 제공
- Chain-of-Thought 유도
VLM에서의 프롬프트 엔지니어링은
여기에 시각 정보의 해석 방향이 추가됩니다:
| 관점 | LLM 프롬프트 | VLM 프롬프트 |
|---|---|---|
| 입력 | 텍스트만 | 텍스트 + 이미지/프레임 |
| 프롬프트 역할 | “무엇을 생성할 것인가” | “이미지에서 무엇을 볼 것인가” |
| 모호성 원인 | 언어적 다의성 | 시각적 주관성 (구도, 분위기, 맥락) |
| 오류 유형 | 사실 오류, 형식 불일치 | 할루시네이션, 과잉 서술 |
| 제어 난이도 | 비교적 예측 가능 | 동일 프롬프트도 프레임에 따라 결과 변동 |
2. 할루시네이션 (Hallucination)
할루시네이션은 AI 모델이 입력에 존재하지 않는 내용을 사실인 것처럼 생성하는 현상입니다.
LLM에서는 학습 데이터에 없는 사실을 지어내는 형태로 나타나고,
VLM에서는 이미지에 없는 객체나 행동을 서술하는 형태로 나타납니다.
| 구분 | LLM 할루시네이션 | VLM 할루시네이션 |
|---|---|---|
| 형태 | 존재하지 않는 사실을 생성 | 이미지에 없는 객체/행동을 서술 |
| 예시 | “이 문서에는 보안 정책이 명시되어 있습니다.” (실제로는 없음) | 화면에 사람이 없는데 “사람이 걸어가고 있다” |
| 원인 | 학습 데이터의 패턴에 과적합 | 프롬프트의 유도 + 시각 정보 부족 |
VLM 프롬프트는 문장을 생성하라는 지시가 아니라 영상에서 무엇을 볼지 지정하는 지시이므로,
프롬프트의 표현 하나가 다수 구간의 서술 결과에 영향을 줄 수 있습니다.
3. System Prompt vs User Prompt
LLM/VLM에 입력되는 프롬프트는 일반적으로 두 영역으로 나뉩니다.
| 구분 | System Prompt | User Prompt |
|---|---|---|
| 역할 | 모델의 동작 방식, 역할, 제약 조건을 정의 | 실제 요청이나 질문을 전달 |
| 설정 주체 | 개발자/시스템 | 최종 사용자 |
| 변경 빈도 | 배포 시 고정, 사용자에게 비공개 | 매 요청마다 변경 가능 |
| 예시 | “너는 영상 분석 전문가다. 한국어로 1~2문장으로 서술해라.” | “건물이 나오는 장면을 찾아줘” |
System Prompt는 모델이 어떻게 동작할지 결정하고, User Prompt는 무엇을 할지 지시합니다.
ChatGPT 같은 서비스에서는 System Prompt가 사용자에게 보이지 않지만,
API를 직접 호출할 때는 messages의 role: "system"과 role: "user"로 구분하여 입력합니다.
messages = [
{"role": "system", "content": "너는 영상 분석 전문가다..."},
{"role": "user", "content": "이 영상에서 건물이 보이는 장면을 찾아줘"},
]
4. Custom Prompt의 위치
이번 프로젝트에서 Custom Prompt는 전체 프롬프트의 일부로,
시스템이 고정한 기본 프롬프트 위에 사용자가 추가하는 형태입니다.
앞서 설명한 User Prompt와는 다르며, 사용자가 UI에서 입력하는 가변 영역을 가리킵니다.
┌──────────────────────────────┐
│ 시스템 고정 프롬프트 (수정 불가) │
│ ┌────────────────────────┐ │
│ │ 기본 프롬프트 │ │
│ │ 작업 순서 프롬프트 │ │
│ │ 출력 형식 프롬프트 │ │
│ └────────────────────────┘ │
│ │
│ ┌────────────────────────┐ │
│ │ Custom Prompt (수정 가능) │ │ ← 유일한 가변 영역
│ └────────────────────────┘ │
└──────────────────────────────┘
각 Custom Prompt는 다음 두 필드로 구성됩니다.
| 필드 | 역할 | 예시 |
|---|---|---|
| 프롬프트 내용 | 추출 대상 장면을 기술 | “인물이 등장하는 장면” |
| 디스크립션 생성 가이드 (선택) | VLM이 서술할 때 중점적으로 포함할 내용을 지정 | “의상 위주로 서술” |
두 필드는 VLM 프롬프트에 하나의 줄로 결합됩니다.
인물이 등장하는 장면(의상 위주로 서술)
Custom Prompt는 사용자가 UI에서 직접 입력하는 영역이며,
이 프로젝트에서의 역할은 사용자가 원하는 장면을 효과적으로 추출할 수 있도록
작성 가이드를 설계하고 추출에 최적화된 인터페이스 구조를 제안하는 것이었습니다.
프롬프트 엔지니어링 대상이 Custom Prompt에 한정된다는 점이 핵심 제약이었습니다.
5. 영어 프롬프트 vs 한국어 프롬프트
프롬프트 엔지니어링이 확산되던 초기에는 논문·예제·벤치마크 대부분이 영어 기준이었기 때문에
영어 프롬프트가 사실상 기본값처럼 사용되었습니다.
- 레퍼런스가 영어 중심이라 시행착오가 상대적으로 적었고
- 당시에는 한국어 프롬프트에서 표현/출력 일관성이 떨어지는 경우도 종종 관찰되었습니다.
이번 프로젝트에서는 모든 Custom Prompt를 한국어로 작성했습니다.
모델 자체가 다국어 사전학습(multilingual pretraining)을 거친 최신 버전이었고,
임베딩 모델 또한 다국어 지원 모델을 사용했으며, 사용자가 한국어 기반 UI를 사용했기 때문에
쿼리-서술-후처리 전 과정을 동일 언어로 통일하는 것이 일관성 측면에서 유리했습니다.
영어 프롬프트는 별도로 비교 실험하지 않았으나,
동일 데이터셋에서 한국어 프롬프트의 출력 안정성과 후처리 일관성이 충분하다고 판단했습니다.
6. VLM은 언어를 타는가?
많은 VLM은 시각 정보가 언어 모델 출력으로 자연스럽게 이어지도록
시각-언어 정렬(alignment)을 거치며 학습됩니다.
이때 언어 모델이 어떤 언어 데이터로 얼마나 학습되었는지가 출력 안정성에 영향을 줍니다.
- 영어 중심 데이터로 학습된 모델 → 영어 프롬프트에 더 안정적인 편
- 다국어 학습 모델 → 한국어 포함 여러 언어에서 상대적으로 안정적
모델이 언어를 가린다기보다는,
학습 데이터의 분포와 토큰 통계에 영향을 받는다고 보는 것이 더 정확합니다.
실무에서 실제로 달라지는 부분은 다음과 같습니다.
| 항목 | 영어 | 한국어 |
|---|---|---|
| 토큰 분해 | 단어 단위 토큰화가 비교적 안정적 | 형태소 분해 + 조사 결합으로 토큰 길이 변동 |
| 동사 활용 | run / running / ran | 달리다 / 달리고 있다 / 달린다 / 달렸다 → 키워드 매칭에서 차이 발생 |
| 임베딩 일관성 | 다국어 임베딩 모델을 쓰면 언어 간 격차가 줄어드는 편 (모델/도메인 의존) | 동일 언어 내에서는 더 안정적 |
VLM, 임베딩 모델 모두 다국어 지원 모델을 사용했고,
검색 쿼리도 한국어였으므로 전 과정을 한국어로 통일했습니다.
3. RAG (Retrieval-Augmented Generation)
RAG는 LLM의 응답에 외부 검색 결과를 결합하는 구조입니다.
LLM은 학습 데이터에 포함되지 않은 정보 (사내 문서, 실시간 데이터, 도메인 지식 등)에 대해
정확한 응답을 생성하기 어려우나, RAG는 이 한계를 보완합니다.
1. 동작 원리
1. 사용자 질문 입력
2. 질문을 벡터로 변환 (임베딩)
3. 벡터 DB 또는 검색 엔진에서 관련 문서/데이터 검색
4. 검색 결과를 LLM의 컨텍스트에 삽입
5. LLM이 검색 결과를 참고하여 응답 생성
┌──────────┐ ┌──────────────┐ ┌──────────┐
│ 사용자 │────▶│ 검색 엔진 │────▶│ LLM │
│ 질문 │ │ (벡터 DB 등) │ │ │
└──────────┘ └──────────────┘ └──────────┘
│ 관련 문서 반환 │ 검색 결과 + 질문
└──────────────────────▶│ → 응답 생성
2. LLM 단독 vs RAG 적용
| 구분 | LLM 단독 | RAG 적용 |
|---|---|---|
| 지식 범위 | 학습 데이터까지 | 외부 DB의 최신 데이터까지 |
| 할루시네이션 | 모르는 내용을 생성할 위험 | 검색된 근거 기반으로 응답 |
| 업데이트 | 재학습 필요 | DB만 업데이트하면 됨 |
| 비용 | 모델 재학습 비용 | 검색 인프라 비용 |
| 대표 사례 | 검색 결합 없는 순수 LLM 서비스 | 사내 문서 QA, 기술 지원 챗봇 |
3. 영상 추출에서의 RAG
영상 추출 파이프라인에서는 RAG를 답변 생성이 아닌 검색 결과의 re-scoring 용도로 사용합니다.
일반적인 RAG: 질문 → 문서 검색 → LLM이 답변 생성
영상 추출의 RAG: 쿼리 → 임베딩 검색 → LLM이 각 결과에 관련도 점수(1~10) 산출
임베딩 유사도 검색(1차)만으로는 부정문, 동의어, 맥락 차이를 정확히 구분하지 못하므로,
LLM이 텍스트를 직접 읽고 2차 필터링하는 구조입니다.
| 구분 | 임베딩 검색 (1차) | RAG 재점수 (2차) |
|---|---|---|
| 방식 | 벡터 간 코사인 유사도 | LLM이 텍스트를 읽고 점수 산출 |
| 장점 | 빠름, 대량 처리 가능 | 부정문/동의어/맥락 이해 가능 |
| 한계 | 부정 표현도 유사도가 높게 산출될 수 있음 | 느림, LLM 비용 발생 |
4. 영상 추출 파이프라인
영상에서 원하는 장면을 찾는 것은 구조적으로 검색 문제에 가깝습니다.
다만, 영상은 텍스트처럼 직접 검색할 수 없으므로 다음과 같은 변환이 필요합니다:
영상 → VLM으로 텍스트 변환(인덱싱) → 텍스트 임베딩 저장 → 사용자 쿼리로 검색
이 구조에서 VLM의 서술은 검색 인덱스의 역할을 합니다.
검색 엔진에서 문서 품질이 검색 결과를 좌우하듯,
VLM 서술 품질이 장면 추출 품질에 크게 영향을 줍니다.
이번 프로젝트에서 사용한 평가 지표(Precision, Recall, F1)도
정보 검색(Information Retrieval) 분야에서 사용하는 것과 동일합니다.
검색 결과 중 정답 비율(Precision)과 전체 정답 중 찾은 비율(Recall)로 검색 품질을 측정합니다.
전체 시스템은 분석엔진과 추출 서버 두 단계로 구성됩니다.
1. 분석엔진 (VLM 추론)
영상 입력 → 프레임 샘플링 (N프레임마다 1장) → 배치 구성 (10~20프레임) → VLM 추론 → 구간별 서술 생성
VLM 인터페이스 내부에서 프롬프트는 고정 영역과 가변 영역으로 나뉩니다.
| 영역 | 수정 가능 여부 |
|---|---|
| 기본 프롬프트 | 고정 |
| 작업 순서 프롬프트 | 고정 |
| 출력 형식 프롬프트 | 고정 |
| Custom Prompt | 유일한 가변 영역 |
각 프롬프트의 내용은 다음과 같습니다.
기본 프롬프트:
당신은 영상 분석 전문가입니다.
주어진 영상 프레임에 나타난 객체와 인물의 행동에 초점을 맞춰
현재 상황을 서술하세요.
화면에 보이는 시각적 정보만 사용하며,
추측이나 영상에 없는 정보를 만들어내서는 안 됩니다.
작업 순서 프롬프트:
작업 순서:
1) 중점 상황이 실제로 보이는지 확인
2) 보이지 않으면 → 핵심 장면만 사실적으로 요약
3) 보이면 → 해당 장면을 우선으로 1~2문장으로 요약
Custom Prompt 안내 문구:
다음 상황들을 중점적으로 서술하여야 합니다.
해당 상황이 나타나지 않으면 절대 서술하지 않아야 하며,
항목 옆에 ()로 지시문이 있으면 따라 서술하여야 합니다.
출력 형식 프롬프트:
- 한국어로 1~2문장 작성
- 나오지 않는 상황은 절대 서술하지 않음
- 중점 상황이 없으면 화면에 나타난 장면을 직관적으로 서술
- 포함되어 있지 않다는 이야기를 절대 하지 않음
최종 프롬프트 조합 방식:
{기본 프롬프트}
+
{작업 순서 프롬프트}
+
{안내 문구}
+
1. {custom_prompt_1}
2. {custom_prompt_2}
+
{출력 형식 프롬프트}
2. 추출 서버 (클립 생성)
분석엔진의 VLM 서술 결과는 Kafka를 통해 추출 서버로 전달되고,
Elasticsearch에 임베딩 벡터와 함께 저장됩니다.
사용자 쿼리 → 쿼리 임베딩 → ES KNN 검색 → RAG 재점수 → 구간 병합 → 클립 추출
| 단계 | 동작 | 주요 파라미터 |
|---|---|---|
| 쿼리 임베딩 | 사용자 검색어를 벡터로 변환 | 다국어 임베딩 모델 |
| ES KNN 검색 | VLM 서술 임베딩과 유사도 비교 | 유사도 임계값, 후보 수 |
| RAG 재점수 | LLM이 각 결과를 1~10점으로 재평가 | 최소 점수 기준 |
| 구간 병합 | 인접 구간 합치기 | 병합 간격, 최소 구간 길이 |
RAG 재점수 시 적용되는 규칙은 다음과 같습니다:
- 동의어 허용
- 부정문 제외
- 과도한 추론 금지
- 일정 점수 이상만 최종 선택
5. 고정 프롬프트의 상충 문제
1. 고정 프롬프트가 항상 서술하도록 설계된 이유
분석엔진의 VLM은 모든 구간을 자연어로 서술해 검색 인덱스를 생성하는 역할로 설계되었습니다.
서술이 없는 구간은 검색 대상이 될 수 없으므로,
“항상 무언가를 서술하라”는 지시는 검색 커버리지 관점에서 합리적입니다.
Custom Prompt가 추가되어도 VLM은 여전히 모든 구간을 서술합니다.
다만 특정 장면이 있으면 그것을 우선 서술하도록 방향을 유도하는 것이 원래 의도였습니다.
문제는 이 구조를 특정 장면 추출 용도로 사용할 때 발생합니다.
분석엔진의 프롬프트는 추출 파이프라인을 고려하여 설계된 것이 아니므로,
범용 서술용 프롬프트와 Custom Prompt 사이에 상충이 생깁니다.
Custom Prompt 기능이 추가될 때 안내 문구만 삽입되었고,
기존 작업 순서 프롬프트는 수정되지 않았습니다.
그 결과 실제 동작에서는 긍정 지시(서술)가 우선되면서,
‘서술하지 말라’는 부정 지시가 기대만큼 반영되지 않았습니다.
2. 상충 지시에 대한 VLM의 동작
LLM/VLM은 프롬프트 내에서 모순되는 지시를 받으면 한쪽을 우선하여 동작합니다.
| 관찰된 패턴 | 설명 | 적용 |
|---|---|---|
| Recency Bias (최신 우선) | 프롬프트 뒤쪽에 위치한 지시가 우선됨 | 관찰상 recency 효과는 제한적이었고, 구체성/긍정 지시가 더 강하게 작동 |
| 구체성 우선 | 구체적인 지시가 추상적인 지시보다 우선됨 | “화면에 보이는 핵심 장면을 요약”(구체적 행동 지시)이 “서술하지 않아야 하며”(추상적 금지)보다 우선 |
| 긍정 지시 우선 | “~해라”가 “~하지 마라”보다 실행되기 쉬움 | “장면을 서술해라”가 “서술하지 마라”보다 우선 → 결과적으로 “어쨌든 서술” |
이 세 가지 패턴이 결합되어 부정 지시가 기대만큼 우선되지 않았고,
대상 장면이 없어도 서술이 생성되는 경우가 잦았습니다.
이 동작의 결과로 발생하는 문제:
| 상황 | VLM 출력 | 문제점 |
|---|---|---|
| 대상 장면 있음 | “빨간 조끼를 입은 사람이 달리고 있다.” | 정상 |
| 대상 장면 없음 | “빨간 조끼를 입은 사람이 달리는 장면은 나타나지 않았습니다. 두 남성이 대화를…” | 부정문에 “조끼”, “달리” 키워드 포함 → 오탐 |
이 부정문 서술은 후속 파이프라인에서 두 가지 경로로 오탐을 유발합니다:
- 키워드 매칭: “조끼”, “달리” 등 목표 키워드가 부정문에 포함되어 양성 판정
- 임베딩 유사도: 부정문이라도 목표 키워드를 포함하므로
임베딩 벡터 간 유사도가 임계값 이상으로 산출될 수 있음
6. 서술형 vs 감지형 인터페이스
VLM이 영상을 분석할 때 결과를 출력하는 방식은 크게 두 가지로 나눌 수 있습니다.
| 구분 | 서술형 (v1) | 감지형 (v2) |
|---|---|---|
| 역할 | 모든 구간에서 장면을 서술 | 특정 장면이 있을 때만 서술 |
| 출력 (대상 있음) | “빨간 조끼를 입은 사람이 달리고 있다.” | “빨간 조끼를 입은 사람이 달리고 있다.” |
| 출력 (대상 없음) | “해당 장면은 나타나지 않았습니다. 두 남성이 테이블에 앉아…” | “N/A” |
| 후처리 | 키워드 매칭 필요 | N/A 여부만 확인 |
| 오탐 위험 | 부정문에 키워드 포함 → 오탐 발생 | 대상 없으면 출력 없음 → 오탐 감소 |
서술형은 항상 무언가를 출력하므로,
후속 파이프라인에서 부정문 서술도 유사도 점수를 받을 수 있습니다.
7. 프롬프트 전략 3종 비교
Custom Prompt 최적화를 위해 3가지 전략을 설계하고 동일 조건에서 비교했습니다.
| 전략 | 프롬프트 구조 | 감지 방식 | 특징 |
|---|---|---|---|
| v1 (서술형 + 키워드 OR) | 기존 고정 프롬프트 그대로 | 키워드 1개 이상 매칭 | 기존 시스템 동작 방식 |
| v2 (감지형 N/A) | 감지형 전용 프롬프트 | N/A가 아니면 감지 | 인터페이스 구조 변경 |
| v3 (서술형 + 지시문 + AND) | v1 프롬프트 + () 지시문 | AND 키워드 그룹 매칭 | v1 유지하면서 후처리 강화 |
1. v1: 서술형 + 키워드 OR
기존 인터페이스를 그대로 사용합니다.
VLM 출력에서 목표 키워드가 하나라도 포함되면 감지로 판정합니다.
2. v2: 감지형 N/A
프롬프트 구조를 재설계하여 감지 대상의 모든 조건이 동시에 충족되는 경우에만 장면을 서술하고,
하나라도 충족되지 않으면 "N/A"만 출력하도록 합니다.
후처리는 N/A 여부만 확인하면 됩니다.
3. v3: 서술형 + () 지시문 + AND 키워드
v1의 프롬프트 구조를 유지하면서,
() 지시문으로 VLM 출력에 복장/색상/동작 정보를 강제 포함시킵니다.
후처리에서 AND 키워드 그룹 매칭과 제외 키워드를 적용합니다.
AND 키워드 매칭 예시:
| 그룹 | 키워드 | 의미 |
|---|---|---|
| 그룹1 (색상) | “빨간” | 복장 색상 |
| 그룹2 (복장) | “조끼”, “유니폼” | 복장 종류 |
| 그룹3 (동작) | “달리” | 행동 |
| 제외 | “자세”, “준비”, “하려는” | 실제 동작이 아닌 표현 |
모든 그룹에서 최소 1개씩 매칭되어야 감지 판정합니다.
8. 테스트 자동화 환경
1. 테스트 파이프라인
각 전략의 정량 비교를 위해 다음 파이프라인을 자동화했습니다.
1. 프레임 추출 (ffmpeg, N프레임 간격)
2. VLM 추론 (vLLM API, 배치 병렬 처리)
3. 후처리 (키워드 매칭 / N/A 판정)
4. 구간 병합 (인접 감지 구간 합치기)
5. 정답 비교 (IoU 기반 Precision/Recall/F1)
6. 리포트 생성 (JSON + CSV + 클립 추출)
2. 테스트 조합
복수의 추출 유형 × 3가지 프롬프트 전략 × 복수 영상의 조합을 테스트했습니다.
추출 유형은 행동추출(특정 복장/동작 인물 탐지)과 배경 추출(건물, 자연 등)로 구분했습니다.
3. 평가 지표
정답 비교에는 IoU(Intersection over Union) 기반의 매칭을 사용했습니다.
IoU = (예측 구간 ∩ 정답 구간) / (예측 구간 ∪ 정답 구간)
예를 들어 IoU 임계값을 0.3으로 설정한 경우,
이 이상인 구간을 매칭으로 판정하고 Precision, Recall, F1을 산출합니다.
| 지표 | 수식 | 의미 |
|---|---|---|
| Precision | TP / (TP + FP) | 감지한 것 중 정답 비율 |
| Recall | TP / (TP + FN) | 정답 중 감지한 비율 |
| F1 | 2 × P × R / (P + R) | Precision과 Recall의 조화 평균 |
정답 클립의 타임스탬프가 없는 경우, 퍼셉추얼 해싱(aHash/dHash)으로 자동 매칭을 시도했으나,
정확도가 충분하지 않아 원본 영상을 직접 재생하며 수작업으로 타임스탬프를 매칭했습니다.
9. 실험 결과
3가지 전략을 동일 조건에서 비교했습니다.
1. 행동추출
특정 복장/동작을 가진 인물을 탐지하는 유형입니다.
| 전략 | 결과 |
|---|---|
| v1 (서술형) | 대량의 오탐 발생 |
| v2 (감지형) | 오탐 대폭 감소, 대부분의 정답 탐지 |
| v3 (AND 매칭) | 오탐 일부 감소, 부정문 키워드는 여전히 통과 |
v1에서 프롬프트를 상세하게 작성할수록 VLM이 부정문에도 목표 키워드를 더 많이 포함시켜
오히려 역효과가 발생했습니다.
2. 배경 추출
건물, 자연 등 소재 장면을 탐지하는 유형으로 v1, v2 모두 유의미한 결과를 내지 못했습니다.
정답 기준이 영상미, 구도, 장면전환 등 주관적 요소에 의존하기 때문입니다.
3. 인코딩 영향
해상도가 동일하더라도 비트레이트가 낮아지면 압축 아티팩트가 증가하고
복장 색상, 로고 등 세부 시각 요소가 손실되어 동일한 프롬프트에서도 서술 결과가 달라졌습니다.
4. 부정문의 자연 필터링
테스트에서는 VLM 출력을 직접 키워드 매칭하여 부정문이 대량의 오탐을 유발했습니다.
그러나 추출 서버에 배포된 임베딩 모델로 동일한 결과를 재검증하면,
부정문 서술 중 상당수는 유사도 임계값 미만으로 자동 탈락합니다.
즉, 임베딩 유사도 임계값 단계에서 일부 오탐이 추가로 제외됩니다.
다만 모든 부정문이 걸러지는 것은 아니며,
이 임계값은 코드에 하드코딩되어 있어 프롬프트 작성자가 조절할 수 없습니다.
10. 실험 중 발견한 이슈
실험 과정에서 프롬프트 최적화만으로는 해결할 수 없는 시스템 이슈들을 발견했습니다.
| 이슈 | 원인 | 영향 | 대응 |
|---|---|---|---|
| 고정 프롬프트의 지시 모순 | 작업 순서 프롬프트가 추출이 아닌 서술 목적으로 설계됨 | Custom Prompt를 아무리 정교하게 작성해도 부정문 서술 생성을 막을 수 없음 | v2 감지형 인터페이스로 작업 순서 프롬프트 자체를 교체 |
| 상세 프롬프트의 역효과 | 프롬프트에 정보를 많이 포함할수록 VLM이 부정문에도 해당 키워드를 서술 | 오탐이 오히려 증가 | 서술형에서는 프롬프트 상세도를 높이지 않음 |
| 추출 서버의 하드코딩된 임계값 | 임베딩 유사도 임계값, RAG 최소 점수 등이 코드 내 상수로 고정 | 프롬프트 작성자가 제어할 수 없는 영역 | 파라미터 외부화 제안 |
| 인코딩 방식에 따른 결과 차이 | 비트레이트 변화로 프레임 품질이 저하 | 동일 프롬프트에서도 감지 결과가 달라짐 | 입력 영상 품질 기준 사전 정의 |
11. 리서치 단계에서 검토한 접근법
프로젝트 초기에 다음 접근법들을 리서치하고 일부를 실제 구현하여 테스트했습니다.
| 접근법 | 내용 | 구현 여부 | 프로덕션 적용 |
|---|---|---|---|
| Dense Caption → Query Prompt | 정답 클립에서 캡션 추출 후 검색용 프롬프트 자동 생성 | 구현 완료 | 불가 (UI가 자연어 1줄 입력) |
| 구조화 조건 (JSON 스키마) | 필수/선호/제외 조건을 구조화하여 입력 | 구현 완료 | 불가 (JSON 입력 미지원) |
| Keyframe 요약 + 변화점 | 시작/종료 트리거 조건 명시 | 일부 구현 | 불가 (5초 단위 프레임으로 시간 흐름 인식 제한) |
| 다중 후보 프롬프트 앙상블 | 관점별 쿼리 통합 검색 | 구현 완료 | 불가 (프롬프트 입력 수 제한, 앙상블 로직 없음) |
| Hard Negative Mining | 오답 구간과의 차이로 배제 조건 강화 | 분석 완료 | 불가 (배제 조건 전달 인터페이스 없음) |
| 타깃 클립 매칭 | 타깃 클립 스키마 → 슬라이딩 윈도우 점수화 | 구현 완료 | 불가 (프로덕션 파이프라인 구조 상이) |
이 중 Dense Caption, 구조화 조건, 앙상블 등은 구현까지 완료했으나,
인터페이스가 자연어 Custom Prompt만 받는 구조라 적용할 수 없었습니다.
1. 프롬프트 작성자의 제어 가능 범위
Custom Prompt 작성자가 실제로 제어할 수 있는 영역과
없는 영역을 정리하면 다음과 같습니다.
| 파이프라인 단계 | 제어 주체 | 프롬프트 작성자의 영향 |
|---|---|---|
| VLM 추론 | 고정 프롬프트 + Custom Prompt | Custom Prompt만 제어 가능 |
| 임베딩 유사도 | 임베딩 모델 + 임계값 | 제어 불가 |
| RAG 재점수 | RAG 시스템 프롬프트 + 최소 점수 | 제어 불가 |
| 구간 병합 | 병합 파라미터 | 제어 불가 |
| 클립 추출 | 영상 처리 로직 | 제어 불가 |
12. 프롬프트 엔지니어링 인사이트
실험 과정에서 확인한 프롬프트 작성 시 고려사항입니다.
| 원칙 | 비효과적 예시 | 효과적 예시 | 이유 |
|---|---|---|---|
| 부정 조건 활용 | 건물이 보이면 예 | 건물이 보이고, 인물 클로즈업이 아니고, 실내가 아니면 예 | 긍정 조건만으로는 False Positive 많음 |
| 구체적 시각 요소 | 고풍스러운 분위기 | 기와지붕, 돌담, 목조 구조물이 보임 | 분위기는 모호, 시각 요소는 명확 |
| 카메라 구도 명시 | 배경이 잘 보임 | 와이드샷 또는 버드아이뷰로 건물 전체가 보임 | 구도를 특정해야 VLM이 판별 가능 |
| 인물 허용 기준 | 인물이 없어야 함 | 인물이 있어도 화면의 1/3 이하를 차지하고, 풍경의 일부로 보임 | 절대 기준은 False Negative 유발 (군중 씬 제외) |
| 출력 형식 고정 | 자유 서술 | 배경탐지: 예/아니오, 설명: (판정 근거 한 문장) | 형식이 고정되어야 후처리 자동화 가능 |
마무리
이 글에서는 VLM 영상 추출 시스템의 프롬프트 최적화와 구조적 한계를 정리했습니다.
- 서술형(v1), 감지형(v2), AND 후처리(v3) 전략을 동일 조건에서 비교
- 자동화 파이프라인을 구축해 IoU, Precision, Recall, F1 기반 정량 평가 수행
- 감지형 인터페이스가 행동추출에서 가장 안정적인 결과를 보임
- 프롬프트 수정만으로는 고정 프롬프트의 모순과 파이프라인 제약을 해소할 수 없음을 확인
- 임베딩·재점수·구간 병합 단계가 실제 성능에 큰 영향을 미침을 검증
핵심 제약은 고정 프롬프트를 변경할 수 없다는 점이었습니다.
범용 서술 목적의 프롬프트 위에 특정 장면 추출 요구가 추가되면서 상충 지시가 공존하게 되었고,
이는 Custom Prompt만으로 조정하기 어려운 영역이었습니다.
임베딩 임계값, RAG 재점수 기준, 구간 병합 로직 등
후속 파이프라인의 파라미터 역시 프롬프트의 통제 범위를 벗어나 있습니다.
프롬프트는 시스템의 한 구성 요소입니다.
후처리·검색·인터페이스와 역할을 구분하지 않으면 성능 개선은 한계에 부딪힐 수밖에 없습니다.
프롬프트의 책임과 시스템의 책임을 구분하는 인식이 먼저 필요합니다.