audit_rag_6.4 설명

JERRY·2025년 12월 30일

Project

목록 보기

14/14

아래 설명은 audit_rag_6.4 기준으로, 각 노드가 왜 존재하는지(목적), 무슨 원리로 동작하는지(개념 수준), 그리고 이번 성능 고도화에서 무엇을 손봤는지를 정리한 것입니다.

전체 그림

이 플로우는 사용자의 질문을 먼저 “어떤 유형의 질문인지” 분류하고, 그 결과에 따라 A/B/C 3가지 검색 전략 중 가장 맞는 방식으로 근거(사례/조항)를 찾은 뒤, 가장 그럴듯한 근거를 뽑아 LLM이 요청한 출력 형식으로 답변하게 만드는 구조입니다.

1) Chat Input

목적

사용자가 입력한 질문을 워크플로우에 “시작 신호”로 넣는 역할입니다.

2) Stage1 LLM Router

목적

질문을 (1) 새 질문인지/후속 질문인지, (2) 어떤 검색 플랜(A/B/C/D)이 적합한지, (3) 필요한 슬롯(기관/기간/키워드/처분 등)이 무엇인지를 판단해 “검색에 유리한 형태”로 정리합니다.

원리

“사람이 질문을 읽고 ‘이건 규정 조항을 물어보는 거네’, ‘이건 유사 사례를 더 찾자는 거네’”처럼 의도를 분류하고, 검색 엔진이 알아먹기 쉬운 단서(키워드/필터)를 뽑아주는 단계입니다.

성능 개선 작업(이번 고도화 관점)

분류 품질이 흔들리면 플랜이 잘못 선택되어 불필요한 대량 검색(특히 B) 로 가는 문제가 생기므로, 라우터 자체를 “안정형”으로 두고 이후 단계에서 규정/조항 의도가 있으면 강제 보정하는 (아래 Stage4)을 추가했습니다.

아직 부족한 점 / 개선

라우터가 뽑는 “규정/법령 의도”가 100% 안정적이지 않으면 C로 못 가는 케이스가 남습니다.
- 개선: 질문 유형 분류를 LLM 1회로 끝내지 말고, 규정/조항 키워드 룰 기반 보정 + confidence 기반 재질문(내부적으로만) 같은 하이브리드가 더 안정적일 수 있음.

3) Stage1 Bundle Builder

목적

라우터 결과(분류/슬롯/키워드/필터)를 “하나의 묶음(bundle)”로 만들어 이후 모든 노드가 공통 형식으로 쓰게 합니다.

원리

검색 파이프라인에서 자주 발생하는 문제는 “각 단계가 서로 다른 형태의 데이터/단서”를 기대하는 것입니다. 이 노드는 표준 포맷으로 통일해 downstream 복잡도를 줄입니다.

성능 개선 작업

표준화가 잘 되면, 후속 노드들이 방어코드/예외처리 때문에 시간을 낭비하는 일이 줄고, “플랜 전환/폴백” 같은 제어가 쉬워집니다.

아직 부족한 점 / 개선

bundle에 들어가는 슬롯 품질이 낮으면 결국 검색 품질도 낮아집니다.
- 개선: 슬롯(예: 처분/기관/기간) 추출에 사전(dictionary) + 정규식 + LLM을 혼합해 정확도/재현율을 올리는 게 효과적

4) Stage1 Payload Unpacker

목적

bundle 안의 여러 값(질문, 필터, 키워드 등)을 “다음 단계에서 쓰기 쉽도록” 꺼내주는 단계입니다.

원리

하나의 가방(bundle)에서 필요한 것만 꺼내 각 검색 플랜으로 나눠주는 분배기 역할입니다.
캐시가 있으면 동일 입력 반복 시 불필요한 재계산을 줄입니다(특히 라우터/정규화 계열).

성능 개선 작업

캐싱/안정 분배를 통해 “같은 질문을 여러 플랜이 참조할 때” 중복 비용을 줄입니다.

아직 부족한 점 / 개선

캐시 히트가 잘 안 나는 환경이면 체감이 낮습니다.
- 개선: 질문 정규화(공백/문장부호 등)를 더 강하게 해서 캐시 히트율을 올리는 방법이 있습니다.

5) Stage2 Route Selector ABC

목적

