목차
- 들어가며: 지능형 AI 에이전트를 향한 첫걸음
- 대회 개요: Upstage AI Lab Competition
- 프로젝트 소개: 과학 기술 문서 기반 질의응답 시스템
- 주요 기능 및 개발 과정: 더 나은 답변을 찾기 위한 여정
- 프로젝트 회고: 성장과 학습의 기록
- 마치며: 대회를 넘어, 계속될 프로젝트
1. 🎯 들어가며: 똑똑한 AI 에이전트를 향한 첫걸음
이번 프로젝트는 제가 가장 기대했던 Retrieval Augmented Generation (RAG) 기반의 Q&A 시스템을 구축하는 프로젝트 였습니다. 원하는 정보를 정확하고 필요한 형식으로 가져오는 기술은 매우 강력하기 때문입니다. 방대한 데이터 속에서 단순한 내용 검색을 넘어, 상황까지 이해하고 적절한 답변을 제공하는 지능형 에이전트는 회사 내부 개발 문서 검색이나 법률 질의응답 등 다양한 도메인에서 높은 수요를 가지고 있습니다.
특히 RAG 기술을 과학 문서와 같은 특정한 전문 도메인에 맞춰 커스터마이징하고 질의응답 시스템을 구축할 수 있다면, 그 활용 가능성은 무궁무진해집니다. 이 경험은 AI 모델 구현력을 한층 더 깊게 만들어 줄 것이라 확신하며 배우고 싶은 열정이 많았습니다.
이 글을 통해 저희 팀이 더 나은 Q&A 시스템을 만들기 위해 어떤 고민을 했고, 어떤 기술들을 적용했으며, 그 과정에서 무엇을 배우고 느꼈는지 공유하고자 합니다.
Github Repository:
Information Retrieval for Scientific Documents Q&A
2. 대회 개요: Upstage AI Lab Competition
개요
Upstage AI Lab에서 주최한 이번 Information Retrieval 대회는 '과학상식 기반 질의응답'을 주제로 진행되었습니다. 주어진 과학 기술 문서들을 바탕으로 사용자의 질문에 가장 적절한 답변을 찾아내는 Q&A 시스템을 구축하는 것이 목표였습니다.
평가방법
대회에서 사용된 평가 지표는 수정된 MAP(Mean Average Precision)입니다. 이번 평가는 RAG 시스템이 생성한 최종 답변이 아닌, 질문에 적합한 레퍼런스 문서를 얼마나 잘 찾아내는가, 즉 검색(Retrieval) 단계의 성능에만 초점을 맞췄습니다.
가장 큰 특징은 기존 MAP 계산 방식에 특별한 규칙이 추가되었다는 점입니다. 대회에서 다루는 질문 중에는 과학 상식과 무관하여 문서 검색이 필요 없는 경우도 있었습니다. 이러한 질문에 대해서는 문서를 검색하지 않은 경우를 정답(1점)으로 처리하고, 불필요하게 문서를 검색한 경우에는 0점을 부여했습니다. 과학 관련 질문에 대해서만 기존의 MAP 계산 로직이 적용되었습니다
3. 🚀 프로젝트 소개: 과학 기술 문서 기반 질의응답 시스템
RAG, LLM과 어떻게 다를까요?
프로젝트를 소개하기 앞서, RAG가 LLM과 어떻게 다른지 짚고 넘어가는 것이 중요합니다. LLM은 방대한 데이터를 학습했지만, 학습 시점 이후의 실시간 정보나 특정 분야의 깊이 있는 정보는 알지 못해 잘못된 답변(Hallucination)을 할 수 있습니다. RAG는 이 문제를 해결하기 위한 효과적인 접근법입니다.
- LLM (Large Language Model): 초거대 언어 모델로서 방대한 정보를 바탕으로 학습되어 아는 것이 많습니다. 하지만 대중적인 지식 위주로 학습되었고, 최신 정보가 실시간으로 업데이트되지 않아 오래된 정보를 제공할 수 있다는 단점이 있습니다.
- RAG (Retrieval Augmented Generation): LLM이 외부의 최신 정보나 특정 지식에 접근할 수 있도록 설계된 기술입니다. 외부 데이터 소스나 도구를 활용하여 LLM의 한계를 보완하는 이 기술은 생각보다 복잡한 파이프라인으로 구성됩니다.
RAG는 먼저 외부 데이터를 잘게 쪼개고(Chunking) 검색이 용이하도록 가공하여 벡터 데이터베이스에 저장합니다. 사용자의 질문이 들어오면, 이 데이터베이스에서 가장 관련성 높은 정보를 검색(Retrieve)하고, 이 정보를 LLM에게 '참고 자료'로 함께 전달합니다. 최종적으로 LLM은 이 참고 자료를 바탕으로 신뢰도 높은 답변을 생성(Generate)합니다.
기본 이론
기본 개념은 간단 합니다. 하지만, 시스템을 개발하는 개발자는 구성품 뿐만 아니라 작업 흐름을 이해하고 성능을 fine-tuning 해야해서 이해해야 하는 구성품와 RAG 구현하면서 해결 해야 하는 문제들은 아래 그림을 보면 미리보기 할 수 있습니다.
개발자가 생각하는 문제들
RAG를 배우는 것은 LLM을 일부 배우는 것을 포함하고 있으며 저는 인공지능 전공자가 아니고 LLM을 공부할 생각이 없었는데 이번 대회에서 LLM, LM, 임베딩 모델, 리트리버 모델, 도구 호출 모델, 등 모두 생각보게 되었습니다. 효율적인 답변을 생성하기 위해서 어떻게 높은 품질의 답변이 가능한지 신기해서 항상 흥미럽다 생각했는데 이제 그런 답변을 생성하기 위해서 얼마나 많은 반복적인 프롬트 엔지니어링와 테스팅을 통해서 가능한지 알게 되었고 구현하면서 결과가 상용 같이 않아서 시장에서 누구나 져렴하게 접근할 수 있는 LLM 대해서 감상하는 방법을 배우기도 했습니다. 인공지능 개발하는 일은 정말 엄청난 집중력와 노고가 요구되는 것 같습니다.
저희 팀의 접근 방식
flowchart TD
A[👤 사용자 질문] --> B[🔌 API 계층]
B --> C[🧠 질문 인코딩]
C --> D{🔍 검색 전략}
D -->|Sparse| E[📝 BM25 검색]
D -->|Dense| F[🎯 벡터 검색]
E --> G[🔀 하이브리드 리랭킹]
F --> G
G --> H{⚡ 캐시 확인}
H -->|Hit| I[📊 결과 반환]
H -->|Miss| J[💾 저장 후 반환]
I --> K[📈 성능 평가]
J --> K
style A fill:#e1f5fe
style K fill:#f3e5f5
style G fill:#fff3e0저희 팀은 부트캠프에서 제공된 베이스라인 코드를 기반으로, 각자 시도해보고 싶은 접근법을 적용하며 과학 기술 문서 Q&A 시스템의 성능을 개선해 나가는 방식으로 실험을 진행했습니다.
- 베이스라인 기술 스택
- Python, Pytorch
- Korean Indexing: Nori tokenizer
- Embedding: KR-SBERT-V40K-klueNLI-augSTS (768D)
- Retriever/Tool Calling: GPT-3.5
- Vector Database: Elasticsearch
- LLM: OpenAI API
- 베이스라인 성능
- 샘플 제출 파일 성능:
- 베이스라인 리팩터링 후 성능 (동일):
샘플 제출 파일 성능
베이스라인 리팩터링 후 성능 (동일)
4. 🛠️ 주요 기능 및 개발 과정: 더 나은 답변을 찾기 위한 여정
저희는 더 정확하고 효율적인 Q&A 시스템을 만들기 위해 다음과 같은 기능들을 개발하고 실험했습니다.
데이터 기반 강화 (Data Foundation)
- 향상된 과학문서 데이터셋 생성: 원본 데이터셋은 정보는 많지만 검색이 용이하지 않았습니다. 이를 해결하기 위해 문서 요약(Summary), 핵심 키워드(Keyword), 그리고 가상 질문(Hypothetical Question)을 생성하여 메타데이터로 추가했습니다. 이를 통해 일상적인 질문과 전문적인 문서 내용 사이의 간극을 줄이고자 했습니다.
- 균형 잡힌 평가 데이터셋 생성: 제공된 평가 데이터셋이 없어 자체적으로 제작해야 했습니다. 초기 데이터셋은 특정 도메인에 편중되는 문제가 있어, 다양한 과학 분야를 고르게 포함하도록 균형을 맞춘 새로운 평가 데이터셋을 생성하여 보다 신뢰도 높은 평가가 가능하도록 했습니다.
- 임베딩 모델 파인튜닝 (Finetuning): 우리가 직접 강화한 데이터셋을 기반으로 임베딩 모델을 파인튜닝하여, 과학 도메인에 특화된 검색(Retrieval) 성능을 끌어올렸습니다.
핵심 기술 스택 (Core Technology Stack)
- 다양한 Retriever 및 Re-ranker 모델 실험: BM25, DPR, ColBERT와 같은 Retriever 모델과 bge-reranker, Llama-3 등 다양한 Re-ranker 모델을 실험하며 최적의 조합을 찾기 위해 노력했습니다.
- 질의응답 캐싱 (Redis Caching): 반복적인 질문에 대해 빠른 응답 속도를 제공하고 시스템 부하를 줄이기 위해 Redis를 활용한 캐싱 시스템을 도입했습니다.
분석 및 개발 도구 (Analysis & Development Tools)
- WandB를 활용한 추론 결과 시각화: 실험 결과를 눈으로만 이해하기에는 한계가 있었습니다. WandB를 연동하여 도메인별 성공/실패율, 성능 분포 등 추론 결과를 다각적으로 시각화하고 분석하여 모델 개선의 인사이트를 얻었습니다.
- Streamlit 기반 비교 분석 대시보드: 통계적인 분석만으로는 부족했습니다. 하이퍼파라미터 변경이나 새로운 기법 적용 시, 각 샘플의 추론 결과가 어떻게 변하는지 질적으로 평가하기 위해 Streamlit UI를 개발했습니다. 이를 통해 평가 데이터, 기존 추론 결과, 새로운 추론 결과를 나란히 놓고 비교하며 변화를 직관적으로 파악할 수 있었습니다.
- 단위 테스트(Unit Test) 도입: 복잡한 기능들이 추가되면서 디버깅이 점점 어려워졌습니다. AI 에이전트조차 해결하지 못하는 버그를 겪으며 개발 방식의 전환을 결심했고, 모듈별로 코드를 리팩터링하며 단위 테스트를 도입했습니다. 이를 통해 코드의 안정성을 확보하고, 설정 변경 시 문제가 어디서 발생하는지 체계적으로 추적할 수 있었습니다.
- 대화형 CLI 메뉴 도입: 기능이 많아질수록 코드를 작성하고 터미널 명령어를 관리하는 것은 점점 어려워집니다. 체계적인 관리가 없다면 인적 오류가 발생할 가능성이 높고, 이는 비효율로 이어집니다. 특히 다른 사람에게 사용법을 전달할 때 발생할 수 있는 혼동과 오류를 예방하고, 사용 편의성을 개선하기 위해 대화형 CLI 메뉴를 도입했습니다.
IR 프로젝트 - 대화형 CLI
- Setup & Infrastructure: 의존성 설치, 환경 설정, 로컬 서비스(Elasticsearch, Redis) 시작/중지 등 프로젝트 인프라 설정 및 관리 기능을 제공합니다.
- Data Management: Elasticsearch에 문서를 효율적으로 색인하고 데이터 품질을 검증하는 등 데이터 관리 작업을 지원합니다.
- Experiments & Validation: 기본 검증부터 Ollama 모델을 활용한 고급 실험까지 병렬 처리를 포함한 다양한 검색 성능 검증 옵션을 제공합니다.
- Evaluation & Submission: 다양한 모델(OpenAI, Qwen2, Llama 등)을 선택하여 대회 제출용 파일을 생성하고 평가하는 작업을 수행합니다
- Translation: 검증 데이터 및 문서 번역(Ollama/Google), Redis 캐시 관리 등 번역 관련 기능을 지원합니다.
- Utilities: 시스템 상태 확인, 스크립트 목록 조회, Streamlit UI 실행 등 프로젝트 유지보수 및 모니터링에 유용한 기능을 제공합니다.
📊 결과
- Private Dataset Results
- MAP: 0.9000
- MRR: 0.9030
- Public Dataset Results
- MAP: 0.8455
- MRR: 0.8500
대회에서 저희 팀은 3위를 차지했습니다. 다만, 저는 팀의 최종 점수 달성 과정에서 개인적인 실험 결과를 제때 반영하지 못해 기여도에 대한 아쉬움이 남습니다. 프로젝트 후반부에 발생한 파이프라인 버그를 수정하는 데 많은 시간을 쏟느라 최종 제출 시점을 놓쳤고, 결국 제가 개선한 모델의 성능을 최종 점수에 반영하지 못했습니다.
팀의 최고 점수 달성에 크게 기여하지 못해 아쉬움이 남지만, 대회 성적을 넘어 향후 프로덕션 수준으로 발전시킬 수 있는 견고한 프로젝트 기반을 만들었다는 점에서 개인적으로 큰 의미를 찾고 있습니다.
5. 🌱 프로젝트 회고: 성장과 학습의 기록
👍 좋았던 점 (What Went Well)
가장 만족스러웠던 점은 데이터 분석 및 평가를 위한 효율적인 도구를 직접 구축한 것입니다. 단순히 모델을 만드는 것을 넘어, 결과를 체계적으로 분석할 수 있는 환경을 만들었다는 점에서 큰 성취감을 느꼈습니다.
- Streamlit 비교 분석 대시보드: 개별 추론 결과를 기존 결과와 나란히 비교하며 질적 분석을 할 수 있었던 것이 모델 개선에 큰 도움이 되었습니다. 매번 파일을 열어보던 번거로움을 없애고 분석의 효율을 극대화했습니다.
- WandB 통계 분석 대시보드: 전체적인 성능을 도메인별, 성공/실패별 등 다양한 기준으로 시각화하여 통계적 분석을 용이하게 했습니다.
🤔 아쉬웠던 점 (What Could Be Improved)
- 팀 시너지 부족: RAG라는 주제를 처음 다루다 보니, 각자 어떤 부분에 어떻게 기여해야 할지 명확히 파악하기 어려웠습니다. 개인적으로는 기여했다고 생각하지만, 팀 전체의 시너지를 극대화하지 못한 점이 아쉬움으로 남습니다.
🔥 어려웠던 점 (Challenges Faced)
- 예상치 못한 디버깅 시간: 대회 후반, 복잡해진 시스템의 버그를 해결하는 데 많은 시간을 쏟았습니다. 결국 대회가 끝날 무렵에야 문제가 해결되어, 충분한 실험을 진행하지 못하고 좋은 점수를 얻지 못한 것이 가장 아쉽습니다.
- 까다로운 인덱스 관리: 여러 임베딩 모델을 실험하면서 모델 간 호환성 문제가 발생할 수 있다는 점, 그리고 인덱스가 존재하더라도 임베딩 벡터가 다를 수 있다는 미묘한 차이를 어렵게 깨달았습니다.
🤝 팀 기여 (Contributions to the Team)
- 개선된 베이스라인 코드 공유
- Summary, Keywords, Hypothetical Questions가 포함된 합성 데이터셋 생성 및 공유
- 최종 README.md 작성 및 리포지토리 마무리 정리
💡 배운 점 (Lessons Learned)
- 테스트 기반 개발의 중요성: 잘 작성된 문서는 물론, 안정적인 개발을 위해 단위 테스트는 선택이 아닌 필수라는 것을 절실히 깨달았습니다. 앞으로는 무조건 테스트 기반으로 개발을 진행할 것입니다.
- Local 모델 vs. 상용 API: 로컬 모델은 API 의존성 없이 개발할 수 있다는 장점이 있지만, 상용 API 모델에 비해 지시를 따르는 능력이나 전반적인 성능에 큰 차이가 있다는 것을 알게 되었습니다. 특히 복잡한 프롬프트 파이프라인을 로컬 모델이 모두 소화할 수 있는지, 인프라 요구사항은 어떤지 반드시 고려해야 합니다.
- 개발 프로세스의 중요성: 인공지능 프로젝트를 진행 하면서 인공지능와 전혀 관련 없는 문제들이 더 많은 것 같습니다. 인공지능 모델을 연구하고 개발하면서 경쟁력을 갖추기 위해서는 소프트웨어 개발, 디버깅, 데이타 검증 프로세스를 잘 이해해야 프로젝트 규모가 커지면서 관리하기 용이하게 관리할 수 있습니다.
6. ✨ 마치며: 대회를 넘어, 계속될 프로젝트
이번 프로젝트는 단순히 하나의 대회를 넘어, Information Retrieval 분야에 대해 깊이 있게 탐구하고, 팀원들과 함께 성장할 수 있었던 소중한 경험이었습니다. 이번 프로젝트를 통해 얻은 지식과 경험을 바탕으로, 더 나은 Q&A 시스템은 물론, 유사한 기술 스택을 활용한 챗봇 시스템, 코딩 에이전트, 멀티 에이전트 파이프라인 등 새로운 챌린지에 도전하며 계속 발전해 나갈 계획입니다. 이번 프로젝트를 통해 이전보다 더 큰 자신감과 배우고 싶은 열정이 생긴 것 같습니다.
배우면서 즐길 수 있는 것만큼 좋은 것은 없는 것 같습니다. 제게 소원이 하나 있다면, 부자가 되는 것보다 평생 즐겁게 배울 수 있는 기회를 갖는 것입니다. 이만 글을 마치며, 다음 포스팅에서 뵙겠습니다.
