8. 최종 통합 설계 및 회고 - 100-hours-a-week/20-real-wiki GitHub Wiki

📐 1. 서비스 아키텍처 다이어그램

📊 2. 단계별 설계 적용 결과 요약표

단계	주요 변경사항	성능/품질 향상 요약
1단계: 모델 API 설계	- FastAPI 기반 RESTful API 구축- /api/v1/chat 엔드포인트 구현	- 사용자 요청에 대한 안정적인 응답 제공- 오류 처리 및 상태 코드 명확화
2단계: 모델 추론 성능 최적화	- Qwen2.5-7B-Instruct 모델 선택- gpu_memory_utilization 조정 (0.8)- max_model_len 최적화 (2048)	- 추론 속도 향상- 메모리 사용 효율화- 긴 문서 처리 가능
3단계: 서비스 아키텍처 모듈화	- API, 서비스 로직, 프롬프트 관리, 예외 처리 등 역할별 디렉토리 구조 설계- /api, /services, /schemas, /core, /model 등으로 계층 분리	- 코드 유지보수성 향상- 기능 확장 용이성 증가
4단계: LangChain 기반 멀티스텝 AI 구현	- RetrievalChain 구조 도입- PromptTemplate 활용	- 다양한 문서 소스 대응 가능- 유연한 질의응답 처리
5단계: RAG 적용 설계	- FAISS 벡터 DB 구축- multilingual-e5-large-instruct 임베딩 모델 사용	- 의미 기반 검색 정확도 향상- 다국어 문서 처리 능력 강화

📈 3. 현재 완성된 시스템의 성능/품질 평가

• 응답 정확도
  → 의미 기반 검색을 통해 정확한 정보 제공

• 처리 속도
  → 최적화된 모델 설정으로 빠른 응답 시간 확보
  → 평균 응답 시간: 약 18초

• 다국어 지원
  → multilingual-e5 임베딩 모델 사용으로 다양한 언어 대응 가능

🧭 4. 프로젝트 수행에 대한 회고 및 평가

• 배운 점

  • 모델 경량화와 캐시 전략 설정의 중요성 체감
  • 모듈화된 구조로 기능별 협업 가능성 확보
  • 사용자 중심 UX 설계의 필요성 학습

• 어려움 및 해결

  • GPU 메모리 부족 → gpu_memory_utilization 조정으로 해결
  • 다양한 문서 포맷 처리 → LangChain 체인 구조 활용으로 해결

🔧 5. 앞으로의 개선 제안 및 계획

• 기능 추가

  • 사용자 피드백 기반 평가 시스템 도입 (예: 별점/수정 요청)
  • 실시간 Notion 문서 업데이트 자동 반영

• 최적화

  • 모델 경량화 및 추론 속도 향상
  • 양자화 및 LoRA 적용으로 추론 메모리 절감
  • 클라우드 기반 벡터 DB(Pinecone 등)로의 확장 고려

• 연구 및 개발 방향

  • 다양한 도메인에 RAG 적용 사례 확대
  • 사용자 맞춤형 응답 생성에 대한 심화 연구

🧠 6. 전반적인 결론

현재 구축된 AI 모델 서빙 아키텍처는 다음과 같은 이유로 타당하고 적절함:

• 효율성
  → 최적화된 모델 설정과 의미 기반 검색을 통해 높은 정확도와 빠른 응답 속도 달성

• 유연성
  → 모듈화된 아키텍처 + LangChain의 체인 구조로 다양한 문서 형식 및 기능 확장 용이

• 확장성
  → 클라우드 기반 벡터 DB와 도구 연동 확장을 통해 다양한 도메인 및 트래픽에 대응 가능

✅ 현재 구조는 실용성과 확장성을 모두 갖춘 적절한 선택입니다.