Stage1이 정한 플랜(A/B/C) 또는 상태에 따라 어느 검색 경로를 실제로 실행할지를 결정합니다.

원리

“이번 질문은 C가 맞다”면 C 라인만 타게 해 비용/시간을 줄이는 교통 정리입니다.

성능 개선 작업

잘못된 분기 때문에 “B까지 같이 돌려서 느려지는 문제”를 줄이려는 목적이 큽니다.

아직 부족한 점 / 개선

분기 오류는 완전히 사라지지 않습니다.
- 개선: 분기 confidence(확신도)가 낮으면 “B는 축소 모드로만 실행” 같은 “안전 모드”가 필요합니다.

6) Plan Enable Switch (A/B/C)

목적

운영 상황(성능/비용/디버깅)에 따라 특정 플랜을 켜거나 끄는 스위치입니다.

원리

실무 시스템에서 “지금 C가 오류가 나니 잠시 끄자” 같은 운영 제어가 필요합니다.

성능 개선 작업

직접 성능 향상보다는, 장애 시 전체 응답 실패를 막는 안전장치입니다.

아직 부족한 점 / 개선

수동 토글만으로는 운영이 불안정.
- 개선: 에러율/지연시간을 보고 자동으로 플랜을 조절하는 “adaptive routing”이 다음 단계입니다.

7) Plan Payload Gate (A/B/C)

목적

분기된 플랜 결과가 “비었거나(0건)” “형식이 깨졌거나” 할 때, 다음 단계로 무의미한 데이터가 흘러가지 않게 막는 검문소입니다.

원리

검색 결과가 비었는데 rerank나 stage4를 돌리면 비용만 낭비합니다. 그걸 차단합니다.

성능 개선 작업

불필요한 후속 계산(특히 rerank/LLM)을 줄여 체감 속도를 올립니다.

아직 부족한 점 / 개선

“0건”이라고 판단하는 기준이 너무 단순하면, 유효한 결과를 버릴 수 있습니다.
- 개선: 0건 판정은 “케이스 수”뿐 아니라 “스코어/근거 품질”을 같이 보는 게 좋습니다.

8) Payload Unpacker Plan A / Plan B / Plan C

목적

각 플랜에서 필요한 재료(질문/필터/키워드/임베딩 등)를 꺼내 플랜별 검색기에 맞춰 공급합니다.

원리

A/B/C는 검색 전략이 다르니 요구하는 단서도 다릅니다. 이를 플랜별로 맞춰 줍니다.

성능 개선 작업

플랜별로 “필요한 것만” 전달하여 불필요한 계산/데이터 전달을 줄입니다.

아직 부족한 점 / 개선

플랜별 요구가 계속 늘면 언팩 로직이 복잡해져 유지보수가 어려워집니다.
- 개선: 공통 스키마를 강화하고 플랜별 차이를 최소화하는 방향이 좋습니다.

9) Prefilter Candidates(SQL.Plan A 전용)

목적

Plan A는 “조건이 구체적”인 질문을 다룹니다. 그래서 전체 DB를 다 뒤지지 않고, 먼저 SQL 필터로 가능성 있는 문서/사례 후보(sub_code 등)를 좁힌 뒤 정밀 검색을 합니다.

원리(비유)

도서관에서 책 전체를 훑지 않고, 먼저 “분류코드/서가”를 좁힌 뒤 그 안에서만 자세히 찾는 방식입니다.

성능 개선 작업

이 단계가 잘 되면 이후 벡터/키워드 검색 범위가 작아져 속도·정확도가 동시에 좋아집니다(검색 공간 축소).

아직 부족한 점 / 개선

프리필터가 너무 빡세면 “0건”이 늘고, 너무 느슨하면 A의 장점이 사라집니다.
- 개선: “자동 완화(auto-relax)”를 더 정교하게(예: 조건을 단계적으로 풀되, 풀 때마다 품질 지표 체크) 하면 안정성이 올라갑니다.

10) Message Relay

목적

흐름 중간에 메시지 포맷/전달을 안정화하는 “중계기”입니다.

원리

복잡한 플로우에서는 연결 간 형식 차이로 사소한 오류가 나기 쉬워서, 중간에 “중계”를 둬서 안정성을 확보합니다.

성능 개선 작업

직접적인 속도 향상보다는 에러 감소(재시도/실패 방지)가 핵심입니다.

