happybell80
f727f47b28
- 그라운딩, RAG, RRF, pg_trgm 용어 추가 - 중복 파일(01_Terminology/grounding_용어집.md) 삭제 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
100 lines
5.5 KiB
Markdown
100 lines
5.5 KiB
Markdown
---
|
|
tags: [ideas, companyx, rag, aggregation, entity-layer, grounding]
|
|
type: 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_파이프라인_아이디어.md)
|
|
- [260320 다형식문서 RAG 2차 PGVector·JSONB 적재 계획](../plans/260320_다형식문서_RAG_2차_PGVector_JSONB_적재_계획.md)
|
|
- [260320 PostgreSQL 그래프확장 설계 리서치](../research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md)
|
|
- [260322 Company X RAG 문서 완벽도 평가](../../valuation/260322_companyx_rag_문서_완벽도_평가.md)
|