EDA_report.md

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

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

---

📋 목차

1. 데이터 개요
2. 기본 통계 분석
3. 파일 형식별 비교
4. 문장 구조 분석
5. 품질 이슈 및 이상치
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 품질 필터링 기준

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

# 품질 필터링 기준
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 시스템

데이터 특성 기반 전략:

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개
• 규모 평가: 프로토타입용으로는 적절, 프로덕션용으로는 부족

전처리 전략:

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 기반 모델

데이터 특성 활용:

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로 요약문 생성 (임시)
• 소규모 실험 진행
• 성능 평가 및 데이터 확장 필요성 판단

---

보고서 끝