아직 부족한 점 / 개선

릴레이가 많아지면 구조가 복잡해집니다.
- 개선: 업스트림/다운스트림 형식을 더 통일하면 릴레이를 줄일 수 있습니다.

11) OpenAI Query Embedder / (Plan A) + Embedding Extractor

목적

사용자의 질문을 “의미 벡터(embedding)”로 바꿔서, DB에 저장된 embedding과 유사도를 계산할 수 있게 합니다.

원리(비유)

문장을 숫자 좌표로 바꾸어 “의미가 가까운 문장끼리 가까운 좌표”에 위치하도록 만드는 방식입니다. 그래서 “비슷한 사례”를 빠르게 찾을 수 있습니다.

성능 개선 작업

이번 최적화는 “임베딩 그 자체”보다, 임베딩을 활용한 검색의 후단 비용(후보 수, rerank 전송량)을 줄이는 데 집중했습니다.

아직 부족한 점 / 개선

임베딩 모델이 도메인(감사/규정)에 최적이 아닐 수 있습니다.
- 개선: (가능하다면) 도메인 특화 임베딩 또는 쿼리 리라이팅(검색용 질문 재작성)으로 recall을 올릴 수 있습니다.

12) Plan C Action Hints Extractor

목적

“주의/시정/통보/징계/환수” 같은 처분/조치 힌트를 질문에서 뽑아 Plan C(규정/처분 근거 중심 검색)를 더 잘 되게 합니다.

원리

법령/규정 관련 질문은 “무슨 행위 + 어떤 조치(환수/징계 등)”가 핵심 단서가 되는 경우가 많아서, 그 단서를 추출해 검색 조건에 반영합니다.

성능 개선 작업

이번 고도화의 핵심은 “조항을 반드시 출력”하도록 Stage4를 강화한 것이고, Plan C는 그에 맞춰 조항이 들어있는 후보를 더 잘 찾게 하는 역할을 합니다.

아직 부족한 점 / 개선

질문 표현이 다양하면 힌트 추출이 누락될 수 있습니다.
- 개선: 동의어 사전(환수=반환/회수/정산 등) + 정규식 + LLM 혼합이 필요합니다.

13) Postgres Hybrid Retriever (Plan A Filtered / Plan B / Plan C)

목적(공통)

DB(total_vdb)에서 “관련 있어 보이는 후보 문서/청크”를 찾는 핵심 검색기입니다.
“Hybrid”인 이유는 보통 두 축을 섞기 때문입니다:
1. 의미 기반(벡터 유사도): 표현이 달라도 의미가 비슷하면 잡힘
2. 단어 기반(키워드 매칭): 특정 용어(환수/성과급/부정지급 등)에 강함

원리(비전공자 버전)

“뜻이 비슷한 것”과 “단어가 직접 겹치는 것”을 둘 다 후보로 모아서 합친 다음, 다음 단계(rerank)가 최종적으로 가장 맞는 순서로 정렬하도록 넘깁니다.

성능 개선 작업(이번 고도화의 핵심 적용 영역)

Plan B는 가장 쉽게 후보가 많아져 느려지므로, Plan B의 후보 수(TopK)와 멀티쿼리 확장량을 줄여 rerank 병목을 완화했습니다(최종 파일 기준).
Plan A는 프리필터로 검색 공간을 줄이는 구조 자체가 성능에 유리합니다.
Plan C는 조치/규정 단서를 활용해 “조항이 나올 확률이 높은 후보”를 먼저 모으는 것이 목표입니다.

아직 부족한 점 / 개선

하이브리드 가중치/결합 방식이 고정적이면, 질문 유형에 따라 최적이 아닐 수 있습니다.
- 개선: 질문 유형별로 “벡터 비중↑ / 키워드 비중↑”를 동적으로 조절하면 품질과 속도를 동시에 개선할 여지가 큽니다.
DB 인덱스/쿼리 튜닝(특히 keyword 검색, full-text index)이 부족하면 속도는 한계가 있습니다.

14) DF Diversify (Plan A/B/C, cap per sub_code)

목적

검색 결과가 특정 문서/사례(sub_code)에 “쏠리는 현상”을 막고, 서로 다른 사례를 골고루 보여주기 위한 단계입니다.

원리(비유)

