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

type, tags, status, research_target

type	tags	status	research_target
research	research rag companyx aggregation entity-layer ontology pgvector postgres graph	open	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 집계 레이어 아이디어
• 260320 PGVector·JSONB RAG 스키마 설계 리서치
• 260320 PostgreSQL 그래프확장 설계 리서치
• 260322 Company X RAG 문서 완벽도 평가