일일 개발 및 기획 로그 요약

1. 작업 분포

카테고리	비중
데이터 전략/생성	60%	██████░░░░
시스템 아키텍처/분석	40%	████░░░░░

2. 집중 영역 / 시간 소모 포인트

🟢 생산적 작업

데이터 품질 고도화 전략 수립: 런타임 비용 절감을 위해 검색 응답 모델(GLM)은 유지하되, 고품질 시드 데이터 생성에 리소스를 집중하는 방향으로 전략 수정.
시드 데이터 확장: 44개였던 데이터를 1차(59개), 2차(74개)로 단계적으로 확장. 특히 why 필드를 단순 사실 설명에서 ‘문화적 매력 설명’으로 강화하는 프롬프트 엔지니어링 수행.
RAG 파이프라인 개선안 도출: 검색된 why 필드가 답변의 뼈대가 되도록 하여 GLM의 한계를 보완하는 구조 제안.

🔴 삽질/시간 소모 포인트

모델 선택 고민: Claude API로 런타임을 교체할지 고민하다가, 추가 비용 발생 우려로 인해 기존 GLM을 유지하고 데이터 생성 파트에만 Claude를 활용하는 쪽으로 결론 내리면서 일부 시간 소요.

3. 타임라인

15:38 🦦 (AI): 기존 데이터(44개)와 병합하여 총 59개로 업데이트. GLM의 한계를 보완하기 위해 시드 데이터의 why 필드 강화 및 Claude API 도입 제안.
16:53 User: 런타임에 Claude API를 사용하는 것은 비용 상 비효율적임을 지적. 생성 단계에서만 활용 가능하다고 언급.
16:54 🦦 (AI): GLM(런타임) + Claude(생성)의 하이브리드 전략 확정. why 필드에 문화적 배경과 매력을 담는 상세한 생성 프롬프트 작성 및 15개 신규 데이터 생성 요청.
17:41 User: 15개 분량의 신규 JSON 데이터 전달.
17:45 🦦 (AI): 데이터 병합 완료(총 74개). why 필드의 서술 퀄리티 향상 확인. Qdrant 인덱싱(python3 index_qdrant.py) 필요성 안내.

4. 해결한 문제와 인사이트

🛠️ 해결한 문제

답변 품질 저하 이슈: GLM이 일반 학습 데이터에 의존하여 답변이 평범해지는 문제를, 시드 데이터의 why 필드에 ‘문화적 맥락’과 ‘매력 포인트’를 강제하여 RAG 검색 결과의 품질을 높이는 방식으로 해결.
데이터 중복 및 누락: 기존 데이터와 중복되지 않도록 상세한 제외 규칙을 프롬프트에 포함시켜, food, transport, manner, daily 카테고리별로 고품질의 신규 데이터 15개를 성공적으로 확보.

💡 인사이트

데이터 품질 = 답변 품질: 모델을 교체하는 것보다, RAG에 들어가는 시드 데이터의 퀄리티(특히 why 필드의 서술력)를 높이는 것이 비용 효율적이면서도 성능 향상에 직결된다.
비용 최적화 전략: 고가의 모델(Claude 등)은 런타임보다는 사전 데이터 생성 및 정제 단계에서 활용하여, 운영 비용은 절감하면서도 서비스 퀄리티는 높이는 ‘하이브리드 접근법’이 유효함.

Supported by ai-log-sync & GLM-4.7