RAG의 실패를
연구로 고칩니다

문제학과⁠·⁠부서별 웹사이트에 매년 2,000건 넘는 공지가 흩어져 올라와, 장학금⁠·⁠행사 공지를 놓치는 일이 잦았습니다.

구현Python 크롤러로 수집해 FastAPI⁠·⁠SQLite에 적재하고, Next.js에서 출처⁠·⁠카테고리로 탐색합니다. RAG 챗봇은 LLM 호출을 세 단계로 나눴습니다. 질문을 분기해 검색 키워드를 JSON으로 뽑고, 그 키워드로 공지 본문을 grep해 모은 후보를 다시 골라, 고른 근거로 답합니다(gpt-4.1-mini). LLM 호출이 실패하면 질문 원문으로 검색하는 경로로 돌아갑니다. 이미지⁠·⁠HWP로만 올라온 공지는 비전 모델로 본문을 뽑아 검색 대상에 넣었습니다. 백엔드는 AWS Lightsail 단일 서버에 Docker로, 프론트엔드는 Vercel에 배포했습니다.

1. 약 70개 교내 사이트Python crawler
2. FastAPI · SQLiteingest · search API
3. Next.jsbrowse UI
4. RAG 챗봇keyword grep → rerank
5. RAGASanswer eval

설계 결정과 운영운영하며 생긴 문제를 계측으로 확인하고 고쳤습니다.

• 질문 단어와 공지 단어가 달라('공모전'으로 물었는데 공지는 '해커톤') 단순 키워드 매칭이 놓치는 것을 확인하고, LLM이 검색 키워드를 고르게 바꿨습니다. 공지는 장학금⁠·⁠수강신청처럼 반복되는 핵심 단어가 많고 근거를 설명하기 쉬워, 벡터 임베딩 대신 키워드 검색을 유지했습니다. 글: RAG 고찰
• 자동 지표를 그대로 믿지 않았습니다. RAGAS answer_relevancy는 공지에 없는 날짜를 지어내지 않고 "명시되어 있지 않다"고 답한 경우를 0점 처리해(13건 평균 0.36), 사람 0/1 판정으로 바꿨습니다. 정답을 임의로 고정하고 운영 경로(분기⁠·⁠재정렬)를 거치지 않던 recall@k⁠·⁠MRR 평가는 지웠습니다. 평가는 기준일을 고정한 데이터 스냅샷에서만 돌려 실행 간 비교가 되게 했습니다. 글: RAG 평가 도입
• 공지를 메모리에 전부 올리던 초기 구조에서 OOM이 나, dmesg로 원인을 확인하고 SQLite로 바꾼 뒤 k6 부하 테스트로 검증했습니다. 글: 인프라 점검
• 비용⁠·⁠어뷰징에 대비해 rate limit⁠·⁠요청 크기⁠·⁠출력 토큰 상한을 걸고, Vercel Analytics로 사용 흐름을 봅니다. 글: 운영 리스크 글: 모니터링
• 질문자와 대상이 다른 공지가 근거에 섞이는 문제가 있었습니다(예: 대학원생의 질문에 학부생용 공지). 논문 작업에서 공지마다 붙인 대상 라벨을 운영에 적용해, 사용자가 신분을 고르면 그 대상의 공지만 근거로 쓰게 했습니다. 실제 운영 코드로 질문 날짜 시점을 재현한 평가 99문항(1회 실행)에서, 기존 34%였던 다른 대상 공지 혼입을 필터로 구조적으로 없앴고 첫 번째 근거가 정답 공지인 비율은 57% → 79%가 됐습니다.

현재최근 3개월 방문자가 1,500명을 넘고(Vercel Analytics), 유입 대부분이 교내 커뮤니티(에브리타임)입니다. 이어지는 연구는 Research에 적었습니다.

3개월 방문자

1,500+

수집 사이트

약 70

누적 수집 공지

2,400+

담당

End-to-End

서비스 열어보기 GitHub

문제대학 공지는 같은 내용이 학기마다, 대상별로 다시 올라와 가장 최근 공지가 질문한 사람에게 맞는 답이라는 보장이 없습니다. 2026학년도 1학기 수강신청 공지는 학부용이 대학원용보다 13일 먼저 올라왔고, 대학원 일정은 없었습니다. 그 사이 대학원생이 물으면 최신순 검색은 학부 공지로, 대상 필터 검색은 지난 학기 대학원 공지로 답합니다. 그래서 게시 여부를 (시리즈, 회차, 대상) 단위로 판단하는 문제로 정의했습니다. 맞는 공지가 아직 없으면 "아직 게시되지 않았다"고 답해야 합니다.

지금까지 한 일

