EDA_report.md

# 문서 요약 챗봇 프로젝트 EDA 보고서

**작성일**: 2024년 11월 11일 
**분석자**: 1팀(이유노, 김진욱, 박지윤, 지동진)

---

## 📋 목차
1. [데이터 개요](#1-데이터-개요)
2. [기본 통계 분석](#2-기본-통계-분석)
3. [파일 형식별 비교](#3-파일-형식별-비교)
4. [문장 구조 분석](#4-문장-구조-분석)
5. [품질 이슈 및 이상치](#5-품질-이슈-및-이상치)
6. [주요 인사이트 및 활용 방안](#6-주요-인사이트-및-활용-방안)

---

## 1. 데이터 개요

### 1.1 데이터셋 구성
- **총 파일 수**: 100개
- **PDF 파일**: 4개 (4%)
- **HWP 파일**: 96개 (96%)

### 1.2 데이터 출처
- 공공기관의 정보시스템 구축 사업 제안요청서
- 주요 발주기관: 대학교, 지방자치단체, 공공기관 등

### 1.3 데이터 구조
```
1팀 중급 프로젝트/
├── data/
│   ├── data_list.xlsx
│   ├── data_list.csv
│   └── files/
│       ├── 문서1.hwp
│       ├── 문서2.pdf
│       └── ...
```

> **💡 활용 방안**  
> 데이터 불균형(96:4)으로 인해 HWP 파일만 사용하는 전략 고려. PDF는 추가 수집 또는 제외 검토 필요.

---

## 2. 기본 통계 분석

### 2.1 문자 수 통계

| 통계량 | 값 |
|--------|-----|
| 평균 | 3,835자 |
| 중앙값 | 2,583자 |
| 최소값 | 80자 |
| 최대값 | 18,328자 |
| 표준편차 | 3,692자 |
| 1사분위수 (25%) | 1,188자 |
| 3사분위수 (75%) | 5,827자 |

**분포 특성**:
- 대부분의 문서가 1,000~6,000자 범위에 분포
- 소수의 긴 문서(10,000자 이상) 존재
- 극단적으로 짧은 문서(500자 미만) 약 25% 존재

> **💡 활용 방안**  
> - **RAG 시스템**: 평균 문서 길이(3,835자 ≈ 2,000 토큰)를 고려하여 청크 크기 512 토큰, 문서당 4-5개 청크 예상
> - **Fine-tuning**: 극단적으로 짧거나 긴 문서는 품질 필터링 대상
> - **API 모델**: 평균 길이 기준으로 프롬프트 최적화 및 비용 산정

### 2.2 문장 수 통계

| 통계량 | 값 |
|--------|-----|
| 평균 | 215.5문장 |
| 중앙값 | 161.5문장 |
| 최소값 | 5문장 |
| 최대값 | 1,107문장 |
| 표준편차 | 201.2문장 |
| 1사분위수 (25%) | 76.5문장 |
| 3사분위수 (75%) | 295.8문장 |

**분포 특성**:
- 중앙값(161.5)이 평균(215.5)보다 낮음 → 우편향 분포
- 소수의 매우 긴 문서가 평균을 끌어올림
- 대부분 100-300문장 범위에 분포

> **💡 활용 방안**  
> - **청크 분할**: 문장 단위 청크 분할 시 기준 설정 (예: 10-15문장당 1개 청크)
> - **품질 필터링**: 5문장 미만 문서는 내용이 부족할 가능성 → 제외 고려
> - **배치 처리**: 문장 수 기준으로 배치 크기 조정 가능

### 2.3 문장 길이 통계

| 통계량 | 평균 문장 길이 | 최대 문장 길이 |
|--------|--------------|--------------|
| 평균 | 16.3자 | 104.5자 |
| 중앙값 | 15.8자 | 106.5자 |
| 최소값 | 7.3자 | 13자 |
| 최대값 | 52.6자 | 259자 |
| 표준편차 | 5.6자 | 51.3자 |

**한국어 문장 특성**:
- 평균 문장 길이 16.3자는 한국어로서 적절한 범위 (일반적으로 15-20자)
- 최대 문장 길이의 편차가 큼 (표준편차 51.3자) → 일부 비정상적인 긴 문장 존재

> **💡 활용 방안**  
> - **이상치 탐지**: 평균 문장 길이 > 30자인 파일은 문장 분할 실패 가능성 → 재검토 필요
> - **전처리 전략**: 최대 문장 길이 > 150자인 경우 추가 분할 로직 적용
> - **품질 평가**: 정상적인 문장 길이 분포는 양질의 데이터 지표

---

## 3. 파일 형식별 비교

### 3.1 형식별 주요 지표

| 지표 | HWP (96개) | PDF (4개) | 차이 | 비고 |
|------|-----------|----------|------|------|
| 평균 문자 수 | 3,930자 | 1,548자 | HWP가 2.5배 많음 | ⚠️ PDF가 짧음 |
| 평균 문장 수 | 221문장 | 63문장 | HWP가 3.5배 많음 | ⚠️ PDF가 적음 |
| 평균 문장 길이 | **15.9자** | **26.8자** | PDF가 69% 더 김 | 🚨 비정상 |
| 최대 문장 길이 | 105자 | 84자 | 비슷 | ✅ 정상 |

### 3.2 시각적 비교

**파일 형식 분포**:
```
HWP: ████████████████████████████████████████████ 96개 (96%)
PDF: ██ 4개 (4%)
```

**문장 길이 박스플롯 해석**:
- HWP: 중앙값 약 16자, IQR(사분위 범위) 좁음 → 일관된 품질
- PDF: 중앙값 약 27자, 편차 큼 → 불안정한 품질

### 3.3 핵심 발견사항

#### 🚨 PDF 문장 길이 이상
- PDF의 평균 문장 길이(26.8자)가 HWP(15.9자)보다 **69% 더 김**
- 정상적인 한국어 문장 평균(15-20자)을 크게 벗어남

**추정 원인**:
1. 문장 분할 실패 (줄바꿈이 문장 구분으로 인식되지 않음)
2. 표나 목차가 한 문장으로 추출됨
3. PDF 내부 구조 문제 (이미지 기반 PDF일 가능성)

#### ✅ HWP 추출 품질 우수
- 평균 문장 길이 15.9자 → 한국어 자연어로서 적절
- 96개 중 95개가 정상 범위 → 추출 성공률 98.9%

> **💡 활용 방안**  
> - **PDF 처리 전략**: 
>   1. 다른 추출 라이브러리 시도 (pdfplumber, PyMuPDF)
>   2. OCR 적용 (이미지 기반 PDF 대응) - 시간 관계상 제외
>   3. 개선 실패 시 학습 데이터에서 제외
> - **HWP 중심 전략**: 추출 품질이 우수한 HWP 96개만으로 프로젝트 진행 가능
> - **데이터 균형**: PDF 추가 수집 또는 무시 결정 필요

---

## 4. 문장 구조 분석

### 4.1 평균 문장 길이 분포

**분포 특성**:
- **최빈 구간**: 15-20자
- **분포 형태**: 정규분포에 가까움
- **중앙값**: 15.8자
- **이상치**: 50자 이상인 경우 소수 존재 (약 1%)

**히스토그램 해석**:
```
 7-10자:  ▓▓▓▓▓░░░░░ (약 10개)
11-15자:  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░ (약 30개)
16-20자:  ▓▓▓▓▓▓▓▓▓▓▓░░░░░░░ (약 25개)
21-25자:  ▓▓▓▓▓░░░░░ (약 15개)
26-30자:  ▓▓░░░░░░░░ (약 8개)
31자 이상: ▓░░░░░░░░░ (약 5개)
```

> **💡 활용 방안**  
> - **품질 필터링**: 평균 문장 길이 > 30자인 파일은 문장 분할 로직 재검토 필요
> - **프롬프트 설계**: 대부분 15-20자 문장 → 간결한 응답 스타일 학습 가능
> - **모델 평가**: 생성된 요약문의 문장 길이도 15-20자 범위 유지 시 자연스러움

### 4.2 최대 문장 길이 분포

**분포 특성**:
- **중앙값**: 약 107자
- **분포**: 우편향 (대부분 100자 이하)
- **이상치**: 250자 이상 2개 (상위 1%)

**구간별 분포**:
```
  0-50자:   ▓░░░░░░░░░ (약 7개)
 51-100자:  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░ (약 40개)
101-150자:  ▓▓▓▓▓▓▓▓▓▓▓░░░░░░ (약 30개)
151-200자:  ▓▓▓░░░░░░░ (약 12개)
201-250자:  ▓░░░░░░░░░ (약 4개)
250자 이상: ▓░░░░░░░░░ (약 2개)
```

**이상치 파일**:
1. 인천광역시_도시계획위원회 통합관리시스템 구축용역.hwp (259자)
2. 고려대학교_차세대 포털·학사 정보시스템 구축사업.pdf (176자)

> **💡 활용 방안**  
> - **추가 분할 필요**: 최대 문장 길이 > 150자인 경우 추가 문장 분할 로직 적용
> - **Fine-tuning**: 비정상적으로 긴 문장은 학습 데이터 품질 저하 원인 → 필터링 고려
> - **RAG 청크 분할**: 긴 문장도 포함할 수 있도록 청크 크기 여유 있게 설정

### 4.3 특수문자 및 구두점 비율

#### 구두점 비율

| 통계량 | 값 |
|--------|-----|
| 평균 | 6.5% |
| 중앙값 | 5.6% |
| 최소값 | 1.0% |
| 최대값 | 67.8% |
| 표준편차 | 7.0% |

**분포 특성**:
- 대부분의 문서: 0-10% 범위에 집중
- 정상 범위로 판단 (한국어 문서 일반적으로 5-10%)
- 극단 이상치 1개 (67.8%) → 문제 파일

#### 특수문자 비율

| 통계량 | 값 |
|--------|-----|
| 평균 | 2.0% |
| 중앙값 | 0.5% |
| 최소값 | 0.0% |
| 최대값 | 73.1% |
| 표준편차 | 9.7% |

**분포 특성**:
- 대부분의 문서: 0-5% 범위에 극도로 집중
- 매우 낮은 특수문자 비율 → 깨끗한 텍스트
- 극단 이상치 1개 (73.1%) → 심각한 추출 오류

**히스토그램 해석**:
```
특수문자 비율:
 0-5%:   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ (약 95개) ← 정상
 5-10%:  ▓░░░░░░░░░ (약 3개)
10-15%:  ░░░░░░░░░░ (0개)
15%+:    ▓░░░░░░░░░ (약 2개) ← 이상

구두점 비율:
 0-10%:  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░ (약 90개) ← 정상
10-20%:  ▓▓░░░░░░░░ (약 8개)
20%+:    ▓░░░░░░░░░ (약 2개) ← 이상
```

> **💡 활용 방안**  
> - **품질 필터링 기준**: 
>   - 특수문자 비율 > 15% → 추출 실패로 간주, 제외
>   - 구두점 비율 > 20% → 비정상 문서, 검토 필요
> - **전처리 전략**: 대부분 특수문자가 적어 전처리 부담이 적음
> - **모델 학습**: 깨끗한 텍스트 → 고품질 학습 데이터

---

## 5. 품질 이슈 및 이상치

### 5.1 이상치 탐지 결과

**전체 요약**:
- **긴 문장 이상치**: 1개 (1.0%)
- **특수문자 과다**: 1개 (1.0%)
- **총 문제 파일**: 2개 (2.0%)
- **정상 파일**: 98개 (98.0%)

### 5.2 심각한 문제 파일 (학습 데이터 제외 필수)

#### 🚨 파일 #1: 고려대학교 PDF

**파일명**: `고려대학교_차세대 포털·학사 정보시스템 구축사업.pdf`

| 지표 | 값 | 정상 범위 | 평가 | 심각도 |
|------|-----|----------|------|--------|
| 평균 문장 길이 | 52.6자 | 15-20자 | ❌ 정상의 3배 | 🚨 심각 |
| 특수문자 비율 | 73.1% | 0-5% | ❌ 14배 초과 | 🚨 심각 |
| 문장 수 | 42개 | 100+ | ❌ 비정상적으로 적음 | 🚨 심각 |
| 문자 수 | 2,450자 | 3,000+ | ⚠️ 짧음 | ⚠️ 주의 |

**문제 진단**:
- 텍스트 추출 완전 실패
- 표/목차/특수기호만 추출된 것으로 추정
- 실제 본문 내용이 거의 포함되지 않음

**예상 원인**:
1. 이미지 기반 PDF (스캔 문서)
2. 복잡한 PDF 레이아웃 (다단 구성, 표 중심)
3. PDF 암호화 또는 보안 설정

**조치 방안**:
- ❌ **학습 데이터에서 완전 제외 (필수)**
- 재추출 시도 불필요 (품질 회복 불가능 판단)
- 대체 데이터 확보 고려

---

### 5.3 경미한 문제 파일 (수동 검토 필요)

#### ⚠️ 파일 #2: 인천광역시 HWP

**파일명**: `인천광역시_도시계획위원회 통합관리시스템 구축용역.hwp`

| 지표 | 값 | 정상 범위 | 평가 | 심각도 |
|------|-----|----------|------|--------|
| 최대 문장 길이 | 259자 | 100자 이하 | ⚠️ 상위 1% | ⚠️ 주의 |
| 평균 문장 길이 | 22.1자 | 15-20자 | ✅ 약간 높지만 양호 | ✅ 정상 |
| 특수문자 비율 | 0.5% | 0-5% | ✅ 정상 | ✅ 정상 |
| 문자 수 | 3,132자 | 1,000+ | ✅ 적절 | ✅ 정상 |

**문제 진단**:
- 전체적으로 정상이나 특정 문장만 비정상적으로 김
- 문단 분할 실패 가능성 (여러 문장이 하나로 합쳐짐)
- 리스트나 긴 설명문이 마침표 없이 작성되었을 가능성

**조치 방안**:
- ✅ **학습 데이터로 사용 가능 (기본)**
- 옵션 1: 해당 문장(259자) 수동 확인 후 분할
- 옵션 2: 그대로 사용 (나머지 품질이 양호하므로)
- 권장: **그대로 사용** (1개 문장만의 문제이므로 전체 품질에 영향 미미)

---

### 5.4 품질 필터링 기준

다음 기준으로 데이터를 필터링하면 고품질 데이터셋 확보 가능:

```python
# 품질 필터링 기준
quality_criteria = {
    'min_chars': 200,                 # 최소 200자 이상
    'max_avg_sentence_len': 30,       # 평균 문장 길이 30자 이하
    'max_special_ratio': 0.15,        # 특수문자 15% 이하
    'max_punct_ratio': 0.20,          # 구두점 20% 이하
    'min_sentences': 5,               # 최소 5문장 이상
    'max_sentence_len': 200           # 최대 문장 200자 이하 (선택)
}
```

**필터링 결과 예상**:
- 제외 예상: 2-3개
- 유지 예상: 97-98개
- 유지율: **97-98%**

> **💡 활용 방안**  
> - **자동 필터링**: 위 기준으로 자동 품질 검사 스크립트 작성
> - **수동 검토**: 경계선상의 파일(3-5개)만 수동으로 최종 판단
> - **버전 관리**: 원본(100개), 필터링 후(97개) 버전 모두 보관

---

## 6. 주요 인사이트 및 활용 방안

### 6.1 데이터 품질 인사이트

| # | 인사이트 | 근거 | 활용 방안 |
|---|---------|------|----------|
| 1 | **HWP 추출 품질 우수** | 96개 중 95개 정상 (98.9%) | HWP 파일을 주요 학습 데이터로 사용 |
| 2 | **PDF 추출 품질 불량** | 4개 중 1개 심각한 문제 (25%) | PDF는 재추출 시도 후 개선 없으면 제외 |
| 3 | **문장 길이 분포 양호** | 평균 15.9자, 표준편차 5.6 | 한국어 자연어 처리에 적합한 데이터 |
| 4 | **특수문자 비율 낮음** | 평균 2.0%, 95개가 5% 이하 | 깨끗한 텍스트, 전처리 부담 적음 |
| 5 | **데이터 불균형 심각** | HWP:PDF = 96:4 비율 | PDF 추가 수집 또는 HWP만 사용 |
| 6 | **문서 길이 적절** | 평균 3,835자 ≈ 2,000 토큰 | LLM 컨텍스트 윈도우에 적합 |
| 7 | **이상치 최소** | 98% 정상, 2% 이상치 | 높은 데이터 품질, 소수 파일만 처리 |

### 6.2 모델별 활용 전략

#### 🔍 RAG 시스템

**데이터 특성 기반 전략**:
```python
rag_config = {
    # 청크 설정
    'chunk_size': 512,              # 평균 문서 ≈ 2,000 토큰 고려
    'chunk_overlap': 50,            # 10% 오버랩
    'chunking_method': 'semantic',  # 문장 단위 분할
    
    # 예상 청크 수
    'chunks_per_doc': 4-5,          # 평균 문서 길이 기준
    'total_chunks': 400-500,        # 100개 문서 기준
    
    # 메타데이터
    'metadata_fields': [
        'filename',
        'organization',             # 발주기관
        'category',                 # 사업 분류
        'year'                      # 연도
    ],
    
    # 검색 설정
    'top_k': 5,                     # 상위 5개 청크 검색
    'similarity_metric': 'cosine'
}
```

**최적화 포인트**:
- 평균 문서 길이가 적절 → 과도한 잘라내기 불필요
- 문장 구조 양호 → 문장 단위 청크 분할 효과적
- 특수문자 적음 → 임베딩 품질 우수 예상

> **💡 실제 적용**  
> 1. 98개 정상 문서로 Vector DB 구축
> 2. 문서당 4-5개 청크 → 총 약 490개 청크
> 3. 한국어 임베딩 모델 사용 (KoSimCSE, multilingual-e5 등)

---

#### 🎓 Fine-tuning

**데이터 현황 평가**:
- **사용 가능 데이터**: 97-98개 (문제 파일 제외 후)
- **데이터 분할**: Train 78개, Val 10개, Test 10개
- **규모 평가**: 프로토타입용으로는 적절, 프로덕션용으로는 부족

**전처리 전략**:
```python
finetuning_config = {
    # 품질 필터링
    'min_chars': 200,
    'max_avg_sentence_len': 30,
    'max_special_ratio': 0.15,
    
    # 토큰 길이 제한
    'max_input_tokens': 2048,       # 평균 문서 포함 가능
    'max_output_tokens': 512,       # 요약문
    
    # 데이터 분할
    'train_ratio': 0.8,             # 78-80개
    'val_ratio': 0.1,               # 10개
    'test_ratio': 0.1,              # 10개
    
    # 포맷
    'format': 'chat',               # Chat format 사용
    'system_prompt': '당신은 공공기관 문서 요약 전문가입니다.'
}
```

**한계점 및 대응**:
- ⚠️ **데이터 부족**: 100개는 소규모 (이상적으로 500-1,000개 필요)
- ✅ **대응 방안**:
  1. 데이터 증강 (역번역, 패러프레이즈)
  2. Few-shot Learning 활용
  3. 기존 모델에서 계속 학습 (Continued Pre-training)
  4. 추가 데이터 수집

> **💡 실제 적용**  
> - Phase 1: 현재 데이터로 프로토타입 Fine-tuning
> - Phase 2: 성능 평가 후 데이터 확장 여부 결정
> - 목표: 데이터 300개 이상 확보 시 본격 Fine-tuning

---

#### 🤖 API 기반 모델

**데이터 특성 활용**:
```python
api_config = {
    # 프롬프트 설계
    'avg_doc_length': 3835,         # 평균 문서 길이
    'avg_tokens': 2000,             # 약 2,000 토큰
    
    # 비용 예측
    'input_cost_per_1k': 0.01,      # GPT-4 기준 예시
    'output_cost_per_1k': 0.03,
    'expected_output': 256,         # 요약문 토큰
    
    # 문서당 비용
    'cost_per_doc': (2000 * 0.01 / 1000) + (256 * 0.03 / 1000),
    # = $0.0276/문서
    
    # 캐싱 전략
    'cache_similar_docs': True,     # 유사 문서 캐싱
    'cache_ttl': 86400,             # 24시간
    'expected_cache_hit': 0.3       # 30% 캐시 적중률
}
```

**최적화 전략**:
1. **토큰 수 최적화**: 
   - 평균 2,000 토큰 → 대부분 문서가 한 번에 처리 가능
   - 긴 문서(>4,000 토큰)만 잘라내기 또는 요약 후 재요약

2. **캐싱 활용**:
   - 유사한 문서 패턴 많음 (공공기관 제안요청서)
   - 캐싱으로 30-40% 비용 절감 가능

3. **모델 선택**:
   - 간단한 요약: GPT-3.5-Turbo (저렴)
   - 복잡한 요약: GPT-4 (고품질)
   - A/B 테스트로 성능-비용 최적 지점 찾기

> **💡 실제 적용**  
> - 100개 문서 요약 비용: 약 $2.76 (캐싱 없을 때)
> - 캐싱 30% 적용 시: 약 $1.93
> - 프로토타입으로 충분히 활용 가능한 비용

---

### 6.3 프로젝트 진행 가능성 평가

#### ✅ 현재 데이터로 가능한 것

| 작업 | 가능 여부 | 데이터 충분성 | 비고 |
|------|----------|-------------|------|
| RAG 프로토타입 | ✅ 가능 | 충분 | 98개 문서면 충분 |
| API 기반 요약 | ✅ 가능 | 충분 | 테스트 및 검증 가능 |
| Fine-tuning 실험 | ✅ 가능 | 최소 요건 | 프로토타입 수준 |
| 성능 평가 | ✅ 가능 | 충분 | Test set 10개로 평가 |
| A/B 테스트 | ✅ 가능 | 충분 | 비교 실험 가능 |

#### ⚠️ 추가 작업 필요한 것

| 작업 | 필요 작업 | 현재 상태 | 목표 |
|------|----------|---------|------|
| 대규모 Fine-tuning | 데이터 확장 | 98개 | 300-500개 |
| 프로덕션 배포 | 데이터 검증 | 테스트 단계 | 안정화 |
| PDF 처리 안정화 | 추출 개선 | 25% 실패율 | 95%+ 성공률 |
| 다양한 문서 타입 | 데이터 수집 | 단일 도메인 | 멀티 도메인 |

#### 📊 데이터 품질 종합 점수

| 평가 항목 | 점수 | 설명 |
|----------|------|------|
| 데이터 양 | ⭐⭐⭐☆☆ | 프로토타입 가능, 실서비스 부족 |
| 추출 품질 | ⭐⭐⭐⭐☆ | HWP 우수(98.9%), PDF 문제 |
| 데이터 균형 | ⭐☆☆☆☆ | 심각한 불균형 (96:4) |
| 텍스트 품질 | ⭐⭐⭐⭐☆ | 문장 구조 양호, 노이즈 적음 |
| 일관성 | ⭐⭐⭐⭐☆ | 동일 도메인, 유사한 구조 |
| **종합 평가** | **⭐⭐⭐☆☆** | **프로토타입 개발 가능, 개선 필요** |

---

### 6.4 최종 권장 전략

#### Phase 1: 현재 데이터 활용 (즉시 시작 가능)

**우선순위 1 - RAG 시스템**:
```
목표: 문서 검색 기반 QA 시스템 구축
데이터: 98개 HWP 문서
예상 기간: 1-2주
성공 가능성: 높음 (⭐⭐⭐⭐⭐)
```

**우선순위 2 - API 모델**:
```
목표: GPT/Claude 기반 요약 시스템
데이터: 100개 문서로 프롬프트 최적화
예상 기간: 1주
성공 가능성: 매우 높음 (⭐⭐⭐⭐⭐)
```

**우선순위 3 - Fine-tuning 실험**:
```
목표: 소규모 모델 Fine-tuning 실험
데이터: 98개 (요약문 필요)
예상 기간: 2-3주
성공 가능성: 중간 (⭐⭐⭐☆☆)
조건: 요약문 데이터 확보 필요
```

#### Phase 2: 데이터 확장 후 (3-6개월)

**데이터 확장 목표**:
- 현재: 100개 → 목표: 300-500개
- PDF 비율: 4% → 목표: 20-30%
- 도메인: 단일 → 목표: 다중 (교육, 의료, 행정 등)

**확장 후 가능한 작업**:
- 본격적인 Fine-tuning (성능 향상 기대)
- 프로덕션 레벨 서비스 배포
- 다양한 도메인 문서 지원

---

### 6.5 팀별 액션 아이템

#### 데이터 전처리 담당
- [ ] 고려대학교 PDF 파일 제외
- [ ] 나머지 PDF 3개 재추출 시도
- [ ] 품질 필터링 스크립트 작성
- [ ] 최종 데이터셋 97-98개 준비
- [ ] 형식별 데이터 분리 (RAG용 청크, Fine-tuning용 페어)

#### RAG 담당자
- [ ] 98개 문서로 Vector DB 구축
- [ ] 한국어 임베딩 모델 선택
- [ ] 청크 크기 512 토큰으로 설정
- [ ] 검색 성능 테스트 (Recall@5 > 80% 목표)

#### API 개발자
- [ ] 평균 문서 길이 기준 프롬프트 설계
- [ ] GPT-4 vs GPT-3.5 A/B 테스트
- [ ] 비용 최적화 (캐싱, 토큰 절감)
- [ ] 100개 문서 테스트 실행

#### Fine-tuning 담당자 (선택)
- [ ] 요약문 데이터 확보 방안 검토
- [ ] API로 요약문 생성 (임시)
- [ ] 소규모 실험 진행
- [ ] 성능 평가 및 데이터 확장 필요성 판단

---

**보고서 끝**