1. 프로젝트 목표와 범위
1.1 목표 기능 2가지
1. RAG 감사사례 검색
- 사용자 질문에 대해 유사 감사사례를 검색하고
- 문서 근거(problem/action/criteria/관련 법령)를 바탕으로 처분 수준(권고/징계/환수 등)을 추천하는 기능
2. 감사보고서 초안작성
- 특정 양식(템플릿)을 따라 초안을 생성하고
- 유사사례 + 내규/정책(policy) + 법령(law)을 근거로 논리적 보고서 형태로 작성
1.2 ‘검색’과 ‘보고서’를 분리(4-B/4-C)
- 검색(Search)은 “질문 → 유사사례 근거 → 결론”이 핵심이라 case 중심 retrieval만으로도 MVP가 가능
- 보고서(Report)는 “case/policy/law 3갈래 증거를 조합해 구조화된 문서”가 필요하므로, 적재가 완성된 뒤 4-C로 확장하는 전략
2. 데이터 소스/적재 계획
- 알리오(ALIO) PDF: 공공기관 감사결과/보고서류
- 감사원 PDF: 감사원 감사결과/처분 관련 자료
- 법령/규정 문서
3. Neo4j 관계(키) 설계
3.1 노드/관계
- (:Document {doc_code, title, site, category, audit_start_date, audit_end_date, ...})
- (:Case {sub_code, doc_code, sub_order, sub_title, keyword_list, problem, action, action_type, criteria, related_laws, fiscal_amount, ...})
- (:Chunk {chunk_id, sub_code, doc_code, text_ft, embedding, ...})
- 관계 : (:Document)-[:HAS_CASE]->(:Case)-[:HAS_CHUNK]->(:Chunk)
- 업무 단위가 사례(Case)인 경우가 많고, 검색도 사례 단위 근거 묶음이 자연스럽습니다.
- Chunk는 검색 인덱싱/근거 패킹을 위해 존재하므로 Case에 종속시키는 게 관리가 쉽습니다.
- doc_code/sub_code가 명확하면 보고서(Report) 단계에서 case/policy/law를 분리해도 같은 패턴으로 확장 가능합니다.
키(식별자) 설계
- Document.doc_code는 문서 유니크 키
- Case.sub_code는 문서+사례순번 조합으로 유니크 키
- Postgres vdb_chunks.id ↔ Neo4j Chunk.chunk_id 1:1 매칭
- Neo4j는 후보 chunk_id만 뽑아도 Postgres에서 원문을 정확히 재구성 가능
- “dedupe 기준(문서/사례/청크)”이 명확해져 랭킹 및 근거 출력이 안정화
인덱스
- Vector index:
- Chunk(embedding)
- 사용자의 질문이 문서 표현과 단어가 정확히 일치하지 않아도 의미적으로 가까운 Chunk를 찾기 위한 인덱스
- 예: “병가 중 해외여행” ↔ 문서에는 “병가기간 중 국외 체류”처럼 표현될 수 있음
→ 키워드 매칭만으로는 놓치므로 벡터 유사도가 필요
- Fulltext index:
- Chunk(text_ft) 또는 헤더 포함 텍스트 필드
- 감사 문서에는 고유명사/기관명/규정명/조문/정확한 숫자가 많아서 벡터 검색만으로는 정확히 같은 표현을 잡기 어려운 경우가 있는데 Fulltext(BM25류)는 이런 정확 매칭/부분 매칭에 강함
- Uniqueness constraint
- Chunk.chunk_id, Document.doc_code, Case.sub_code
- Uniqueness constraint는 단순히 중복 방지가 아니라, ETL 재실행/증분 적재/재처리 시 정합성을 보장
4. Flow(A/B) 상세 설명
4.1 4-A 공통: 입력 → 정규화 → 분기
(1) Chat Input
- 사용자 자연어 질문 수신 (Message)
(2) Slot & Intent Extractor (커스텀)
- 목적: 질문을 표준 스키마로 정규화
- 출력(모두 Message):
- Route: search/report
- Slots JSON: 추출된 조직/기간/위반유형/키워드 등
- Normalized Query: Rerank/검색 품질 향상을 위한 정규화 질문
(3) Route Switch (커스텀)
- Route에 따라 질문을 두 갈래로 분기
- Search Question
- Report Question
4.2 4-B 검색(Search) 플로우: “유사사례 검색 + 처분수준 추천”
(4) MultiQuery Generator (커스텀)
- 입력: Search Question + Slots JSON + LLM(handle)
- 출력: Queries(DataFrame)
- 목적: 단일 질문을 여러 표현으로 확장해 검색 recall을 올림
(5) Neo4j Hybrid Retriever (커스텀)
- 입력: Queries(DataFrame) + Embeddings(handle) + Neo4j 접속정보 + 인덱스명
- 처리:
- fulltext(BM25) + vector(similarity) 결합(하이브리드)
- 후보 chunk_id 생성
- 출력: Candidates(DataFrame)
- 최소 필드: chunk_id (Postgres id와 매칭될 값)
- 추가로 score 등 포함 가능
(6) Postgres Chunk Fetcher (커스텀)
- 입력: Candidates(DataFrame) + Postgres DSN + 테이블/컬럼명
- DSN: postgresql://n8n:n8nthankyou@59.21.250.129:47147/n8n
- table: public.vdb_chunks
- id_column: id
- text_column: chunk
- metadata_column: metadata
- candidate_id_field: chunk_id
- 처리: Candidates의 chunk_id 리스트로 vdb_chunks.id 조회 → chunk/metadata 붙임
- 출력: Candidates+Text(DataFrame)
(4) ReRanker (커스텀)
- 입력: Candidates+Text(DataFrame) + User Question(Message) + OpenAI ReRank API
- 처리: 후보 문서들을 재정렬하여 TopK를 더 정확하게 만듦
- 출력: ReRanked Documents(DataFrame)
- rerank_score 포함
(5) Evidence Pack Builder (커스텀)
- 입력: ReRanked Documents(DataFrame)
- 처리: 상위 K개의 핵심 근거를 LLM 입력용으로 묶음
- 출력: Evidence(Message)
(6) Prompt Template + OpenAI(ChatModel)
- Prompt는 다음을 포함:
- 사용자 질문
- retrieved_docs(Evidence)
- slots_json(정규화 JSON)
- 출력: 최종 답변(검색 결과 요약 + 근거 기반 결론)
4.3 기능 추가 순서와 기대 효과
-
v1 : 단일 질의 + 검색 모드 토글 (hybrid / vector_only / fulltext_only)
- 검색 방식 자체의 베이스라인 비교
- vector_only: 의미 기반(semantic) 유사도 중심
- fulltext_only: 키워드/구문 기반(lexical) 중심
- hybrid: 둘을 합쳐 후보를 넓힌 뒤 점수로 병합/정렬
-
V2 : V1(hybrid 고정) + MultiQuery
- 한 번의 질문을 여러 관점의 쿼리로 확장해서 검색 리콜(recall)을 올림
-
V3 : V2 + ReRanker
- Retriever가 넓게 가져온 후보를, LLM 기반 ReRank로 질문 적합도 순으로 재정렬
-
V4 : V3 + Evidence Pack Builder
- 최종 답변에 들어갈 근거를 정규 포맷(인용/메타데이터/요약 텍스트)으로 묶어 프롬프트에 근거 블록을 안정적으로 주입
5. 다음 단계(4-C Report 확장 계획)
- Neo4j 그래프 스키마(문서–사례–청크) + 키/인덱스/제약 확정 및 적용
- DB 적재 완료 후 A/B(Search) 플로우 “실데이터 end-to-end” 검증
- 4-C(Report) 붙이기 위한 데이터 준비도 점검 후 Agent 구축
