fix: grounding 용어를 650_용어집에 통합, 별도 01_Terminology 삭제
- 그라운딩, RAG, RRF, pg_trgm 용어 추가 - 중복 파일(01_Terminology/grounding_용어집.md) 삭제 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
8c2c6d0f81
commit
f727f47b28
@ -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) — 검색 워크플로우
|
||||
@ -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 코딩 트렌드로 부상.
|
||||
|
||||
|
||||
99
journey/ideas/260322_companyx_rag_집계레이어_아이디어.md
Normal file
99
journey/ideas/260322_companyx_rag_집계레이어_아이디어.md
Normal file
@ -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)
|
||||
Loading…
x
Reference in New Issue
Block a user