후보 100개가 모두 같은 사건의 다른 페이지면 사용자는 유용하지 않습니다.
그래서 “한 사건에서 최대 N개까지만” 같은 방식으로 다양성을 확보합니다.

성능 개선 작업

다양화는 품질 개선용이지만, 동시에 불필요한 중복 후보를 줄여 rerank 비용을 낮추는 효과도 있습니다(후보 중복 제거).

아직 부족한 점 / 개선

다양화가 과하면 진짜 정답이 있는 문서가 잘릴 수 있습니다.
- 개선: “상위 스코어는 보존” + “중하위에서만 다양화” 같은 전략이 더 안전합니다.

15) Cohere ReRanker (DF→DF, MinUI)

목적

하이브리드 검색 결과는 “대충 관련 있어 보이는 후보 목록”입니다.
Rerank는 그 후보들을 사용자의 질문 관점에서 다시 읽고 가장 관련 높은 순서로 재정렬합니다. 또한 top_n으로 잘라서 후단을 가볍게 만듭니다.

원리(비유)

“책 제목만 보고 후보를 모아온 뒤(검색)”, “요약을 다시 읽고 진짜 맞는 순서로 정렬하는(재평가)” 단계입니다.

성능 개선 작업(이번 고도화의 가장 큰 체감 포인트)

rerank는 외부 API 호출이고, 후보 텍스트를 많이 보내면 느려집니다.
따라서 rerank로 보내는 문서 수를 제한(MAX_DOCS_SENT)하고, 최종적으로 남기는 개수(top_n)를 현실적인 값으로 유지하도록 설계돼 있습니다.

아직 부족한 점 / 개선

rerank 품질은 “보내는 텍스트 품질”에 달려 있는데, chunk_text가 너무 길거나 불필요한 본문이 많으면 비용이 올라갑니다.
- 개선: 후보 텍스트를 “문제/조치/기준/의견” 중심으로 더 정교하게 잘라 보내면 비용 대비 품질이 좋아집니다.

16) Evidence Pack Builder (Plan B, Rerank DF)

목적

rerank된 후보를 바탕으로 사용자에게 보여줄 ‘근거팩’(관련 법령/내부지침 조항 + 대표 사례 요약)을 구성합니다.

원리(비유)

“판단에 필요한 근거 자료철”을 만드는 단계입니다.
이후 LLM은 이 근거팩을 보고 형식에 맞는 답을 작성합니다(근거 중심 응답).

성능 개선 작업(이번 이슈의 핵심 해결과 직결)

근거팩에 ‘관련 법령/내부지침 조항’ 섹션을 명확히 만들고, 없으면 “근거팩 내 직접 인용 없음”으로 표시하는 구조를 사용합니다.
이번 lawfix에서는 특히 Stage4가 이 정보를 안정적으로 읽도록 “(조항이 있으면) 반드시 출력되게” 연결을 강화했습니다(아래 Stage4 설명).

아직 부족한 점 / 개선

근거팩에 조항이 “없으면” 시스템이 새로 만들어내지 않기 때문에(의도적으로) 빈 결과가 나올 수 있습니다.
- 개선: DB에 related_law_names 같은 메타가 더 충실히 채워지도록 사전 추출/정제 파이프라인을 강화해야 합니다(근본 해결).

17) ABC Guard → Final Bundle (OneOut)

목적

A/B/C 결과를 비교해 “최종적으로 무엇을 답변 근거로 쓸지” 하나로 결정하고, 필요 시 폴백(B→A 등) 을 수행합니다.

원리(비유)

여러 팀이 찾아온 자료(A/B/C)를 보고, “이번 건은 C가 제일 적합하네”처럼 최종 결론을 내리는 심사위원입니다.
0건이면 폴백 규칙에 따라 다른 플랜 결과를 채택합니다.

성능 개선 작업

폴백을 무조건 다 돌리는 게 아니라, “비었을 때만” 또는 “최소 건수 미만일 때만” 동작하게 해 불필요한 계산을 줄입니다.

아직 부족한 점 / 개선

단순히 “건수”로만 선택하면, 건수는 많지만 질이 낮은 플랜이 선택될 수 있습니다.
- 개선: “건수 + 상위 스코어 + 조항 포함 여부 + 질문 의도 매칭” 같은 품질 지표 기반 선택이 필요합니다.

18) Prompt Template Switch (Stage4)

목적

