mermaid code

사규-_챗봇답변 전체 플로우.drawio.png

2. 전체 플로우 다이어그램 노드 상세 설명 표

(문서 업로드 → 전처리/QA → 검토 → 게시 → 인덱스 → 챗봇 응답)

2-1. 전처리·검토·게시 파이프라인 노드

노드 ID 노드 이름/역할 단계 구분 누가/어디서 실행하는지 내부 처리 내용 실패/예외 시 동작
A 시스템 관리자 문서 업로드 문서 인입 시스템 관리자(관리자 UI) 최종 승인된 사규/정책 문서를 파일 형태(PDF/HWP 등)로 업로드. 제목, 도메인, 버전, 시행일 등 메타데이터 입력. 포맷·용량·확장자 1차 검증 실패 시 업로드 차단 및 오류 메시지 표시
S1 상태 UPLOADED 상태 관리 백엔드(정책 관리 서비스) 업로드된 파일과 메타데이터를 DB/스토리지에 저장하고 상태를 **UPLOADED**로 설정. 없음. 아직 전처리 시작 전 단계.
P1 전처리 및 1차 마스킹 전처리·마스킹 전처리 엔진(워커/배치) 파일을 열고 텍스트 추출, 1차 PII 마스킹, 문단·조항·표 단위 청킹, 기본 전처리 규칙(머리글 제거 등) 적용. 예외 발생 시 상태 **PREPROCESS_FAILED**로 설정, 에러 로그 기록
QA1 구조 자동 체크 (전처리 QA 레벨 1) 자동 QA 전처리 QA 모듈(시스템) 텍스트 길이, 조항 번호 패턴(제1조..), 필수 섹션 제목(목적, 적용범위 등) 존재 여부 등을 자동으로 검사. 비정상 패턴 감지 시 “품질 경고 플래그”를 남기고 나중에 검토자 화면에 경고 아이콘/메시지 표시
QA2 이전 버전 비교 + 대표 질문 기반 QA (레벨 2/3) 자동 QA 전처리 QA 모듈(시스템) 이전 버전과 텍스트/조항 수 비교, 도메인별 대표 질문 세트로 RAG 질의 후 정상 응답 비율을 계산해 QA 점수 생성. QA 점수가 임계값 이하일 경우 “전처리 품질 낮음” 플래그 설정, 검토자에게 우선 검토 대상으로 표시
R1 전처리 결과 저장 (PREPROCESSED) 상태 관리 백엔드(정책 관리 서비스) 전처리된 텍스트·청크·QA 결과·품질 플래그를 저장하고 상태를 **PREPROCESSED**로 설정. 실패 시 PREPROCESS_FAILED로 전환. 검토자에겐 안 보이도록 처리
REV 콘텐츠 검토자 전처리 결과 검토 사람 검토 콘텐츠 검토자(검토 화면) 원본 문서 뷰어 + 전처리된 텍스트/청크 + QA 지표를 한 화면에서 보고, 누락·깨짐·구조 붕괴 여부를 사람이 확인. 문제 발견 시 **REVIEWED_FAIL**로 표시하고, 문제 내용 코멘트 남김
OK REVIEWED_OK (검토 승인) 상태 전환 콘텐츠 검토자 조작, 백엔드 반영 검토자가 “문제 없음”으로 승인하면 상태를 **REVIEWED_OK**로 전환. QA 점수와 함께 “검토 완료” 이력 기록. 없음. 이후 게시 여부는 시스템 관리자 결정
FAIL REVIEWED_FAIL (검토 반려) 상태 전환 콘텐츠 검토자 조작, 백엔드 반영 검토자가 전처리 결과에 문제를 발견하여 반려. “어떤 섹션 누락, 표 누락, 인코딩 깨짐” 등 사유를 남김. 관리자가 문서를 수정/재업로드해야 함. 기존 레코드는 검색에서 영구 제외
PUB 상태 PUBLISHED로 변경 게시 처리 시스템 관리자 REVIEWED_OK 문서 중 실제로 챗봇에 반영할 문서를 선택해 상태를 **PUBLISHED**로 전환. 잘못 게시한 경우, 상태를 다시 DEPRECATED / is_active=false로 전환하여 검색에서 제외
IDX RAG 인덱스 활성 문서로 포함 인덱싱·검색 대상화 RAG 인덱서(벡터 DB 쪽 서비스) PUBLISHED 문서의 청크를 벡터 DB 검색 대상 집합에 등록. 도메인·버전·유효기간 등 메타데이터 기반 필터 설정. 인덱싱 실패 시 로그 기록 및 관리자에게 경고. 실패해도 PUBLISHED 플래그만으로 검색 차단 가능

2-2. 챗봇 측 노드

노드 ID 노드 이름/역할 단계 구분 설명
Q 직원 질문 챗봇 입력 직원이 “USB 써도 돼?”, “사대보험 규정 요약해줘” 등 자연어로 질문을 던짐.
RAG RAG 검색 및 LLM 응답 생성 검색·응답 생성 질문 → 도메인/인텐트 분류 → PUBLISHED 상태 사규 인덱스 조회 → 관련 청크를 LLM에 컨텍스트로 넣어 응답 생성.
ANS 사규 근거 포함한 답변 반환 챗봇 출력 “USB 사용은 ○○ 조항 기준으로 금지/허용이며, 핵심 내용은 △△입니다”처럼 근거 조항을 함께 설명해서 반환.

포인트: RAG가 가져오는 것은 항상 PUBLISHED 상태의 최신 유효 사규 인덱스라는 점을 강조.

슬라이드 3. 전체 플로우 – 업로드부터 챗봇 답변까지

  1. “전체 흐름은 이렇게 보시면 됩니다. 시스템 관리자가 최종 승인된 사규를 올리면, 서버에서 1차 마스킹과 전처리를 돌리고, 자동 QA를 거친 뒤에 콘텐츠 검토자가 전처리 결과를 한 번 더 확인합니다.”
  2. “검토에서 이상 없다고 승인된 문서만 PUBLISHED로 게시되고, 이 시점부터 RAG 인덱스에 활성 문서로 올라가요. 이후에 직원이 ‘USB 써도 돼?’ 같은 질문을 하면, 이 PUBLISHED 사규 인덱스를 기준으로 답변이 생성됩니다.”
  3. “중요한 점은, 사규가 바뀌었다고 해서 매번 LLM을 재학습시키는 구조는 아니고, LLM은 그대로 두고 RAG 쪽 인덱스랑 메타데이터만 갱신해서 빠르게 반영하는 구조라는 점입니다.”

슬라이드 4. 전처리 QA 3단계 – 자동 체크 → 대표 QA → 사람 검토

  1. “전처리 품질 관리는 크게 세 단계로 나눴습니다. 먼저 구조 자동 체크 단계에서 조항 번호나 필수 섹션이 제대로 살아 있는지, 텍스트 길이가 비정상적으로 줄지 않았는지 같은 기본 건강 상태를 자동으로 보고요.”
  2. “두 번째로 도메인별 대표 질문 세트로 RAG에 직접 질의해서, 실제 질문 관점에서 응답이 잘 나오는지 자동 QA를 돌립니다. 여기서 나오는 정상 응답 비율을 전처리 품질 점수로 기록합니다.”
  3. “마지막 단계가 사람이 보는 검토입니다. 콘텐츠 검토자가 원본 PDF와 전처리된 텍스트, 그리고 방금 말씀드린 QA 지표를 같이 보면서 누락이나 깨짐이 없는지 최종 확인하고, 괜찮으면 REVIEWED_OK로 승인하는 구조입니다.”