5단계‐ RAG (Retrieval Augmented Generation) 적용 설계 - 100-hours-a-week/8-pumati-wiki GitHub Wiki

RAG 기반 GitHub 요약 챗봇 설계 문서

1. RAG를 적용할 경우 전체 데이터 흐름도

[사용자 질의]
   ↓
[질문 임베딩]
   ↓
[VectorDB(Chroma)에서 의미 기반 유사 문서 검색 (Top-k)]
   ↓
[관련 문서들 추출 → context 구성]
   ↓
[질문 + context → LLM 프롬프트로 작성]
   ↓
[LLM이 최종 응답 생성]
   ↓
[사용자에게 출력]

'사용자 질의 → 검색 → 결과 → 모델 응답' 으로 “모델이 직접 github 문서 내 모든 사항을 기억하지 않아도, 외부 문서를 실시간으로 검색해 context로 넣어주는 구조”

2. 사용하려는 외부 지식 소스에 대한 설명

소스	설명	선택 이유
🔹 VectorDB (Chroma)	팀별 GitHub 활동 내용을 문서 단위로 임베딩한 후 저장. 이후 의미 유사도를 기준으로 검색 가능.	✅ 유사 질의 검색이 가능하며, 경량화된 구조로 빠른 추론과 통합이 가능함. LangChain과도 쉽게 연동됨.
🔹 GitHub 커밋/릴리즈 문서	GitHub API를 통해 각 팀의 레포에서 주간 단위로 커밋 메시지, 릴리즈 노트, PR 내용을 수집하여 요약 텍스트 문서로 가공.	✅ 팀의 최신 개발 활동을 반영할 수 있는 신뢰도 높은 지식 소스이며, 자동화된 방식으로 최신화 가능함.
🔹 GitHub Wiki 문서	GitHub 클롤링으로 각 팀의 레포 내 Wiki 페이지 내용을 주간 단위로 수집 및 파싱하여 요약 텍스트 문서로 가공.	✅ 팀 내 기술 문서, 설정 가이드, 회의 기록 등 구조화된 내부 지식을 포함하고 있어, 사용자 질문에 대한 정성적인 답변 품질을 높이는 데 기여함.

수집 주기

매주 1회, 팀별 레포 URL 목록을 기준으로 자동 크롤링 - 주 1회 기간 선정 이유: - 주간 배치 방식이 안정적이며 운영 리스크가 낮음 - 질문 응답의 실시간이 더 중요하다고 판단 - 비용 절감(불필요한 실시간성) - 다른 팀의 업무 진행상황을 공유하기 용이함

전처리 방식

feat, fix, refactor 등 prefix 정규화, HTML/markdown 태그 제거, 중복 커밋 제거

결과 형태

팀별 `Document(page_content, metadata={team, date, repo})`

RAG 사용시 이점

이유	설명
최신 정보 반영	GitHub는 팀의 최신 활동을 반영할 수 있는 가장 신뢰성 높은 소스
실시간 질문 대응	매주 업데이트된 문서를 기반으로 RAG 검색 → 즉시 응답 가능
파인튜닝보다 효율적	매번 모델을 재학습하지 않아도 새로운 정보를 반영 가능
검색 품질	임베딩 기반 검색으로 질문이 정확하지 않아도 관련 문서 탐색 가능
유지보수 유연성	GitHub 크롤러와 VectorDB 저장 분리가 가능해 파이프라인 확장 용이

3. 검색을 위한 구현 내용 및 모델과의 통합 방법

a. 임베딩

항목	내용
모델	intfloat/multilingual-e5-small
선정이유	다국어에 유용한 임베딩 모델을 사용하여 Github문서 해석의 품질을 높이기 위함
방식	문단 단위로 나눈 GitHub 요약을 문서로 임베딩
인덱싱	Chroma를 통해 Top-k 검색 가능하게 구성

# 팀별로 문서 저장 (예: team3)
doc = Document(
    page_content="프론트엔드에 이미지 생성 기능 추가",
    metadata={"team": "team3", "week": "2025-W15"}
)
vectordb_team3.add_documents([doc])

✅ 모델 선정과정:

5개 질문에 대한 모델별 평균 유사도는 다음과 같다.

모델	평균 유사도 (5개 질문)	인코딩 시간	특징 요약
intfloat/multilingual-e5-small	0.8317	0.02s	가장 높은 유사도 + 빠름 (밸런스 최고)
paraphrase-multilingual-mpnet-base-v2	0.3254	0.01s	매우 빠르지만 정확도 낮음
BAAI/bge-m3	0.5087	0.04s	정확도 중간, 속도는 느린 편

b. 검색 쿼리

