지난번에 작성한 수리 지식 사이트의 속편입니다.

이번에는 이 사이트의 핵심 기능이기도 한 **수리 페이지를 자동 생성하는 배치 처리(JOB)**에 대해 소개합니다.

수리 영상을 하나씩 요약하는 것이 아니라, 동일한 고장을 다루는 여러 영상을 집약하여 하나의 수리 가이드로 통합하는 메커니즘입니다.

일반적인 AI 활용과 비교하면 방향성이 조금 다릅니다.

이 메커니즘으로 실현하고 싶었던 것은,

"영상을 이해하는 것"이 아니라, "동일한 고장에 관한 여러 영상을 수리 가이드로 통합하는 것"

입니다.

수리 영상은 매우 많이 공개되어 있지만, 다음과 같은 특성이 있습니다.

• 동일한 고장이라도 수리 방법이 미묘하게 다름
• 공구를 소개하는 영상이 있는가 하면 소개하지 않는 영상도 있음
• 주의사항을 적는 사람이 있는가 하면 적지 않는 사람도 있음
• 30분 이상의 영상도 드물지 않음

예를 들어 Switch의 Joy-Con 드리프트 수리에서도,

• 분해 방법을 자세히 설명하는 사람
• 케이블 단선 주의사항을 설명하는 사람
• 필요 공구를 소개하는 사람

등, 각각의 특기 분야가 다릅니다.

즉 필요한 것은,

1개의 요약 영상이 아니라, 여러 영상을 통합한 결과로서의 수리 가이드

입니다.

물론 영상의 내용이 항상 옳다고는 할 수 없습니다. 잘못된 수리 방법이 포함될 가능성도 있으며, 이 점은 앞으로도 개선해 나가야 할 과제입니다.

시스템 전체는 다음과 같이 구성되어 있습니다.

JOB1: YouTube 신착 영상 검색 & 등록 (6개 지역)
│
▼
...

이 기사에서 소개하는 주인공은 마지막인

「여러 영상 통합 & 수리 페이지 자동 생성」

부분입니다.

미분석된 수리 영상을 자체 GPU 서버로 보냅니다.

처리 내용은 다음과 같습니다.

• faster-whisper (large-v3)를 이용한 받아쓰기 (Transcription)
• OpenAI를 이용한 요약 생성
• 키워드 추출
• 챕터 생성
• 공구 후보 추출

여기서 중요한 것은,

모든 영상을 평등하게 해석하지 않는다

는 점입니다.

JOB2에서 계산한 조회수나 성장률을 이용하여, 현재 인기가 상승 중인 수리 영상을 우선적으로 해석합니다.

해석 비용이 높기 때문에 수요가 있는 영상에 GPU 리소스를 집중시키고 있습니다.

또한,

Whisper는

• 무음
• BGM
• 노이즈

등으로 인해 오인식하는 경우가 있습니다.

또한, 영상 마지막에 있는 인사나 감사 인사 등 수리와 관계없는 내용도 받아쓰기됩니다.

따라서,

• 제목
• 설명란
• 태그 정보

도 추가 정보로서 보완하여, 관계없는 내용은 무시하도록 합니다.

OpenAI를 이용하여

• device
• repair_type

의 2개 축으로 분류합니다.

예를 들어

와 같은 분류입니다.

분류 결과는

• repair_topics
• repair_topic_videos

에 저장되며,

예를 들어

switch-joycon-drift

라는 슬러그(Slug)가 생성됩니다.

여기서 처음으로 흩어져 있던 영상군이

「동일한 고장을 다루는 토픽」

으로 묶이게 됩니다.

이 부분이 이번의 메인입니다.

하나의 토픽에 연결된 각 영상에 대해,

• 영상의 요약
• 영상의 받아쓰기 (약 2,000자까지)

를 모아서 LLM에 입력하고, 여러 영상의 지식을 통합한 수리 페이지를 생성합니다.

// 토픽에 연결된 영상 ID를 취득
const videoIds = await db.getVideoIdsForTopic(topic.topic_id);
// 영상의 요약 데이터를 취득
...