질문 의도에 따라 출력 형식(템플릿) 을 자동으로 선택합니다.
예: 유사사례, 특정 처분 사례, 처분수준 추천, 위반 규정/조항(법령), 다중 요구사항 등.

원리

같은 근거팩이라도 사용자는 “조항을 달라”, “사례만 달라”, “처분수준 추천해달라” 등 원하는 출력이 다릅니다.
Stage4는 그 요구를 “정해진 답변 서식”으로 번역해 LLM에게 전달합니다.

이번 고도화에서 한 작업(당신이 지적한 ‘조항 미출력’ 문제의 핵심)

기존에는 “성과급 부정 지급 및 환수 미이행…” 같은 문장이 다중요구(multi) 로 분류되면서, 결과적으로 “조항을 반드시 출력”하는 템플릿이 선택되지 않을 수 있었습니다.
이번에는 법령/규정/조항/위반/근거가 질문에 포함되면, 문장에 “및/그리고”가 있어도 우선적으로 ‘위반 조항 템플릿(법령)’을 선택하도록 보강했습니다. (템플릿 구조 자체는 T_LAW 등으로 분리되어 있음)

아직 부족한 점 / 개선

템플릿 선택이 안정적이어도, 근거팩에 조항이 없으면 출력이 빈약해집니다.
- 개선: “조항이 반드시 필요”한 질문은 C 플랜 강제 + 조항 존재 후보 우선 같은 end-to-end 제어가 더 필요합니다.
또한 템플릿이 많아질수록 유지보수 부담이 커집니다.
- 개선: 템플릿 수를 줄이고(핵심 3~4종), 세부는 “조건부 블록”으로 구성하면 안정적입니다.

19) OpenAI (최종 답변 생성)

목적

근거팩 + 선택된 템플릿(출력 형식)을 보고, 사람이 읽기 쉬운 답변을 작성합니다.

원리(비유)

“자료철(근거팩)을 보고 보고서 서식(템플릿)에 맞춰 최종 문장을 쓰는” 역할입니다.

성능 개선 작업

LLM을 더 똑똑하게 쓰는 것보다, 앞단에서 후보를 잘 줄여서(rerank top_n, diversify, plan B 폭주 제어) LLM이 읽을 분량을 줄이는 것이 체감 개선에 더 큽니다.

아직 부족한 점 / 개선

근거팩이 길면 LLM이 중요한 정보를 놓칠 수 있습니다.
- 개선: 근거팩을 “요지/핵심 조항/핵심 문장” 중심으로 더 압축하거나, “조항 섹션”을 항상 최상단에 두는 것이 효과적입니다.

20) Chat Output

목적

최종 응답을 사용자에게 표시합니다.

지금 구조에서 “가장 부족한 점” 5가지 (우선순위)

조항/규정 메타데이터의 커버리지 문제
- DB에 related_law_names 같은 필드가 빈 문서가 많으면, 아무리 라우팅/템플릿을 잘해도 조항이 안 나옵니다.
- chunk_text 안에 실제로 ‘제○조, 제○항, 제○호’ 같은 표현이 존재하면 이를 정규식/휴리스틱으로 추출해서 “조항 섹션”을 채울 예정
플랜 선택(라우팅)의 품질 지표가 단순함
- 건수(0건/1건) 중심 선택은 취약합니다. 품질 기반 선택으로 고도화 필요.
Plan B 폭주(후보 과다) 위험은 줄였지만 ‘질문 유형별 동적 제어’는 아직 약함
- 질문이 “조항 중심”이면 키워드 비중↑, “유사사례”면 벡터 비중↑ 같은 동적 조정이 더 효과적입니다.
Rerank 의존도가 높음
- rerank 전 단계에서 “텍스트 정제/압축”을 더 해야 비용 대비 효율이 좋아집니다.
설명 가능성(왜 이 사례가 선택됐는지) 부족
- 사용자는 ‘왜 이게 후보인지’가 중요합니다. 스코어/매칭 키워드/해당 조항 등장 위치 같은 근거 설명을 자동 생성하면 신뢰도가 상승합니다.
검색 시간 불안정
- 특정 노드에서만 시간이 길게 나는 형태가 아니라 수정할 노드가 불명확함
- 성능 고도화로 갈수록 시간이 더 늘어날 가능성

JERRY

이전 포스트