---
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)
