docs: sync companyx rag open docs with runtime state
This commit is contained in:
parent
741ce44360
commit
47057380a8
@ -2,6 +2,7 @@
|
||||
tags: [robeing, idea, rag, multimodal, markdown, pgvector, postgres]
|
||||
type: ideas
|
||||
status: open
|
||||
adopted_by: 260320_다형식문서_RAG_1차_MD_메타_정규화_계획.md, 260320_다형식문서_RAG_2차_PGVector_JSONB_적재_계획.md, 260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md
|
||||
---
|
||||
|
||||
# 260320 다형식문서 자동지식화 RAG 파이프라인 아이디어
|
||||
@ -28,6 +29,12 @@ status: open
|
||||
- PGVector는 의미 검색을 맡고, PostgreSQL 관계 구조는 연결 탐색을 맡는다.
|
||||
- 이 구조는 지금 로빙의 범위에서 과하지 않고, 나중에 더 크게 키워도 버티는 방향이다.
|
||||
|
||||
## 현재 반영 상태 (2026-03-22)
|
||||
|
||||
- `로빙 적용 1`은 별도 계획에서 이미 구현·검증이 끝났고, 현재 열린 체인은 `1차/2차/3차`와 관련 리서치다.
|
||||
- `PGVector + JSONB + tsvector + Apache AGE` 방향은 설계가 아니라 현재 운영 코드와 문서가 함께 따라가야 하는 실제 기준이 됐다.
|
||||
- 따라서 이 아이디어 문서는 신규 구상보다 `왜 이 구조를 유지하는가`를 설명하는 상위 맥락 문서로 읽는 편이 맞다.
|
||||
|
||||
## 단계 구분
|
||||
|
||||
### 1차
|
||||
|
||||
@ -53,6 +53,18 @@ closing_criteria: 원본 스캔부터 파일별 MD 생성과 front matter 최소
|
||||
- 파일명 규칙: `원본파일명_확장자.md` 적용됨
|
||||
- front matter: title, source_path, md_path, file_type, file_size, modified_at, status, text_length, summary
|
||||
|
||||
## 현재 상태 보정 (2026-03-22)
|
||||
|
||||
- 이 단계의 핵심 산출물인 `MD 파생본 + front matter 최소 메타`는 이미 만들어졌다.
|
||||
- 다만 `48,906개 중 48,744건 text_length: 0` 상태라서, 실제 운영 가치는 아직 낮다.
|
||||
- 원본 53,336건과 MD 48,906건의 차이 4,430건도 남아 있어, `생성 완료`보다 `생성 후 본문 부재와 누락 원인 규명`이 현재의 직접 과제다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- MD 4,430건 누락 원인이 원본 경로 접근 문제인지, 필터링 규칙인지, 생성 실패 누적인지 확인이 안 됐다.
|
||||
- 본문 미추출 99.7%를 어떤 우선순위와 배치 정책으로 재처리할지 아직 고정되지 않았다.
|
||||
- NAS 원본 경로와 24 서버 런타임 컨테이너의 접근 경로가 달라 대량 재처리 경로가 불안정하다.
|
||||
|
||||
## 보류
|
||||
|
||||
- OCR
|
||||
|
||||
@ -11,7 +11,7 @@ closing_criteria: front matter와 청크를 PostgreSQL JSONB·pgvector 구조로
|
||||
## 목적
|
||||
|
||||
- 1차에서 생성한 MD와 메타를 PostgreSQL 중심 저장 구조로 적재한다.
|
||||
- 2차 범위는 `document_files`, `document_chunks` 중심으로 문서와 청크를 저장하고, PGVector 검색을 붙이는 것이다.
|
||||
- 2차 범위는 설계 별칭 `document_files`, `document_chunks`에 해당하는 운영 실체 `team_document`, `team_document_chunk`에 문서와 청크를 저장하고, PGVector 검색을 붙이는 것이다.
|
||||
|
||||
## 참조 문서
|
||||
|
||||
@ -43,10 +43,11 @@ closing_criteria: front matter와 청크를 PostgreSQL JSONB·pgvector 구조로
|
||||
- file_hash 기반 중복 방지 ✅
|
||||
- 200개 파일 인덱싱 스크립트 (`reindex_companyx_latest_200.py`) ✅
|
||||
|
||||
### 미구현
|
||||
- `team_document_chunk`에 tsvector 컬럼 없음 → **키워드 검색(TSVECTOR + GIN) 추가 필요**
|
||||
- 하이브리드 검색(벡터+키워드 RRF 합산) 없음
|
||||
- 리랭킹 없음
|
||||
### 2026-03-22 기준 구현 반영
|
||||
- `team_document_chunk.tsv` + GIN 인덱스 + 자동갱신 트리거 구현 완료
|
||||
- 하이브리드 검색(vector + keyword + graph) 및 RRF 정규화 구현 완료
|
||||
- `rb8001` grounding 서비스가 `search_mode=hybrid`로 이 검색 경로를 사용 중
|
||||
- 리랭킹 전용 계층은 아직 없음
|
||||
|
||||
### 핵심 코드 경로
|
||||
- 인덱싱: `skill-rag-file/app/services/indexing_pipeline.py` → `embedding.py` → `postgres_vector_store.py`
|
||||
@ -57,8 +58,9 @@ closing_criteria: front matter와 청크를 PostgreSQL JSONB·pgvector 구조로
|
||||
|
||||
- ~~PostgreSQL 스키마~~ → 이미 존재 (`team_document`, `team_document_chunk`)
|
||||
- ~~적재 배치 스크립트~~ → 이미 존재 (`reindex_companyx_latest_200.py`)
|
||||
- tsvector 컬럼 + GIN 인덱스 추가 마이그레이션
|
||||
- 하이브리드 검색 구현
|
||||
- ~~tsvector 컬럼 + GIN 인덱스 추가 마이그레이션~~ → 구현 완료
|
||||
- ~~하이브리드 검색 구현~~ → 구현 완료
|
||||
- 설계 별칭과 운영 테이블명 차이를 설명하는 정합화 문단
|
||||
|
||||
## 완료 조건
|
||||
|
||||
@ -73,7 +75,18 @@ closing_criteria: front matter와 청크를 PostgreSQL JSONB·pgvector 구조로
|
||||
- 인덱싱 스크립트: `skill-rag-file/scripts/reindex_companyx_latest_200.py`
|
||||
- 200개 대상 파일 리스트: `/tmp/latest_200_companyx.txt`
|
||||
- 텍스트 추출 + 청크 + Gemini Embedding 2 적재 완료
|
||||
- **미구현**: `team_document_chunk`에 tsvector 컬럼 없음 → 키워드 검색(TSVECTOR + GIN) 추가 필요
|
||||
|
||||
## 현재 상태 보정 (2026-03-22)
|
||||
|
||||
- `team_document` Company X 기준 1,174건, `team_document_chunk` 3,474건이다.
|
||||
- `tsvector + GIN`, `vector/keyword/hybrid 검색`, `Apache AGE graph_score 합산`은 모두 구현됐다.
|
||||
- 이 문서에서의 `document_files`, `document_chunks`는 설계 별칭이고, 운영 실제는 `team_document`, `team_document_chunk`다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 200개 샘플 수준을 넘어 2천/5천/1만 건 확장 시 적재 속도와 실패 격리 기준이 아직 문서화되지 않았다.
|
||||
- 삭제·이동·재처리 시 `team_document`와 MD, 그래프를 어떤 순서로 동기화할지 운영 계약이 부족하다.
|
||||
- 리랭킹 계층과 대량 재색인 품질 게이트는 아직 별도 정의가 없다.
|
||||
|
||||
## 보류
|
||||
|
||||
|
||||
@ -29,9 +29,15 @@ closing_criteria: OCR 선별 적용과 문서 관계 확장, 생성·수정·삭
|
||||
## 실제 코드 현황
|
||||
|
||||
- OCR: 미구현. 현재 인덱싱은 텍스트 추출 + PDF 바이너리 직접 임베딩만.
|
||||
- 관계: 미구현. Neo4j 컨테이너 존재하나 2개월 전 중지됨. Apache AGE로 방향 변경.
|
||||
- 관계: Apache AGE 기반 그래프는 이미 운용 중이다. `companyx_docs`, `document_graph` 그래프가 있고 검색 시 `graph_score`도 합산된다.
|
||||
- 동기화: 외부→내부 NAS cron 있음. NAS→DB 자동 인덱싱은 없음 (수동 스크립트만).
|
||||
|
||||
## 현재 상태 보정 (2026-03-22)
|
||||
|
||||
- 이 단계는 `관계 확장 일부 구현 + OCR/증분 동기화 미완` 상태다.
|
||||
- 즉 `AGE 그래프 자체`는 더 이상 예정 항목이 아니고, 남은 핵심은 `대량 증분 수집`, `재색인 트리거`, `실패 격리`, `삭제/이동 반영`이다.
|
||||
- Neo4j는 현재 기준 운영 SSOT가 아니다.
|
||||
|
||||
## 관계 생성 우선순위
|
||||
|
||||
1. front matter `related`
|
||||
@ -45,6 +51,19 @@ closing_criteria: OCR 선별 적용과 문서 관계 확장, 생성·수정·삭
|
||||
- 수정 파일: hash 비교 후 재생성/재임베딩
|
||||
- 삭제 파일: `deleted` 상태 반영
|
||||
|
||||
## 증분 운영 계약 (초안)
|
||||
|
||||
- 재색인 트리거: `새 파일`, `source_hash 변경`, `본문 미추출 보완`, `OCR 결과 추가`, `그래프 규칙 변경`일 때만 재색인한다.
|
||||
- 실패 처리: 원본 누락·경로 접근 실패는 `중단`이 아니라 `격리`하고, 문서 단위 실패 목록에 남긴 뒤 재시도한다.
|
||||
- SSOT 우선순위: `원본 파일 > MD 파생본 > team_document/team_document_chunk > AGE 그래프` 순서로 본다.
|
||||
- 품질 게이트: 샘플 질문 회귀 없음, 실패 문서 로그 남음, 삭제/수정 반영 확인을 통과해야 다음 배치 규모로 확장한다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 24 서버 런타임에서 NAS 원본 전체 경로 접근이 불안정해 대량 재처리 경로가 아직 고정되지 않았다.
|
||||
- OCR 선별 기준은 있으나 실제 배치 실행기와 실패 재시도 정책은 없다.
|
||||
- 파일 삭제/이동 시 MD, DB, 그래프를 어떤 순서와 트랜잭션 경계로 갱신할지 더 명확한 운영 기준이 필요하다.
|
||||
|
||||
## 산출물
|
||||
|
||||
- OCR 배치 정책
|
||||
|
||||
@ -139,6 +139,16 @@ sync_status: synced
|
||||
- OCR/요약/그래프 연결이 붙을 때 메타를 확장한다.
|
||||
- 메타 확장의 기준은 "검색 품질이나 운영 자동화에 실제 도움이 되는가"로 잡는다.
|
||||
|
||||
## 8-1. 현재 구현 반영 (2026-03-22)
|
||||
|
||||
- 실제 MD에는 `title`, `source_path`, `md_path`, `file_type`, `file_size`, `modified_at`, `status`, `text_length`, `summary`가 우선 반영돼 있다.
|
||||
- 권장 메타 전체와 실제 메타 사이에는 아직 차이가 있으며, 특히 `ocr_status`, `embedding_status`, `sync_status`, `related`는 전면 적용되지 않았다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 권장 메타 중 무엇을 MD front matter에 두고 무엇을 DB JSONB 전용으로 둘지 최종 경계가 고정되지 않았다.
|
||||
- 실제 메타와 권장 메타의 갭을 언제 어떤 배치로 메울지 계획이 부족하다.
|
||||
|
||||
## 9. 관련 문서
|
||||
|
||||
- [Markdown 중간표현 SSOT 설계 리서치](./260320_MD_중간표현_SSOT_설계_리서치.md)
|
||||
|
||||
@ -87,6 +87,16 @@ research_target: 다형식 원본을 위한 Markdown 중간표현 SSOT 규칙
|
||||
- 최소 MD에는 "이 파일이 무엇인지"와 "현재 어느 정도까지 해석됐는지"만 적어도 된다.
|
||||
- 이후 표 추출, OCR, 요약, 태그는 후속 배치로 누적하는 구조가 좋다.
|
||||
|
||||
## 9-1. 현재 구현 반영 (2026-03-22)
|
||||
|
||||
- 최소 MD 생성 자체는 이미 48,906개 규모로 진행됐다.
|
||||
- 하지만 본문이 비어 있는 MD가 48,744건이라, 이 리서치의 핵심은 `MD를 만들자`보다 `MD를 실제로 읽을 수 있게 채우자`로 옮겨갔다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 99.7% 본문 미추출 상태를 어떤 우선순위와 배치로 해소할지 아직 정해지지 않았다.
|
||||
- 원본 53,336건과 MD 48,906건의 차이를 설명하는 실패/스킵 기준이 문서화되지 않았다.
|
||||
|
||||
## 10. 관련 문서
|
||||
|
||||
- [다형식 문서 RAG 자동수집·정규화 전략 리서치](./260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md)
|
||||
|
||||
@ -94,3 +94,14 @@ research_target: OCR 전수 대신 선별 적용 기준과 비용-품질 정책
|
||||
|
||||
- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md)
|
||||
- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md)
|
||||
- [OCR 모델 벤치마크 리서치](./260320_OCR_모델_벤치마크_리서치.md)
|
||||
|
||||
## 10-1. 현재 구현 반영 (2026-03-22)
|
||||
|
||||
- OCR 정책은 아직 설계 단계이고, 실제 운영은 `텍스트 추출 + PDF 바이너리 직접 임베딩` 수준이다.
|
||||
- 따라서 OCR 문서는 독립 과제가 아니라 `본문 미추출 99.7%` 문제와 연결해서 읽어야 한다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- OCR 대상을 고른 뒤 어떤 배치 단위와 실패 재시도로 돌릴지 운영 기준이 없다.
|
||||
- OCR 보강이 실제 검색 품질을 얼마나 올리는지 측정 지표가 아직 고정되지 않았다.
|
||||
|
||||
@ -130,6 +130,17 @@ create index if not exists idx_document_chunks_embedding_hnsw
|
||||
- `status`와 `metadata_jsonb` 안의 `sync_status`, `ocr_status`, `embedding_status`를 함께 관리한다.
|
||||
- soft delete를 우선 사용해 감사 추적과 복구 가능성을 남긴다.
|
||||
|
||||
## 9-1. 현재 구현 반영 (2026-03-22)
|
||||
|
||||
- 운영 실제 테이블은 `document_files`, `document_chunks`가 아니라 `team_document`, `team_document_chunk`다.
|
||||
- `tsvector + GIN`, `PGVector HNSW`, `JSONB`, `hybrid 검색`은 이미 구현됐다.
|
||||
- 관계 저장은 권장 `document_relations` 테이블이 아니라 Apache AGE 그래프 쪽으로 이동했다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 설계 별칭과 운영 실체를 한 번에 읽을 수 있는 정합화 표가 아직 없다.
|
||||
- `document_jobs` 수준의 작업 상태 테이블을 둘지, 기존 테이블 메타와 로그로 버틸지 확정되지 않았다.
|
||||
|
||||
## 10. 관련 문서
|
||||
|
||||
- [다형식 문서 RAG 자동수집·정규화 전략 리서치](./260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md)
|
||||
|
||||
@ -120,7 +120,7 @@ group by id, title
|
||||
order by min_depth, id;
|
||||
```
|
||||
|
||||
## 7. AGE 그래프 스키마 (예정)
|
||||
## 7. AGE 그래프 스키마 (운영 반영 전제)
|
||||
|
||||
### 노드
|
||||
- `Document`: 문서 (title, source_path, file_type, tags)
|
||||
@ -154,6 +154,17 @@ RETURN r.title
|
||||
- `document_relations` 테이블 대신 AGE 그래프로 관계 관리.
|
||||
- PGVector(의미검색) + AGE(관계탐색)를 하나의 DB에서 하이브리드 운용.
|
||||
|
||||
## 8-1. 현재 구현 반영 (2026-03-22)
|
||||
|
||||
- Apache AGE는 더 이상 예정이 아니라 운영 중이다.
|
||||
- 검색 경로에서도 `graph_score`가 합산되고, `companyx_docs`, `document_graph` 그래프가 실제로 존재한다.
|
||||
- 따라서 이 문서의 남은 역할은 `왜 AGE를 쓰는가`보다 `운영 그래프를 어떤 규칙으로 유지할 것인가`에 가깝다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 그래프 노드/엣지 생성 규칙의 최종 SSOT가 아직 약하다.
|
||||
- 삭제·이동·재색인 시 그래프를 언제 갱신하고 언제 재구성할지 운영 기준이 부족하다.
|
||||
|
||||
## 10. 관련 문서
|
||||
|
||||
- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md)
|
||||
|
||||
@ -103,6 +103,17 @@ research_target: 다형식 원본의 자동 수집·정규화 전략 정리
|
||||
5. 100~500개 파일로 샘플 검증
|
||||
6. 이후 배치 자동화와 증분 동기화로 확대
|
||||
|
||||
## 9-1. 현재 구현 반영 (2026-03-22)
|
||||
|
||||
- 1~4번은 개념 정리 수준을 넘어서 일부 구현까지 들어갔다.
|
||||
- 특히 샘플 200개 인덱싱과 하이브리드 검색, AGE 기반 연결은 이미 운영 코드에 반영돼 있다.
|
||||
- 남은 핵심은 `배치 자동화와 증분 동기화로 확대` 부분이다.
|
||||
|
||||
## Unresolved
|
||||
|
||||
- 재색인 트리거, 실패 격리/재시도, 원본-MD-DB-그래프 우선순위가 아직 문서 한 곳에 고정되지 않았다.
|
||||
- 2천/5천/1만 건 단계에서 어떤 품질 게이트로 확장 여부를 판단할지 미정이다.
|
||||
|
||||
## 10. 관련 문서
|
||||
|
||||
- [Markdown 중간표현 SSOT 설계 리서치](./260320_MD_중간표현_SSOT_설계_리서치.md)
|
||||
|
||||
@ -1,4 +1,9 @@
|
||||
---
|
||||
tags: [valuation, rag, companyx, documentation, completeness]
|
||||
type: research
|
||||
status: open
|
||||
research_target: 열린 Company X RAG 문서 10개의 문서-현실 괴리 평가
|
||||
---
|
||||
|
||||
# 260322 Company X RAG 문서 완벽도 평가
|
||||
|
||||
@ -49,8 +54,8 @@ tags: [valuation, rag, companyx, documentation, completeness]
|
||||
## 공통 문제
|
||||
|
||||
### 1. 프론트메터 부재/불완전
|
||||
- 계획 3개: tags/status 전혀 없음
|
||||
- 리서치 6개: `status: proposed`에서 멈춰 있음
|
||||
- 이 평가는 당시 기준 문제 제기로 유효했다.
|
||||
- 2026-03-22 현재는 열린 10개 문서와 `workflow/03_rag` 문서에 YAML front matter, `type`, `status` 또는 `last_updated`가 반영됐다.
|
||||
|
||||
### 2. 현재 상태 미반영
|
||||
- tsvector 컬럼, 하이브리드 검색, AGE 그래프가 이미 구현됐으나 "미구현"으로 남아 있음
|
||||
@ -131,3 +136,8 @@ tags: [valuation, rag, companyx, documentation, completeness]
|
||||
- **3차 계획**도 마찬가지입니다. Apache AGE는 23서버에서 이미 설치·운용 중이고, `companyx_docs` 그래프에 노드가 있고, `postgres_vector_store.py`에서 Cypher 쿼리로 graph_score를 합산하고 있습니다. 그런데 문서에는 `미구현. Neo4j 컨테이너 존재하나 2개월 전 중지됨`입니다.
|
||||
- Cursor 의견의 **"1차 본문 미추출 99.7%가 최우선"** 에 동의합니다. 오늘 P1-4에서 초과 청크 재분할을 돌렸는데, 381건 중 8건만 성공했습니다. 원인은 NAS 원본 경로(`/mnt/nas/...`)가 24서버 컨테이너에서 접근 불가이기 때문입니다. `documents/` 경로에 복사된 200개 파일만 접근 가능합니다. 이 NAS 마운트 문제가 해결되지 않으면 대량 재인덱싱도, 본문 추출도 진행할 수 없습니다.
|
||||
- **제 판단:** 문서 10개를 정비하기 전에 **현재 구현 상태를 문서에 1회 동기화**하는 게 먼저입니다. 구현된 것을 "구현됨"으로, 수치를 현재값으로, 테이블명을 실제명으로 맞추는 작업입니다. 이건 설계 논쟁이 아니라 사실 반영이라 빠르게 닫힙니다.
|
||||
|
||||
## 2026-03-22 반영 메모
|
||||
|
||||
- 이 평가서의 종합 의견에 따라 열린 10개 문서에 `현재 구현 반영`, `Unresolved`, `증분 운영 계약` 보강을 반영했다.
|
||||
- 따라서 이 문서는 "초기 평가"와 "1차 정비 반영 후 기준점"을 함께 보는 문서로 읽는다.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user