1. 프로젝트 개요

패턴 채택 이유

단순 RAG가 아닌 복합 구조를 채택한 이유는 세 가지입니다.

1. Self-Correction Loop 필수: 법적 근거 없는 주장은 실무에서 치명적이므로 생성 결과를 검증하고 재생성하는 Evaluator-Optimizer 패턴이 필수입니다.
2. 4종 데이터소스 이질성: 법령·판례·가이드라인·통계는 청킹 단위와 검색 전략이 모두 다릅니다. 단순 파이프라인으로는 관리 불가합니다.
3. Zero Hallucination 강제: 모든 주장에 출처 인용을 의무화하는 Grounding Validation 노드가 별도로 필요합니다.

2. 전체 시스템 아키텍처

flowchart TD
    A[채용공고 JD 입력\\n텍스트 / PDF / URL] --> B[전처리 & 파싱\\n섹션 분리 · 정규화]
    B --> C[쿼리 분해 & 의도 분류\\n리스크 항목 추출]

    C --> D1[(법령 DB\\n조문 단위 청킹)]
    C --> D2[(판례 DB\\n사건 단위 청킹)]
    C --> D3[(가이드라인\\n섹션 단위 청킹)]
    C --> D4[(통계 & 사례\\n수치 단위 청킹)]

    D1 & D2 & D3 & D4 --> E[하이브리드 검색\\nVector + BM25 → RRF → Reranking → Diversity]

    E --> F[프롬프트 조립\\n컨텍스트 주입]
    F --> G[LLM 생성\\nStructured Output]
    G --> H{Grounding Validation\\n출처 검증 · 환각 탐지}

    H -- 통과 신뢰도 ≥ 0.8 --> I[후처리\\n리스크 점수 · Diff · Redis 캐싱]
    H -- 실패 신뢰도 < 0.8 --> J[Self-Correction Loop\\n실패 원인 진단 · 수정 프롬프트]
    J -- 재생성 최대 3회 --> G
    J -- 초과 --> K[오류 반환 · 수동 검토 플래그]

    I --> L[ComplianceReport\\nrisk_items · score · citations · fixes]
    L --> M[API 응답 → 클라이언트]

#레그 검색을 검사해서 잘됬는지 확인 다시 돌려보내는 레그 에이전틱 구조가 있어야 할것같음

3. 하이브리드 검색 내부 플로우

flowchart TD
    Q[검색 쿼리\\n리스크 항목 분해 결과] --> V & B

    subgraph 병렬 실행
        V[Vector Dense 검색\\ntext-embedding-3-small\\nTop-K 20 · 유사도 임계값 0.75\\nChromaDB]
        B[BM25 Sparse 검색\\n법령 키워드 사전 적용\\nTop-K 20 · k1=1.5 b=0.75\\nElasticsearch]
    end

    V --> R
    B --> R

    R[RRF 퓨전\\nscore = Σ 1 / k + rank\\nk = 60 · Top-40 선택\\nVector 0.6 : BM25 0.4]

    R --> CR[Cross-Encoder Reranking\\nBAAI/bge-reranker-v2-m3\\nTop-40 → Top-10\\n임계값 0.5 미만 제거]

    CR --> DF[Diversity Filter MMR\\nλ = 0.7 · 최종 Top-5\\n출처 다양성 보장]

검색 파라미터 상세

4. Evaluator-Optimizer 레이어 상세