← 프로젝트 목록

AI systems · Backend

BuzzBot

시간표처럼 정확한 조회가 필요한 질문과 정책 문서처럼 문맥이 필요한 질문을 서로 다른 검색 경로로 처리하는 Georgia Tech 어시스턴트입니다.

담당
개인 프로젝트 · 시스템 아키텍처, 백엔드, 검색과 평가
공개 범위
비공개 저장소
기술
FastAPI · LangGraph · PostgreSQL · pgvector · Hybrid Retrieval

Actual product

실제 동작

01

학기별 CS 강의 목록 조회

Fall 2026 CS 과목을 구조화된 목록으로 반환하고, 답변 아래에 조회에 사용한 공식 출처를 함께 보여 줍니다.

BuzzBot이 2026년 가을학기 CS 강의 목록과 공식 출처를 답변한 화면
Which CS courses are offered in Fall 2026?
02

교수자와 분반 정보 조회

CS 2200 담당 교수와 각 분반을 표로 묶고, 실제 시간표 데이터의 근거 행을 답변 아래에 연결합니다.

BuzzBot이 CS 2200 교수자와 분반, 공식 시간표 출처를 답변한 화면
Who teaches CS 2200?
03

학사 일정의 기한 확인

수강 철회 기한처럼 문서 근거가 필요한 질문은 날짜와 시간대를 답하고, Academic Calendar의 관련 문장을 인용합니다.

BuzzBot이 수강 철회 기한과 Georgia Tech 학사 일정 출처를 답변한 화면
When is the withdrawal deadline?
질문을 SQL 또는 RAG로 라우팅하고 근거 검증과 답변 검증을 거치는 BuzzBot 백엔드 흐름
tkim602/BuzzBot-backend · README.md
시간표 SQL 질문 통과
150/150
강의 정보 검색 질문 통과
120/120

Hit@1과 Hit@5 기준

정책 답변의 근거 포함률
92%
근거 없이 확신한 정책 답변
0%
01

Context

대학 정보에는 강의 시간과 좌석처럼 정확한 행이 필요한 데이터와, 규정과 일정처럼 문맥을 찾아 인용해야 하는 문서가 함께 있습니다. 모두 semantic search로 처리하면 시간표 조회가 흔들리고, SQL만 사용하면 문서 질문에 답할 수 없습니다.

자연스러운 문장보다 올바른 출처를 고르는 일을 먼저 성공 기준으로 뒀습니다. 새 데이터 수집이 실패했을 때 기존 정보를 망가뜨리지 않고, 검색 실패와 답변 실패를 따로 재현할 수 있어야 했습니다.

02

Engineering

FastAPI가 질문을 받고 LangGraph가 시간표와 문서 경로를 고릅니다. 시간표는 공개 OSCAR 데이터를 정규화한 PostgreSQL에서 SQL로 조회하며 LLM을 사용하지 않습니다. 문서 질문은 pgvector와 PostgreSQL FTS로 후보를 찾고 RRF와 reranking을 거쳐 답변에 쓸 문서를 고릅니다.

생성 모델에는 선택된 문서와 citation 정보를 구조화해 전달합니다. 답변 뒤에는 인용이 실제 문장을 뒷받침하는지 확인하고, 근거가 약하면 한 번만 다시 검색한 뒤 답변을 중단합니다. 새 수집이 실패하면 현재 데이터를 덮어쓰지 않고 마지막 정상 버전을 계속 제공합니다.

내가 맡은 일

  • 시간표 SQL 경로와 문서 RAG 경로를 나눈 시스템 구조를 설계했습니다.
  • 데이터 수집과 정규화, hybrid retrieval, 인용 정보 구성과 답변 검사를 구현했습니다.
  • 시간표 조회, 문서 검색, 답변 정확성, 인용 적합성과 답변 거부를 각각 측정했습니다.

주요 기술 판단

시간표는 SQL로 직접 조회

강의 시간과 좌석은 정확한 행을 반환해야 하므로 vector similarity 대신 공개 OSCAR 데이터를 SQL로 조회합니다. 문서 검색 성능이 시간표 정답에 영향을 주지 않게 했습니다.

재검색은 한 번만 허용

모델이 임의로 도구를 반복 호출하지 않게 route, retrieve, validate 순서를 고정했습니다. 근거 검사가 실패하면 한 번만 다시 검색하고, 그래도 부족하면 답하지 않습니다.

실패한 수집은 현재 데이터에 반영하지 않음

새 수집이 일부만 끝난 상태에서는 현재 데이터를 덮어쓰지 않습니다. 전체 작업이 완료된 경우에만 새 버전으로 교체해 사용자가 부분 데이터에 노출되지 않게 했습니다.

03

Validation

시간표 SQL, 질문 분류와 화면 출력은 각각 150/150, 150/150, 140/140을 통과했습니다. 강의 정보 검색은 상단의 120개 질문에서 Hit@1과 Hit@5를 모두 충족했고, Academic Calendar route/Hit@5는 20/20이었습니다.

정책 답변은 correctness 71%, citation entailment 78%를 기록했습니다. 검색과 답변을 따로 평가해, 답변 문장보다 문서 검색이 먼저 개선되어야 한다는 점을 확인했습니다.

실패와 변경

  • 정책 Evidence Hit@5는 70%로 목표 85%에 미달했습니다. 정답 문서를 직접 넣은 oracle retrieval은 92%였기 때문에 답변기보다 검색이 더 큰 병목이었습니다.
  • hierarchical retrieval 근사는 Evidence Hit@5를 62%로 낮춰 실제 경로에 반영하지 않았습니다.

추후 발전 방향

  • 문서의 최신성은 마지막 수집 시점까지만 보장됩니다. 수집 시각과 원문 변경 여부를 기록하고 변경된 문서만 다시 색인하는 갱신 작업을 추가할 수 있습니다.
  • 정책 검색은 설정한 Evidence Hit@5 85% 목표에 아직 도달하지 않았습니다. chunk와 metadata 구조, reranking을 각각 고정 평가셋에서 비교한 뒤 근거가 확인된 질문부터 답변 범위를 넓히는 것이 다음 단계입니다.