• 운영 DB와 별개로 3년치 공지 7,857건을 다시 수집해 고정하고, 같은 공지가 여러 게시판에 올라오는 교차 게시 문제도 정리했습니다.
• 공지마다 적용 학기와 대상(8분류)을 붙이는 라벨 기준서를 v5까지 다듬고, 별도 검수자의 사람 검수 두 차례(503건⁠·⁠279건)를 거쳐 확정했습니다. 두 번째 검수에서 사람 판정과 대상 라벨이 92% 일치했고, 대상⁠·⁠회차 1,233쌍 중 193쌍(16%)에 게시 시차가 있었습니다.
• 질문 날짜 시점의 공지 목록을 재현하는 실험 환경을 운영 코드와 분리해 만들고, 날짜가 붙은 평가 질문 1,305개와 비교 방법 6종(BM25, 최신순, 대상 필터, 시점 기반 거부 등)을 구현했습니다.
• 대상 라벨은 운영 서비스에도 적용했습니다. 효과는 KAU Notice Hub 항목에 적었습니다.

연구용 공지

7,857

평가 질문

1,305

게시 시차 쌍

16%

비교 방법

6종

논문의 문제분포 강건 최적화(DRO)는 데이터가 바뀔 수 있는 범위 안의 최악 분포에 맞춰 모델을 학습합니다. 이 범위를 생성모델로 만들면 인과 구조를 어기는 분포가 섞이고, 인과 구조를 제약으로 걸면 표현력이 줄어듭니다. 논문은 생성모델을 서로 독립인 외생 변수 좌표마다 두고 고정된 구조 맵으로 보내, 인과 구조 호환성과 KL 분해를 함께 얻습니다.

담당

• 클라우드 도입 제안연구실 A5000 GPU에서는 step당 1.9초에 동시 4개가 한계여서 실험 일정의 병목이었습니다. 팀에 클라우드 GPU(Vast.ai)를 먼저 제안하고, 대여부터 환경 구성까지 담은 사용 가이드를 만들어 배포했습니다.
• 결과가 같은 학습 코드 개선상태 복사와 중복 계산을 걷어내 step당 0.53초 → 0.29초로 줄였고(노트북 CPU 기준), 개선 전후 학습 로그와 모델 파라미터가 비트 단위로 같은 것을 확인했습니다.
• 하드웨어 선택으로 탐색 시간 약 60배 단축제 실험은 모델이 작아(파라미터 4,545개⁠·⁠92개) GPU로는 빨라지지 않는다는 것을 프로파일링으로 확인하고, 192코어 CPU 인스턴스에서 동시 실행 수를 48⁠·⁠96⁠·⁠150개로 재 처리량이 가장 큰 96개로 돌렸습니다. 하이퍼파라미터 탐색 104회(83만 2천 step)를 1시간 49분에 끝냈습니다(실행당 1코어, 합계 48 core-hour). A5000 환경(step당 1.9초⁠·⁠동시 4개)으로 환산하면 약 110시간이 걸리는 양으로 약 60배이고, 코드 개선 몫(서버 기준 약 1.5배)을 빼도 약 40배입니다.
• 탐색 결과최악 환경 OOD 검증 MSE를 0.09567에서 0.09429로 낮췄습니다. 테스트 세트는 선택을 확정한 뒤 한 번만 평가했습니다.
• 비교 조건 문제 제기와 통일안방법 6개를 담당자가 나눠 구현하며 체크포인트 선택 기준이 달라져, 한 표의 숫자를 비교할 수 없다는 문제를 제가 먼저 제기했습니다. 교수님이 best OOD val로 통일하기로 정하신 뒤 학습⁠·⁠선택 규칙 통일안을 작성해 제안했고, 방법별 코드를 공용 저장소에서 점검해 어긋난 부분을 담당자에게 짚었습니다. 이 점검에서 SCOT 구현의 역변환 결함도 제가 찾아 담당자가 수정했습니다.

탐색 시간 (A5000 환산)

약 60배

탐색 104회 소요

1시간 49분

최악 환경 MSE (기존 0.0957)

0.0943

step당 시간

−45%

지표 해석평가 지표인 Brier Skill Score는 순위가 아니라 예측 확률이 실제 빈도와 맞는지(보정)를 채점합니다. 모델 판별력(AUC)이 0.53 수준이라 점수 차이 대부분이 보정에서 나온다는 것을 초기에 측정으로 확인했고, 4주를 "여러 모델을 어떻게 결합하고 보정할 것인가"에 썼습니다.

접근