const PAGE_PROMPT_TEMPLATE = (
device: string,
repairType: string,
...

생성되는 항목은 다음과 같습니다.

생성 결과는

repair_pages

에 저장되어 그대로 웹사이트에 표시됩니다.

즉,

여러 영상의 지식을 한 페이지의 수리 가이드로 통합하는

처리가 됩니다.

매번 생성하면 API 비용이 높아지기 때문에, 페이지 생성은 영상 수에 따른 임계값(Threshold)에서만 수행합니다.

3개
↓
6개
...

예를 들어

• 영상 3개일 때 초판 생성
• 6개가 되면 업데이트
• 10개에서 재업데이트
• 20개에서 최종 업데이트

와 같이 진행됩니다.

const thresholds = [3, 6, 10, 20];
const nextThreshold = thresholds.find(t => t > page.videoCount);
if (videoCount >= nextThreshold) {
...
}

이를 통해 데이터가 늘어날수록 페이지 품질은 향상되면서도, 불필요한 API 실행은 피할 수 있습니다.

LLM은 작업에 사용하는 공구와 교체 부품을 동일한 카테고리로 취급하는 경우가 있기 때문에,

• tools (공구)
• materials (재료)

를 완전히 분리하고 있습니다.

const TOOLS_VS_MATERIALS_RULE = `- **tools**에는 작업용 공구만 열거한다 (재료·부품·소모품은 **materials**에 작성한다).`;

이를 통해 나중에 다음과 같이 확장하기 쉬워집니다.

• 공구 목록
• 어필리에이트 (Affiliate)
• 상품 이미지

등.

LLM은

교체 부품

재료 1

배터리

등과 같이 모호한 명칭을 출력할 때가 있습니다.

그래서 다음과 같은 대책을 세우고 있습니다.

• 모호한 명칭 및 플레이스홀더 (Placeholder) 제거
  "교체 부품", "대상 부품", "재료 1", "부품 2" 등 모호한 것들을 제거.
• 일반 명사만 있을 경우, 디바이스 명을 앞에 추가
  "배터리", "필름", "케이블" 등 단독 단어라면 → "${device}용 배터리"와 같이 보완.
• 형식의 정규화
  명칭과 보충 설명을 세트로 구성하고, 유니코드 정규화 (NFKC)를 통해 표기 불일치를 없애고 공백을 제거.

materials = materials.map(item => {
if (!item.name.startsWith(device)) {
item.name = `${device}용 ${item.name}`;
...

"materials": [
{
"name": "Switch용 배터리",
"note": "모델 번호는…"
}
]

와 같이 보정하고 있습니다.

AI 문장을 '읽을 수 있는 문장'에서 모호성을 없앤

'구매 가능한 정보'

로 변환하고 있습니다.

수리 페이지 내에 이미지를 표시하여 시인성을 높이고 싶습니다.

Stable Diffusion 계열의 이미지 생성 모델에 관심이 있어 모델 선정 및 조정까지 포함하여 검증해 보았으나, 공구에 대한 정밀도가 낮아 제대로 된 이미지를 생성할 수 없었습니다.

AI는 단독으로 사용하는 것뿐만 아니라, 파이프라인 (Pipeline)으로서 조합함으로써 더욱 가치 높은 시스템을 만들 수 있다고 느낍니다.

수리 페이지에 표시할 이미지를 OpenAI API로 생성하는 메커니즘에 대해 소개하고자 합니다.

수리 노하우는 원래 YouTube에 많이 존재하지만,

그것들을 하나로 통합하는 메커니즘은 재미있을 것 같다고 생각했습니다.

이번에 소개한 파이프라인에서는 다음과 같은 흐름을 배치 처리 (Batch Processing)로 구현했습니다.

• 영상을 수집한다
• 성장률을 분석한다
• Whisper로 이해한다
• 고장 유형별로 분류한다
• 수리 가이드로 통합한다

NAS에 Node.js 환경을 구축하여 태스크 스케줄러 (Task Scheduler)를 통해 매일 자동화하고 있습니다.

최근에는 AI로 영상을 요약하는 것 자체는 드문 일이 아니게 되었습니다.

이번에 만든 메커니즘에서는 그 요약 결과를 다시 AI에게 전달하여, "여러 영상의 지식"을 통합한 수리 가이드를 생성합니다.

AI의 출력을 다음 AI의 입력으로 활용함으로써 더욱 가치 있는 정보로 변환할 수 있다는 점이 이 시스템의 흥미로운 부분이라고 생각합니다.

읽어주셔서 감사합니다!