diff --git a/01_Terminology/grounding_용어집.md b/01_Terminology/grounding_용어집.md deleted file mode 100644 index 58924e4..0000000 --- a/01_Terminology/grounding_용어집.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -type: governance -tags: [terminology, grounding, rag, companyx] -created_date: 2026-03-23 -last_verified: 2026-03-23 -scope: robeing 프로젝트 전체 -upper_principle: /home/admin/0_VALUE/00_Foundations/global-principles.md ---- - -# Grounding 용어집 - -## Grounding (근거 기반 답변) - -LLM이 답변할 때 **내부 문서에서 근거를 찾아 명시**하는 프로세스. 추측이나 외부 지식이 아니라 검색된 문서 내용만을 근거로 답변하고, 어떤 문서가 근거인지 함께 제시한다. 근거가 부족하면 "모른다"고 명시한다. - -## RAG (Retrieval-Augmented Generation) - -검색(Retrieval) + 생성(Generation)을 결합한 구조. 먼저 관련 문서를 검색하고, 검색 결과를 LLM 컨텍스트에 넣어 답변을 생성한다. Grounding은 RAG의 출력 원칙이다. - -## 하이브리드 검색 (Hybrid Search) - -여러 검색 방식을 결합하여 결과를 합산하는 검색 구조. - -로빙의 현재 하이브리드 검색 축: -- **벡터 검색** (pgvector): 의미 유사도 기반 -- **키워드 검색** (tsvector + pg_trgm): 텍스트 매칭 기반 -- **파일명 검색** (ILIKE): 파일명 토큰 매칭 -- **그래프 검색** (Apache AGE): 문서 관계 기반 - -## RRF (Reciprocal Rank Fusion) - -여러 검색 결과의 순위를 합산하는 알고리즘. `score = 1/(k + rank)`. 로빙에서는 벡터·키워드·파일명·그래프 결과를 RRF로 합산 후 0~1 정규화. - -## CompanyXRAGOutput - -grounding 응답의 Pydantic 검증 모델. - -| 필드 | 설명 | -|------|------| -| `direct_answer` | 1~3문장 답변. 근거 부족 시 빈 문자열 | -| `evidence_docs` | 근거 문서 파일명 목록 | -| `failure_reason` | 답변 불가 사유. 정상이면 null | - -## Grounding 경로 진입 조건 - -| 조건 | 설명 | -|------|------| -| `team_id == COMPANYX_TEAM_ID` | Company X 팀 사용자면 자동 진입 | -| 검색 결과 0건 | failure 응답 반환 후 일반 경로로 fallback | - -## 질문 유형 (Question Types) - -| 유형 | 트리거 | 예시 | -|------|--------|------| -| `fact_check` | 기본값 | "근거 있어?", "협력 관계야?" | -| `explanatory` | "뭐야?", "설명해줘" | "X-COURSE가 뭐야?" | -| `quantitative` | "몇 개야?", "얼마나?" | "투자사 몇 개야?" | -| `recap` | "다시 정리해줘" | "근거 문서명만 다시" | - -## 관련 문서 - -- [Company X Grounding 파이프라인](../workflow/03_rag/companyx_grounding_pipeline.md) — 워크플로우 -- [companyx-rag SKILL.md](../skills/companyx-rag/SKILL.md) — 스킬 계약 -- [RAG 검색·Grounding 요청](../workflow/03_rag/rag_search_grounding_request.md) — 검색 워크플로우 diff --git a/book/600_appendix/650_용어집.md b/book/600_appendix/650_용어집.md index 12c5714..c9e2c13 100644 --- a/book/600_appendix/650_용어집.md +++ b/book/600_appendix/650_용어집.md @@ -19,6 +19,12 @@ LLM 출력을 후처리하여 로빙의 고유한 성격과 윤리적 기준을 ### 경험치 (Experience Points, XP) 로빙이 작업을 수행하거나 사용자와 상호작용할 때 획득하는 포인트. 일정량 누적 시 레벨업이 발생함. +### 그라운딩 (Grounding) +LLM이 답변할 때 내부 문서에서 근거를 찾아 명시하는 프로세스. 추측이나 외부 지식이 아니라 검색된 문서 내용만을 근거로 답변하고, 어떤 문서가 근거인지 함께 제시한다. 근거가 부족하면 "모른다"고 명시한다. RAG의 출력 원칙. +관련 문서: +- [Company X Grounding 파이프라인](../../workflow/03_rag/companyx_grounding_pipeline.md) +- [companyx-rag SKILL.md](../../skills/companyx-rag/SKILL.md) + ### 공통 계약 (Common Contract) 특정 기능 경로가 따라야 하는 공통 `입력-판단-출력` 약속. 질문별 예외 문장을 계속 추가하는 대신, 질문 유형 분류, 근거 채택 기준, 실패 조건 같은 규칙을 한 번 정의해 코드·프롬프트·테스트가 함께 따르도록 고정한 기준을 뜻한다. 관련 문서: @@ -195,9 +201,20 @@ GPT-4 등의 대규모 언어 모델. 로빙의 자연어 이해와 생성을 ### NLP (Natural Language Processing) 자연어 처리. 인간의 언어를 컴퓨터가 이해하고 처리하는 기술. +### pg_trgm +PostgreSQL 확장. 텍스트를 3글자(trigram) 단위로 쪼개 인덱싱하여 부분 문자열 매칭을 지원한다. 형태소 분석 없이 한국어 조사/복합어 문제를 보완하는 키워드 검색 축. + ### PoC (Proof of Concept) 개념 증명. 아이디어의 실현 가능성을 검증하기 위한 프로토타입. +### RAG (Retrieval-Augmented Generation) +검색(Retrieval) + 생성(Generation) 결합 구조. 먼저 관련 문서를 검색하고, 검색 결과를 LLM 컨텍스트에 넣어 답변을 생성한다. 로빙의 Company X 내부 문서 답변에 사용. +관련 문서: +- [RAG 검색·Grounding 요청](../../workflow/03_rag/rag_search_grounding_request.md) + +### RRF (Reciprocal Rank Fusion) +여러 검색 결과의 순위를 합산하는 알고리즘. `score = 1/(k + rank)`. 로빙에서는 벡터·키워드·파일명·그래프 결과를 RRF로 합산 후 0~1 정규화. + ### Ralph Loop (랄프 루프) AI가 완성 기준 충족 시까지 코드 작성·테스트·수정을 자동 반복하는 기법. 2026년 AI 코딩 트렌드로 부상. diff --git a/journey/ideas/260322_companyx_rag_집계레이어_아이디어.md b/journey/ideas/260322_companyx_rag_집계레이어_아이디어.md new file mode 100644 index 0000000..b68f210 --- /dev/null +++ b/journey/ideas/260322_companyx_rag_집계레이어_아이디어.md @@ -0,0 +1,99 @@ +--- +tags: [ideas, companyx, rag, aggregation, entity-layer, grounding] +type: ideas +--- + +# 260322 Company X RAG 집계 레이어 아이디어 + +## 목적 + +- Company X RAG가 `문서 검색`은 되지만 `전체 조망·집계형 질문`에는 약한 이유를 정리한다. +- 청크 기반 검색 위에 어떤 집계 레이어가 있어야 `투자사 목록`, `전체 개수`, `프로그램 전체 구조` 같은 질문에 답할 수 있는지 방향을 연다. + +## 문제 인식 + +- 현재 RAG는 `문서 청크 회수 -> 근거 답변`에는 강하지만, 여러 문서에 흩어진 사실을 하나의 목록이나 집계로 묶는 데는 약하다. +- 예를 들어 `컴퍼니엑스가 투자한 회사를 나열해줘` 질문에서 검색은 성공해도, 결과 문서가 `투자내역`, `계약서`, `투자회수실적`, `거래관리`처럼 분산돼 있으면 LLM은 전체를 단정하지 못한다. +- 즉 현재 병목은 `검색 0건`보다 `검색 결과를 전사 관점으로 합쳐서 답할 구조 부재`에 가깝다. + +## 현재 상태 요약 + +- 24 서버 기준 `skill-rag-file` 하이브리드 검색과 `rb8001` grounding은 동작한다. +- `vector + keyword + graph` 검색으로 관련 문서는 가져오지만, 그 결과를 `엔티티`, `관계`, `기준일`, `확정성` 단위로 재구성하는 계층은 없다. +- 그래서 `계약서가 있는 회사`, `조합 투자내역에 나온 회사`, `회수실적에 나온 회사`를 하나의 `투자사 목록`으로 dedup·정규화하지 못한다. + +## 왜 집계 레이어가 필요한가 + +- `나열해줘`, `몇 개야`, `전체`, `주요`, `비교해줘` 같은 질문은 청크 답변보다 집계 답변에 가깝다. +- 이런 질문은 문서 1개를 읽어 답하는 게 아니라, 여러 문서에서 같은 대상을 찾아 묶고 중복을 제거하고 기준일을 맞춰야 한다. +- 따라서 문서 검색 위에 `엔티티/팩트/집계`를 다루는 레이어가 없으면, RAG는 계속 `근거는 일부 있으나 전체 단정 불가`로 멈춘다. + +## 내가 생각하는 최소 집계 레이어 + +### 1. 엔티티 추출 + +- 문서/청크에서 `투자사명`, `투자조합`, `문서유형`, `거래유형`, `기준일`을 뽑는다. +- 예: + - `회사명`: 아크로셀 + - `조합`: 컴퍼니엑스 IP 투자조합 6호 + - `문서유형`: 투자내역 / 투자계약서 / 회수실적 + - `기준일`: 2025-12-31 + +### 2. 팩트 정규화 + +- 추출한 값을 문서 청크와 별도로 `정규화 테이블`에 저장한다. +- 예시 테이블: + - `companyx_investee_fact` + - `companyx_program_fact` + - `companyx_document_entity_link` + +### 3. 집계 질의 경로 + +- `투자한 회사 나열`, `전체 투자사 수`, `주요 프로그램 목록` 같은 질문은 일반 grounding 전에 집계 질의로 분기한다. +- 이 경로는 청크를 바로 LLM에 주지 않고: + 1. 관련 fact 조회 + 2. 회사명 dedup + 3. 문서 근거 1개 이상 연결 + 4. 전체 확정 가능 여부 판단 + 순서로 답한다. + +## 답변 형식도 바뀌어야 한다 + +- 현재는 `문서가 없거나 찾지 못함`으로 많이 떨어진다. +- 집계 레이어가 생기면 아래처럼 답할 수 있다: + - `현재 내부 문서 기준으로 투자 사실이 직접 확인되는 회사는 A, B, C입니다.` + - `근거 문서: 투자내역, 투자계약서, 투자회수실적` + - `다만 전사 최신 투자사 마스터 문서는 없어 전체 확정 목록이라고 단정할 수는 없습니다.` + +## 팔란티어처럼 가야 하나 + +- 방향성은 비슷하다. `문서 -> 엔티티 -> 관계 -> 조망`으로 올라가야 한다. +- 다만 지금 단계에서 필요한 것은 거대한 플랫폼이 아니라, Company X 질문에 바로 효율이 나는 `소형 집계 레이어`다. +- 즉 `문서 레이크 전체 재설계`보다 `투자/프로그램/조직` 같은 핵심 주제부터 정규화하는 게 현실적이다. + +## 이 문서가 제안하는 시작 순서 + +1. `투자` 문서군만 별도 분류한다. +2. 투자사명/조합명/문서유형/기준일 추출 규칙을 정한다. +3. `companyx_investee_fact` 같은 테이블에 적재한다. +4. `나열/집계형 질문`을 이 fact 테이블 우선 조회로 분기한다. +5. 답변에 `부분 집계`와 `전체 확정 불가`를 구분해 넣는다. + +## 기대 효과 + +- `투자한 회사 나열해줘` 같은 질문에 부분 목록이라도 안정적으로 답할 수 있다. +- `문서 검색은 됐는데 왜 전체 답을 못 하느냐`는 현재 한계를 구조적으로 줄일 수 있다. +- 이후 `프로그램 목록`, `협력 네트워크`, `팀 구조` 같은 조망형 질문에도 같은 레이어를 재사용할 수 있다. + +## 검증이 필요한 이유 + +- 엔티티 추출 정확도가 낮으면 오히려 잘못된 집계가 생긴다. +- `부분 목록`과 `전체 확정 목록`을 섞으면 신뢰를 잃는다. +- 따라서 이 아이디어는 바로 일반화하지 말고, 먼저 `투자사 목록` 질문 하나로 좁혀 검증하는 편이 맞다. + +## 관련 문서 + +- [260320 다형식문서 자동지식화 RAG 파이프라인 아이디어](./260320_다형식문서_자동지식화_RAG_파이프라인_아이디어.md) +- [260320 다형식문서 RAG 2차 PGVector·JSONB 적재 계획](../plans/260320_다형식문서_RAG_2차_PGVector_JSONB_적재_계획.md) +- [260320 PostgreSQL 그래프확장 설계 리서치](../research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md) +- [260322 Company X RAG 문서 완벽도 평가](../../valuation/260322_companyx_rag_문서_완벽도_평가.md)