• 라벨이 성공 + 반대방향 + 한복판 ≈ 0.90으로 분해된다는 관찰에서 출발해, 실패 유형별 부스터의 출력을 스태커가 다시 결합하는 구조를 설계했습니다(CatBoost, 63피처).
• 팀에서 운용한 LightGBM⁠·⁠신경망⁠·⁠EBM 등 5개 모델을 로짓 공간에서 가중 결합하고, 다항식 보정과 상황별 오프셋 보정을 얹었습니다.
• 평가 대상이 2025 시즌이라 모든 누적 통계가 그 이전 시즌만 참조하게 했고, 랜덤 K-Fold 대신 "2023년까지 학습 → 2024년 검증" 시간 분할 하나로 비교했습니다.
• 하루 5회 제출 제한이라 제출 하나를 측정 1회로 다뤘습니다. 제출 결과로 보정 강도를 추정하되, 추정에 계통 오차가 있음을 확인한 뒤로는 오차가 2배여도 손해가 없는 보수적 지점을 골랐습니다. 실패한 제출도 직전과의 차이로 원인을 특정했습니다.

담당저는 모델 구조 설계와 학습⁠·⁠앙상블⁠·⁠검증⁠·⁠제출 전략을 맡았고, 야구 도메인 지식이 있는 팀원이 피처 가설을 냈습니다. 팀원의 가설은 제가 직교성 분석으로 기존 피처와 겹치는지 걸러 모델 구조와 검증 설계로 옮겼습니다.

검증 규율제출 138회는 근거와 결과를 전부 원장으로 남기고, 채택 기준은 결과를 보기 전에 미리 등록했습니다. 배포 모델은 재학습 시 트리 잎값까지 동일하게 재현되는 것을 확인했습니다.

배운 것모델을 하나 더 얹기보다 무엇으로 결합하고 무엇으로 검증할지 정하는 것이 점수를 갈랐습니다. 도메인을 아는 팀원의 피처는 혼자서는 나오지 않았을 것이라, 역할 분담도 결과의 일부라는 것을 확인했습니다.

판별력(AUC)

0.53

결합 모델

5개

피처

63개

제출(전부 원장 기록)

138회

GitHub 리더보드

문제 재정의같은 요청이라도 파일을 읽었는지, 테스트가 통과했는지에 따라 다음 행동이 달라집니다. 그래서 문장 분류가 아니라 누적된 작업 상태를 추론하는 문제로 정의하고, 현재 요청과 과거 행동을 잇는 관계형 피처를 설계했습니다. 고전 ML과 Transformer 3종의 확률 블렌드에서는 개별 점수보다 오류를 보완하는 조합이 성능을 갈랐습니다.

AI Agent 운영 하네스실험 실행은 Claude 에이전트에, 전략⁠·⁠승인⁠·⁠제출은 제가 맡았습니다. 한 에이전트에 전부 맡기자 단계 누락과 정보 혼선이 반복돼, 원인을 모델 능력이 아니라 한 에이전트의 책임과 컨텍스트가 너무 넓은 구조로 보고 다시 설계했습니다.

• 역할을 17개 서브에이전트로 분리하고(전략 수립 / 데이터⁠·⁠누수 감사 / 학습 설정 검증 / 실행 / 제출물 검증 / 기록), 각 에이전트에는 맡은 역할에 필요한 최소 정보만 넘겼습니다.
• 자연어 보고 대신 산출물로 검증했습니다. effective_config, 코드⁠·⁠데이터 SHA 대조, 제출물 자동 검사로 학습 시작 전 결함을 2회 차단했습니다.

배운 것한 에이전트의 실수가 전체를 통과하기 어려운 구조가 됐고, 에이전트 성능이 모델만이 아니라 역할⁠·⁠컨텍스트⁠·⁠권한⁠·⁠검증 구조 설계에도 달려 있다는 것을 배웠습니다.

서브에이전트

17개

사전 차단한 결함

2회

하네스 구간 상승

+0.0058

제출

110회

회고 연구 일지 GitHub 리더보드

분업경량화 기법을 나눠 팀원들은 프루닝과 디스틸레이션을, 저는 양자화를 연구했습니다.

접근과 배운 것점수가 성능 50% + 속도 50%라 "어디까지 줄여도 성능이 버티는가"를 찾는 문제였습니다. GPTQ(llmcompressor)로 W4A16 양자화를 적용하고 캘리브레이션 데이터 구성을 바꿔 비교했습니다. 한국어 지식 강화 구성은 0.59, baseline은 0.49가 나왔지만, 같은 baseline 제출물을 다시 내자 0.61이 나와 구성 간 차이를 그대로 믿을 수 없었습니다. 모델을 고치기 전에 측정 자체를 믿을 수 있는지 먼저 따져야 한다는 것을 이 대회에서 처음 겪었습니다.

GitHub 리더보드