# 예: team3 전용 챗봇에서 질의
query = "이번 주에 어떤 작업을 했어?"
query_embedding = embed_model.embed_query(query)

# team3 VectorDB에서만 유사 문서 검색
results = vectordb_team3.similarity_search_by_vector(query_embedding, top_k=3)

c. LLM 프롬프트 통합

[System]
당신은 3조의 GitHub 활동을 요약해주는 전용 챗봇입니다.

[User]
이번 주에 어떤 기능을 구현했나요?

[Context]
- 이미지 생성기 프론트엔드 구현
- Stable Diffusion API 연동
- 코드 리팩토링 진행

[Assistant]
이번 주 3조는 이미지 생성 기능 구현과 관련하여 프론트엔드 레이아웃 작업과 Stable Diffusion API 연동 작업을 수행했습니다.

4. RAG 적용 전후의 예상 효과 및 검증 계획

🔹예상 효과

비교 항목	RAG 적용 전 (모델 단독)	RAG 적용 후 (팀별 RAG)
최신성	❌ 모델이 학습된 시점까지만 반영 GitHub 상의 최신 커밋이나 릴리즈는 반영 불가	✅ 각 팀 레포를 주기적으로 크롤링하여 최신 정보를 VectorDB에 저장함으로써 최신 활동을 반영 가능
정확도	❌ 질문에 대해 무관한 답변 생성 또는 “잘 모르겠어요”와 같은 hallucination(환각 응답) 발생 가능	✅ 각 팀별로 저장된 요약 데이터에 기반하여 근거 있는 응답 가능
팀 구분	❌ 모든 팀을 혼합된 상태로 인식하거나, 임의의 팀으로 응답할 위험 있음	✅ 챗봇이 팀 단위로 완전히 분리되어 해당 팀의 문서만 검색함으로써 응답 대상 혼동 없음

🔹 검증 계획

| 항목 | 설명 | | --- | --- | | 🔹 실사용 테스트 시나리오 | 예: "3조 이번 주 백엔드 뭐 했어?", "이미지 기능 추가한 팀 알려줘" 등 | | 🔹 비교 방식 | 동일 질문을 RAG 적용 전/후 모델에 입력 → 응답 정확성 비교 (RAG 미적용 시 hallucination 발생 여부 측정) | | 🔹 정확도 판단 기준 | ① 실제 GitHub 커밋/릴리즈 내용과 비교, ② 정답 여부 수작업 확인 | | 🔹 사용자 반응 기반 정성 평가 | 사용자 테스트 중 "정확한 것 같다/아니다" 등의 반응 수집 → 구조 수정 피드백에 반영 |

5. RAG가 적합한 이유

현재 구조에서는 RAG가 적합하지만, 만약 RAG를 제외한다면 아래와 같은 문제점이 발생할 수 있다.

❌ 문제점:

항목	설명
모델 입력 길이 제한	많은 팀 데이터 포함 불가
정보 업데이트 어려움	질문 내용 바뀌면 정답률 하락
환각 발생 가능	“모름” 대신 없는 팀 정보 만들어낼 수 있음

6. 선택한 방안이 서비스 목표에 부합하는 이유

서비스 목표	적용 구조 적합성
최신 GitHub 활동 반영	주 1회 자동 크롤링 + 벡터DB업데이트로 최신 팀 활동 반영 가능
팀별 응답 정확도	VectorDB + 메타 검색으로 가능
검색 속도와 효율	경량 VectorDB + 단문 응답으로 처리 시간 최소화 미리 크롤링해서 VectorDB에 저장해뒀기 때문에, 실시간 API 호출 없이 빠르게 검색 가능
확장성	팀 수가 늘어나도 구조 변화 없이 대응 가능

정확도 예시(메타 검색)

기능	효과
팀별 챗봇 완전 분리	1조, 2조, 3조 각 챗봇이 자신의 문서만 검색하게 제한 가능
주차별 검색도 가능	“이번 주 뭐했어?” → `metadata={"week": "2025-W15"}` 필터 추가
빠르고 정밀한 RAG	유사도만으로 검색 시 노이즈 발생 가능, 메타 필터로 제거 가능

최종 요약

항목	결론
데이터 흐름	질문 → 임베딩 → 벡터 검색 → LLM 응답
외부 지식 소스	GitHub 문서 + VectorDB (Chroma)
구현 방식	bge 임베딩 + LangChain Retriever + 프롬프트 통합
효과	정확도, 최신성, 확장성 모두 향상
비-RAG 대안	있음, 하지만 한계 큼
서비스 적합성	매우 높음 (실시간 요약 기반 챗봇에 최적)