--- 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: - PostgreSQL pg_trgm: - pgvector official README: ### 5. Palantir Ontology는 좋은 비유지만 그대로 복제할 필요는 없다 Palantir 공식 문서에서 Ontology는: - 조직의 실제 대상을 나타내는 `objects` - 대상 사이 관계를 나타내는 `links` - 변경/결정을 기록하는 `actions` 를 가진 운영 레이어로 설명된다. 참고: - Ontology overview: - Why create an Ontology: - Link type metadata: - 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)