다음 주로 넘어가는 다리: 매뉴얼 Q&A 시스템의 뼈대

이 영상은 선택이다. 재생 59분으로 Day 5의 큰 몫을 차지하는데, 오늘 만드는 챗봇에는 여기서 말하는 청킹도 인덱싱도 들어가지 않는다. 아래 정리는 영상 요약이 아니라 다음 주(W2)에 붙일 구조를 미리 보는 설계 노트다. 오늘의 필수는 최종 프로젝트이고, 이 노트만 읽고 넘어가도 Day 5는 완성된다.

수천 페이지 제조 매뉴얼에서 답을 찾아 주는 시스템은 어떤 모양인가. 오늘 만드는 챗봇에 무엇이 빠져 있는지 알고 나면 다음 주에 무엇을 채우는지도 분명해진다.

1. 전체 아키텍처

[PDF 매뉴얼]
    ↓ 파싱 + 청킹 (섹션 단위, 500~800 토큰)
[청크 인덱스]
    ↓ 키워드 검색 (TF-IDF 또는 임베딩)
[관련 청크 Top-K]
    ↓ 프롬프트 조립
[LLM 호출]
    ↓
[구조화된 답변 + 출처 페이지]

2. 청킹 전략 비교

제조 설비 매뉴얼은 대부분 번호 체계(3.2.1 항목)가 있어 섹션 기반 청킹이 가장 효과적이다.

3. 비용 최적화 — 프롬프트 캐싱

동일한 system 프롬프트와 청크 인덱스를 매 호출마다 전송하면 비용이 커진다. GPT-4o는 캐시에 맞은 입력 토큰을 절반 값으로 계산한다. 다만 절감 폭을 하나의 범위로 말할 수 없다. 공급자마다 셈법이 달라서 Anthropic처럼 캐시를 읽을 때 크게 깎는 대신 캐시를 만들 때 더 받는 곳도 있다. 쓰기로 한 공급자의 요금 문서를 직접 본다.

# Retry 패턴
import time
for attempt in range(3):
    try:
        return client.chat.completions.create(...)
    except RateLimitError:
        time.sleep(2 ** attempt)  # 1s, 2s, 4s

함정 주의: 청크 크기를 너무 작게(< 200 토큰) 설정하면 답변에 필요한 맥락이 분산되어 품질이 떨어진다. 반대로 너무 크면(> 1500 토큰) 검색 정밀도가 낮아진다. 500~800 토큰이 실전 적정값이다.

다음 task와의 연결

오늘의 최종 프로젝트에는 위 구조가 들어가지 않는다. 오늘 만드는 것은 검색 없는 도메인 Q&A 챗봇이고, 청킹과 인덱싱은 W2 D1~D2에서 실제로 구현한다. 오늘은 "무엇이 빠져 있는지"만 알고 넘어가면 된다.