docs: add companyx rag aggregation layer research

journey/research/rag/260322_companyx_rag_집계레이어_구현방안_리서치.md

@@ -0,0 +1,256 @@
+---
+type: research
+tags: [research, rag, companyx, aggregation, entity-layer, ontology, pgvector, postgres, graph]
+status: open
+research_target: Company X RAG 위에 집계/조망 레이어를 어떤 구조로 구현할지 공식 문서와 현재 운영 로그 기준으로 정리
+---
+
+# 260322 Company X RAG 집계 레이어 구현방안 리서치
+
+## 목적
+
+- Company X RAG가 `문서 검색`은 되지만 `전체 목록/개수/비교` 질문에 약한 이유를 구조적으로 정리한다.
+- `팔란티어 Ontology` 같은 전체 조망 레이어를 로빙에 어떻게 축소 구현할지 현실적인 방안을 제안한다.
+
+## Facts
+
+### 1. 현재 실패는 검색 실패가 아니라 집계 실패에 가깝다
+
+- 2026-03-22 실로그 기준, 질문 `컴퍼니엑스가 투자한 회사를 나열해줘.` 는 `companyx_rag` 경로로 정상 진입했다.
+- `skill-rag-file` 로그에는 원문 질의와 변형 질의들이 `mode=hybrid`로 각각 `5 results`를 반환한 기록이 있다.
+- `rb8001` 로그에는 `retrieval_hit_count=20`, `grounding_present=True`가 남았다.
+- 그런데 최종 응답은 `근거를 확인하지 못했습니다`로 떨어졌다.
+
+정리:
+- `문서를 못 찾은 것`이 아니라
+- `찾아온 문서들을 전사 투자사 목록으로 묶어 확정할 구조가 없어서`
+- LLM이 안전하게 실패 응답을 선택한 것이다.
+
+### 2. 현재 회수 문서는 개별 사실 문서다
+
+같은 로그에서 상위 hit는 다음 계열이었다.
+
+- `2025 투자내역_컴퍼니엑스 IP 투자조합 6호.pdf`
+- `투자회수실적_운용사2_(주)컴퍼니엑스.xlsx`
+- `투자거래관리_컴퍼니엑스_250804.xlsx`
+- `주요투자조건 및 투자계약서(RCPS).pdf`
+
+이 문서들은 `개별 투자 사실`이나 `조합 단위 내역`에는 유용하지만, `컴퍼니엑스가 투자한 회사 전체 목록`이라는 질문을 닫아주는 단일 SSOT는 아니다.
+
+### 3. 현재 RAG 구조는 청크 중심이다
+
+- 현재 운영 구조는 `문서 -> 청크 -> vector/keyword/hybrid search -> grounding`이다.
+- 이 구조는 `한 문서 안에 답이 있는 질문`에는 강하다.
+- 하지만 `여러 문서에 흩어진 동일 엔티티를 dedup하고 집계하는 질문`에는 약하다.
+
+### 4. PostgreSQL/pgvector 공식 문서도 하이브리드 검색까지만 직접 다룬다
+
+- PostgreSQL FTS 문서는 `tsvector/tsquery/rank`와 prefix 매칭을 제공하지만, 전사 집계나 엔티티 통합은 별도 계층 문제다.
+- `pg_trgm`은 부분 일치 보완에 유용하다.
+- `pgvector` 공식 README도 hybrid search에서 `full-text search와 함께 쓰고 RRF나 reranking으로 결합`하라고 설명하지만, 이것도 `검색 강화`이지 `집계 모델` 자체를 대신하지는 않는다.
+
+참고:
+- PostgreSQL text search controls: <https://www.postgresql.org/docs/current/textsearch-controls.html>
+- PostgreSQL pg_trgm: <https://www.postgresql.org/docs/current/pgtrgm.html>
+- pgvector official README: <https://github.com/pgvector/pgvector>
+
+### 5. Palantir Ontology는 좋은 비유지만 그대로 복제할 필요는 없다
+
+Palantir 공식 문서에서 Ontology는:
+- 조직의 실제 대상을 나타내는 `objects`
+- 대상 사이 관계를 나타내는 `links`
+- 변경/결정을 기록하는 `actions`
+를 가진 운영 레이어로 설명된다.
+
+참고:
+- Ontology overview: <https://www.palantir.com/docs/foundry/ontology/overview>
+- Why create an Ontology: <https://www.palantir.com/docs/foundry/ontology/why-ontology>
+- Link type metadata: <https://www.palantir.com/docs/foundry/object-link-types/link-type-metadata>
+- Action types overview: <https://www.palantir.com/docs/foundry/action-types/overview/>
+
+이 관점은 맞다. 다만 로빙은 지금 `거대한 플랫폼형 ontology`보다 `Company X 핵심 질문을 풀기 위한 소형 집계 레이어`가 더 현실적이다.
+
+## Interpretation
+
+### 1. 지금 필요한 것은 검색 엔진 고도화만이 아니다
+
+- `keyword`, `pg_trgm`, `형태소 분석`, `reranking`은 모두 검색 품질을 높인다.
+- 하지만 투자사 목록 질문은 검색이 좋아져도 마지막에 `같은 회사를 여러 문서에서 하나로 묶고`, `기준일을 맞추고`, `전체 확정 가능 여부를 판단`해야 한다.
+- 따라서 `검색 강화`와 별도로 `엔티티/팩트/집계 레이어`가 필요하다.
+
+### 2. 가장 현실적인 구현은 “소형 Ontology 레이어”다
+
+거대한 재설계보다 아래 3층이 맞다.
+
+1. `entity`
+- 회사, 투자조합, 프로그램, 문서유형
+
+2. `fact`
+- 어떤 회사가 어떤 조합/문서에서 어떤 사실로 확인됐는지
+
+3. `aggregate`
+- 질문 유형별로 fact를 dedup/집계해서 답변용 결과를 만든다
+
+즉 `문서 청크 레이어` 위에 `정규화된 사실 레이어`를 한 층 올리는 방식이다.
+
+### 3. 그래프는 보조 수단이고, 첫 번째 핵심은 fact table이다
+
+- 현재 AGE 그래프는 `문서-문서 관계 확장`에는 좋다.
+- 하지만 `투자사 목록` 질문은 먼저 `companyx_investee_fact` 같은 테이블이 있어야 풀린다.
+- 그래프는 이후 `회사 ↔ 조합 ↔ 문서` 연결을 더 풍부하게 하거나 탐색 설명을 붙이는 데 쓰는 편이 맞다.
+
+즉 우선순위는:
+1. fact table
+2. 집계 쿼리
+3. 필요 시 graph overlay
+
+### 4. 답변 계약도 바뀌어야 한다
+
+현재는 자주 이렇게 끝난다.
+- `문서가 없거나 찾지 못했습니다`
+
+집계 레이어가 생기면 이런 답이 가능해진다.
+- `현재 내부 문서 기준으로 투자 사실이 직접 확인되는 회사는 A, B, C입니다.`
+- `근거 문서: 투자내역, 투자계약서, 투자회수실적`
+- `다만 최신 전사 투자사 마스터 문서가 없어 전체 확정 목록이라고 단정할 수는 없습니다.`
+
+즉 목표는 `정답/오답` 이분법이 아니라:
+- 부분 집계 가능
+- 전체 확정 불가
+- 근거 문서 동반
+형태로 바뀌어야 한다.
+
+## 구현 후보 비교
+
+### A. 청크 검색만 유지
+
+- 장점: 구현 추가가 적다
+- 단점: 지금 한계를 그대로 유지한다
+- 판단: 불충분
+
+### B. 문서 메타만 강화
+
+- 장점: MD/front matter 재사용 가능
+- 단점: 투자사명 dedup, 조합-회사 관계, 기준일 판정까지는 어렵다
+- 판단: 보조 수단
+
+### C. 엔티티/팩트 테이블 추가
+
+- 장점: 목록/개수/비교형 질문에 직접 대응 가능
+- 단점: 추출 규칙과 정규화 비용 필요
+- 판단: 가장 현실적인 1차 목표
+
+### D. Palantir식 full ontology + actions까지 구현
+
+- 장점: 장기적으로 강력하다
+- 단점: 지금 범위에 비해 무겁다
+- 판단: 지금은 과하다
+
+## 내가 추천하는 최소 구현안
+
+### 1. 투자 문서군만 먼저 분리
+
+대상:
+- 투자내역
+- 투자거래관리
+- 투자회수실적
+- 투자계약서/주요투자조건
+- 조합 관련 문서
+
+### 2. fact 테이블 추가
+
+예시:
+
+`companyx_investee_fact`
+
+- `id`
+- `team_id`
+- `company_name`
+- `fund_name`
+- `fact_type` (`invested`, `exited`, `mentioned`)
+- `as_of_date`
+- `source_document_id`
+- `source_chunk_id`
+- `source_filename`
+- `confidence`
+- `normalized_company_key`
+- `metadata_jsonb`
+
+### 3. document-entity link 보조 테이블
+
+예시:
+
+`companyx_document_entity_link`
+
+- `document_id`
+- `entity_type`
+- `entity_name`
+- `normalized_key`
+- `evidence_span`
+
+### 4. 집계형 질문 라우팅 추가
+
+아래 질문은 일반 grounding 전에 집계 경로로 분기한다.
+
+- `나열해줘`
+- `몇 개야`
+- `전체`
+- `주요`
+- `비교해줘`
+
+흐름:
+1. 질문 분류
+2. fact 조회
+3. company_name dedup
+4. 근거 문서 연결
+5. 전체 확정 가능 여부 판단
+6. 답변 생성
+
+### 5. graph는 2차로 연결
+
+AGE에는 이후 이런 식으로 올리면 된다.
+
+- `Company`
+- `Fund`
+- `Document`
+- `Program`
+
+links:
+- `INVESTED_BY`
+- `MENTIONED_IN`
+- `RELATED_TO`
+
+하지만 첫 번째 성공 기준은 `graph 구축`이 아니라 `투자사 목록 질문에 답하기`다.
+
+## 답변 가능 상태로 바뀌는 기준
+
+현재:
+- 검색은 성공
+- 집계는 실패
+
+목표:
+- `투자 사실이 확인되는 회사 목록`을 부분 집계로라도 낼 수 있음
+- 각 회사마다 최소 1개 근거 문서가 붙음
+- 최신 전사 마스터 부재 시 `전체 확정 불가`를 명시함
+
+이 기준을 만족하면 질문 `컴퍼니엑스가 투자한 회사를 나열해줘`는 `실패 응답`에서 `제한부 성공 응답`으로 바뀐다.
+
+## Unresolved
+
+- 회사명 정규화 규칙을 어디까지 자동화할지 미정이다.
+- `투자`와 `회수`와 `단순 언급`을 어떤 confidence 규칙으로 나눌지 미정이다.
+- 집계 레이어를 별도 테이블로 둘지, 기존 `team_document_chunk.metadata`를 확장할지 확정되지 않았다.
+- 전사 투자사 마스터 문서가 실제로 존재하는지 아직 모른다.
+
+## 내 판단
+
+- 네, `전체 조망 레이어`는 필요하다.
+- 다만 지금 필요한 것은 `팔란티어처럼 거대한 플랫폼`이 아니라 `Company X 질문을 풀어주는 소형 ontology/fact 레이어`다.
+- 첫 구현 목표는 `투자사 목록 질문 하나를 제한부 성공으로 바꾸는 것`이어야 한다.
+
+## 관련 문서
+
+- [260322 Company X RAG 집계 레이어 아이디어](../../ideas/260322_companyx_rag_집계레이어_아이디어.md)
+- [260320 PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md)
+- [260320 PostgreSQL 그래프확장 설계 리서치](./260320_PostgreSQL_그래프확장_설계_리서치.md)
+- [260322 Company X RAG 문서 완벽도 평가](../../../valuation/260322_companyx_rag_문서_완벽도_평가.md)