DOCS/journey/ideas/260322_companyx_rag_집계레이어_아이디어.md

tags, type

tags	type
ideas companyx rag aggregation entity-layer grounding	ideas

260322 Company X RAG 집계 레이어 아이디어

목적

• Company X RAG가 문서 검색은 되지만 전체 조망·집계형 질문에는 약한 이유를 정리한다.
• 청크 기반 검색 위에 어떤 집계 레이어가 있어야 투자사 목록, 전체 개수, 프로그램 전체 구조 같은 질문에 답할 수 있는지 방향을 연다.

문제 인식

• 현재 RAG는 문서 청크 회수 -> 근거 답변에는 강하지만, 여러 문서에 흩어진 사실을 하나의 목록이나 집계로 묶는 데는 약하다.
• 예를 들어 컴퍼니엑스가 투자한 회사를 나열해줘 질문에서 검색은 성공해도, 결과 문서가 투자내역, 계약서, 투자회수실적, 거래관리처럼 분산돼 있으면 LLM은 전체를 단정하지 못한다.
• 즉 현재 병목은 검색 0건보다 검색 결과를 전사 관점으로 합쳐서 답할 구조 부재에 가깝다.

현재 상태 요약

• 24 서버 기준 skill-rag-file 하이브리드 검색과 rb8001 grounding은 동작한다.
• vector + keyword + graph 검색으로 관련 문서는 가져오지만, 그 결과를 엔티티, 관계, 기준일, 확정성 단위로 재구성하는 계층은 없다.
• 그래서 계약서가 있는 회사, 조합 투자내역에 나온 회사, 회수실적에 나온 회사를 하나의 투자사 목록으로 dedup·정규화하지 못한다.

왜 집계 레이어가 필요한가

• 나열해줘, 몇 개야, 전체, 주요, 비교해줘 같은 질문은 청크 답변보다 집계 답변에 가깝다.
• 이런 질문은 문서 1개를 읽어 답하는 게 아니라, 여러 문서에서 같은 대상을 찾아 묶고 중복을 제거하고 기준일을 맞춰야 한다.
• 따라서 문서 검색 위에 엔티티/팩트/집계를 다루는 레이어가 없으면, RAG는 계속 근거는 일부 있으나 전체 단정 불가로 멈춘다.

내가 생각하는 최소 집계 레이어

1. 엔티티 추출

• 문서/청크에서 투자사명, 투자조합, 문서유형, 거래유형, 기준일을 뽑는다.
• 예:
  • 회사명: 아크로셀
  • 조합: 컴퍼니엑스 IP 투자조합 6호
  • 문서유형: 투자내역 / 투자계약서 / 회수실적
  • 기준일: 2025-12-31

2. 팩트 정규화

• 추출한 값을 문서 청크와 별도로 정규화 테이블에 저장한다.
• 예시 테이블:
  • companyx_investee_fact
  • companyx_program_fact
  • companyx_document_entity_link

3. 집계 질의 경로

• 투자한 회사 나열, 전체 투자사 수, 주요 프로그램 목록 같은 질문은 일반 grounding 전에 집계 질의로 분기한다.
• 이 경로는 청크를 바로 LLM에 주지 않고:
  1. 관련 fact 조회
  2. 회사명 dedup
  3. 문서 근거 1개 이상 연결
  4. 전체 확정 가능 여부 판단 순서로 답한다.

답변 형식도 바뀌어야 한다

• 현재는 문서가 없거나 찾지 못함으로 많이 떨어진다.
• 집계 레이어가 생기면 아래처럼 답할 수 있다:
  • 현재 내부 문서 기준으로 투자 사실이 직접 확인되는 회사는 A, B, C입니다.
  • 근거 문서: 투자내역, 투자계약서, 투자회수실적
  • 다만 전사 최신 투자사 마스터 문서는 없어 전체 확정 목록이라고 단정할 수는 없습니다.

팔란티어처럼 가야 하나

• 방향성은 비슷하다. 문서 -> 엔티티 -> 관계 -> 조망으로 올라가야 한다.
• 다만 지금 단계에서 필요한 것은 거대한 플랫폼이 아니라, Company X 질문에 바로 효율이 나는 소형 집계 레이어다.
• 즉 문서 레이크 전체 재설계보다 투자/프로그램/조직 같은 핵심 주제부터 정규화하는 게 현실적이다.

이 문서가 제안하는 시작 순서

1. 투자 문서군만 별도 분류한다.
2. 투자사명/조합명/문서유형/기준일 추출 규칙을 정한다.
3. companyx_investee_fact 같은 테이블에 적재한다.
4. 나열/집계형 질문을 이 fact 테이블 우선 조회로 분기한다.
5. 답변에 부분 집계와 전체 확정 불가를 구분해 넣는다.

기대 효과

• 투자한 회사 나열해줘 같은 질문에 부분 목록이라도 안정적으로 답할 수 있다.
• 문서 검색은 됐는데 왜 전체 답을 못 하느냐는 현재 한계를 구조적으로 줄일 수 있다.
• 이후 프로그램 목록, 협력 네트워크, 팀 구조 같은 조망형 질문에도 같은 레이어를 재사용할 수 있다.

검증이 필요한 이유

• 엔티티 추출 정확도가 낮으면 오히려 잘못된 집계가 생긴다.
• 부분 목록과 전체 확정 목록을 섞으면 신뢰를 잃는다.
• 따라서 이 아이디어는 바로 일반화하지 말고, 먼저 투자사 목록 질문 하나로 좁혀 검증하는 편이 맞다.

관련 문서

• 260320 다형식문서 자동지식화 RAG 파이프라인 아이디어
• 260320 다형식문서 RAG 2차 PGVector·JSONB 적재 계획
• 260320 PostgreSQL 그래프확장 설계 리서치
• 260322 Company X RAG 문서 완벽도 평가