12/18 진행 사항 공유

진행 사항 공유

Stage 1. 공통 flow(의도/슬롯 추출 + 플랜 선택 + 공통 번들링)

입력 표준화

• Chat Input : 사용자 질문 입력 시작점
• Normalizer / Request Parser
  • 사용자 원문을 정규화/표준 JSON 형태로 변환하는 전처리
  • “질문 원문 → 표준 request_json”으로 만들어 이후 슬롯/의도 추출이 안정적으로 동작

  {
    "version": "stage1.v1",
    "user_question_raw": "...",
    "user_question_norm": "...",
    "meta": {
      "note": "normalized",
      "parser": "rule_based"
    }
  }

의도/슬롯 추출 + 플랜 선택 + 공통 번들링

• Intent & Slot Extractor
  • request_json 기반으로 intent/slots 추출
    • intent(검색/유사사례/보고서 등)
    • detail_level(자세히/간단히)
    • requested_cases(몇 건 요청했는지)
    • 기간(날짜 범위)
    • 기관명
• Keyword Builder
  • router_json에서 검색용 키워드 리스트/CSV를 구성
  • max_keywords : 최대 키워드 수 (10)
• Plan Chooser
  • router_json 기반으로 Plan A/B/C 선택
• Filter Params Builder
  • router_json → DB 필터 파라미터(기관/기간/분야/카테고리 등) 정규화
  • Retriever가 이해할 수 있는 형태로 조건을 통일(빈 값/형식 흔들림 방지)
• Stage1 Bundle Builder
  • router_json + selected_plan + filter_params + keywords 등을 하나의 “공통 번들”로 합침
  • 이후 단계는 Stage1 bundle만 받으면 판단/검색이 가능

라우팅 페이로드 생성

• Stage2 Route Selector
  • Stage1 bundle을 Plan A payload / Plan B payload로 분해하고(필요시 fallback 정책 포함) 노드에 전달
  • skip/enable 게이팅 추가 작업 필요
• Payload Unpacker Plan A/B
  • Plan A/B payload를 downstream이 쓰기 쉬운 형태로 쪼개 전달

Stage 2. 플랜별 검색

Plan A 파이프라인

• Prefilter Candidates (SQL)

  • filter_params로 DB를 가볍게 훑어 후보 sub_code 목록을 좁힘

• Plan A Embedding Query Builder

  • 임베딩 입력용 질의 문자열 구성(질문 + 필요한 경우 필터 힌트)

• OpenAI Query Embedder (Plan A)

  • 임베딩 생성

• Embedding Extractor -> Message (Fixed)

  • 임베딩 결과 JSON에서 벡터만 안전 추출

• Postgres Hybrid Retriever (Plan A)

  • (프리필터된 sub_code 범위에서) 벡터+키워드 하이브리드 검색
    • top_k_vector, top_k_keyword: 후보 풀 크기
    • max_keywords: 키워드 사용량 제한
    • bonus_per_hit, max_bonus: 키워드 매칭 보너스(precision↑ 목적)
    • use_cosine: 거리계산 방식

• Cohere ReRanker (Plan A)

  • 후보를 질의 기준으로 재정렬(precision 향상)
    • top_n: rerank 후 유지 개수(너무 크면 후단 비용↑, 너무 작으면 다양성↓)

• DF -> JSON Message (Candidates)

  • DataFrame 결과를 Grouper가 처리하기 쉬운 JSON으로 변환.
    • max_rows: 후보 행 제한
    • max_chunk_chars: chunk 텍스트 자르는 길이

• Case Grouper (by sub_code)

  • 같은 sub_code(사례) 단위로 묶고 대표 chunk를 제한하여 “대표 사례 세트” 생성
    • max_cases: 최대 사례 수
    • max_chunks_per_case: 사례당 chunk 수(근거 밀도)

• Evidence Pack Builder (Plan A)

  • Grouper 결과를 “Evidence Pack” 텍스트로 렌더링(LLM이 그대로 인용 가능하게)
    • max_cases: pack에 넣을 사례 상한

Plan B 파이프라인

• OpenAI Query Embedder (Plan B)

  • 임베딩 생성

• Embedding Extractor (B)

  • 임베딩 추출

• Postgres Hybrid Retriever (Plan B)

  • 벡터+키워드 후보를 넓게 모으는 하이브리드 검색
    • top_k_vector, top_k_keyword: 후보 풀 크기(현재 300/300)
    • max_keywords: 키워드 수 제한
    • audit_fields_hard_filter, audit_fields_csv: 분야 제한
    • gate_hard_filter: 강제 게이트 적용 여부(실험용 토글)

• Cohere ReRanker (B)

  • 후보 재정렬

• DF → JSON(Message) Safe (B)

  • DF→JSON 안전 변환(Decimal/Datetime 등 직렬화 이슈 방지)

• Case Grouper (Meta Lift, MinUI)

  • 사례 그룹핑 + 메타정보를 보강해 대표 사례를 선정하는 변형 Grouper
    • max_cases, max_chunks_per_case: 대표 수/근거량 조절

• Evidence Pack Builder (Plan B)

  • 대표 사례 + 근거 chunk를 Prompt-friendly한 텍스트로 생성
    • max_cases: pack 내 사례 수
    • preview_chars: 근거팩 최대 길이(토큰/가독성/환각방지 균형)

Plan C 파이프라인

• Plan C Action Hints Extractor

  • 질문에서 “조치유형/처분/규정” 힌트를 뽑아 검색을 action 중심으로 유도

• Postgres Hybrid Retriever (Plan C)

  • action_hints를 가중치로 반영해 후보를 모으는 하이브리드 검색.
    • action_boost, field_boost: 액션/필드 매칭 가중치
    • candidate_k, top_k: 후보 풀 크기
    • w_vec, w_kw: 벡터/키워드 결합 가중치

• Cohere ReRanker

  • 후보 재정렬

• Case Grouper (Plan C: Action→sub_code)

  • action bucket별로 균형 있게 사례를 뽑는 그룹핑(다양성 확보)
  • max_cases: 최종 사례 수(현재 3)
  • max_per_bucket: 버킷당 최대 사례 수
  • max_chunks_per_case: 사례당 chunk 수

• Evidence Pack Builder (Plan C)

최종 선택/프롬프트/생성

• ABC Guard → Final Bundle

  • A/B/C 결과물을 검사해서 최종으로 사용할 route/pack을 결정하고 단일 final_bundle 생성
  • “selected_plan 우선 + (조건 미달 시) fallback” 형태의 게이트
  • min_cases: 최소 사례 수 기준(미달이면 fallback 고려)
  • allow_fallback: fallback 허용 여부

• Prompt Template Switch (Stage4)

  • final_bundle을 받아 상황에 맞는 템플릿을 선택해 최종 프롬프트 구성
  • report_template, search_template: 템플릿 본문(운영 룰의 최상위 계약)

• OpenAI