diff --git a/journey/research/rag/260322_companyx_rag_집계레이어_구현방안_리서치.md b/journey/research/rag/260322_companyx_rag_집계레이어_구현방안_리서치.md new file mode 100644 index 0000000..fe4f3e4 --- /dev/null +++ b/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: +- 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)