From 8226affa9aeac17745c769378d97f6228c0f0f58 Mon Sep 17 00:00:00 2001 From: happybell80 Date: Fri, 20 Mar 2026 12:43:52 +0900 Subject: [PATCH] docs: add multimodal rag research set --- ...Matter_메타데이터_설계_리서치.md | 143 ++++++++++++++++++ ...0_MD_중간표현_SSOT_설계_리서치.md | 91 +++++++++++ ...60320_OCR_선별적용_정책_리서치.md | 93 ++++++++++++ ...or_JSONB_RAG_스키마_설계_리서치.md | 134 ++++++++++++++++ ...greSQL_그래프확장_설계_리서치.md | 130 ++++++++++++++++ ...자동수집_정규화_전략_리서치.md | 109 +++++++++++++ journey/research/rag/README.md | 36 +++++ 7 files changed, 736 insertions(+) create mode 100644 journey/research/rag/260320_FrontMatter_메타데이터_설계_리서치.md create mode 100644 journey/research/rag/260320_MD_중간표현_SSOT_설계_리서치.md create mode 100644 journey/research/rag/260320_OCR_선별적용_정책_리서치.md create mode 100644 journey/research/rag/260320_PGVector_JSONB_RAG_스키마_설계_리서치.md create mode 100644 journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md create mode 100644 journey/research/rag/260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md create mode 100644 journey/research/rag/README.md diff --git a/journey/research/rag/260320_FrontMatter_메타데이터_설계_리서치.md b/journey/research/rag/260320_FrontMatter_메타데이터_설계_리서치.md new file mode 100644 index 0000000..c7f6191 --- /dev/null +++ b/journey/research/rag/260320_FrontMatter_메타데이터_설계_리서치.md @@ -0,0 +1,143 @@ +--- +tags: [research, rag, robeing, metadata, front-matter, jsonb] +--- + +# Front Matter 메타데이터 설계 리서치 + +## 상태 + +- proposed + +**작성일**: 2026-03-20 +**목적**: Markdown front matter와 PostgreSQL JSONB에 공통 반영 가능한 메타데이터 구조를 정리한다. + +--- + +## 1. 설계 목표 + +- 검색에 도움이 되는 메타와 운영 동기화에 필요한 메타를 함께 담는다. +- 사람이 읽는 front matter와 DB의 JSONB가 서로 크게 어긋나지 않도록 한다. +- OCR, 임베딩, 그래프 연결 같은 후속 처리를 메타만 보고 판단할 수 있게 한다. + +## 2. 메타 항목 분류 + +### 2.1 기본 식별 + +- `title` +- `source_path` +- `md_path` +- `file_type` +- `file_ext` +- `folder_path` +- `source_hash` + +### 2.2 시간/작성자 + +- `created_at` +- `modified_at` +- `indexed_at` +- `author` +- `owner` + +### 2.3 내용 통계 + +- `text_length` +- `image_count` +- `table_count` +- `graph_count` +- `page_count` +- `sheet_count` +- `slide_count` +- `duration_seconds` + +### 2.4 검색/추론 보조 + +- `tags` +- `keywords` +- `summary` +- `language` +- `entities` +- `related` +- `priority` + +### 2.5 처리 상태 + +- `status` +- `ocr_status` +- `embedding_status` +- `sync_status` +- `deleted_at` +- `last_error` + +## 3. 최소 필수 메타 + +- `title` +- `source_path` +- `file_type` +- `modified_at` +- `status` +- `text_length` +- `tags` +- `summary` + +## 4. 추천 front matter 예시 + +```yaml +--- +title: 오늘전통 사업계획서 +source_path: /mnt/nas/workspace/6.Company X/.../사업계획서_컴퍼니엑스.pdf +md_path: /mnt/nas/indexed_md/.../사업계획서_컴퍼니엑스_pdf.md +file_type: pdf +file_ext: .pdf +folder_path: /mnt/nas/workspace/6.Company X/... +created_at: 2025-01-23T10:21:00+09:00 +modified_at: 2026-03-20T11:15:00+09:00 +indexed_at: 2026-03-20T13:40:00+09:00 +author: Company X +text_length: 12450 +image_count: 7 +table_count: 4 +graph_count: 2 +page_count: 28 +tags: [companyx, rag, accelerator, yellowpunch] +keywords: [오늘전통, 옐로펀치, 공동 컨소시엄, 액셀러레이터] +summary: 오늘전통 사업계획서 내 협력기관 및 공동 지원 구조를 설명하는 PDF. +related: + - /mnt/nas/indexed_md/.../TalkFile_MOU_옐로펀치X컴퍼니엑스_pdf.md +status: active +ocr_status: pending +embedding_status: indexed +sync_status: synced +--- +``` + +## 5. 내가 추천하는 메타 활용 방식 + +- `text_length`, `image_count`, `table_count`는 OCR 대상을 고르는 기준으로 쓴다. +- `status`, `sync_status`는 생성/수정/삭제 동기화 판단에 쓴다. +- `tags`, `keywords`, `summary`는 검색 랭킹과 후속 LLM 컨텍스트에 직접 쓴다. +- `related`는 PostgreSQL 그래프 확장의 직접 입력으로 쓴다. + +## 6. front matter와 JSONB의 관계 + +- front matter는 사람이 읽고 수정하기 쉬운 레이어다. +- JSONB는 SQL 필터, 운영 상태 업데이트, 검색 최적화를 위한 레이어다. +- 둘을 완전 동일하게 유지할 필요는 없지만, 핵심 키는 동일하게 가져가는 편이 낫다. + +## 7. 주의점 + +- 메타 항목이 너무 많아도 초기 구축이 느려진다. +- 작성자, 생성 시간 같은 항목은 원본 포맷별 추출 정확도가 다르므로 nullable로 두는 편이 맞다. +- `graph_count`처럼 완전 정확한 추출이 어려운 항목은 "추정치"가 아니라 "현재 파이프라인 기준 값"으로 다뤄야 한다. + +## 8. 이번 단계 추천 + +- 최소 필수 메타로 먼저 시작한다. +- OCR/요약/그래프 연결이 붙을 때 메타를 확장한다. +- 메타 확장의 기준은 "검색 품질이나 운영 자동화에 실제 도움이 되는가"로 잡는다. + +## 9. 관련 문서 + +- [Markdown 중간표현 SSOT 설계 리서치](./260320_MD_중간표현_SSOT_설계_리서치.md) +- [OCR 선별 적용 정책 리서치](./260320_OCR_선별적용_정책_리서치.md) +- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md) diff --git a/journey/research/rag/260320_MD_중간표현_SSOT_설계_리서치.md b/journey/research/rag/260320_MD_중간표현_SSOT_설계_리서치.md new file mode 100644 index 0000000..1bd43f0 --- /dev/null +++ b/journey/research/rag/260320_MD_중간표현_SSOT_설계_리서치.md @@ -0,0 +1,91 @@ +--- +tags: [research, rag, robeing, markdown, ssot, intermediate-format] +--- + +# Markdown 중간표현 SSOT 설계 리서치 + +## 상태 + +- proposed + +**작성일**: 2026-03-20 +**목적**: 다형식 원본을 로빙이 안정적으로 읽을 수 있도록 Markdown 중간표현의 역할과 규칙을 정리한다. + +--- + +## 1. 결론 + +- Markdown은 최종 저장형이 아니라 **표준 중간표현**으로 두는 것이 맞다. +- 원본 파일을 Markdown으로 "대체"하는 것이 아니라, 원본을 설명하고 로빙이 읽기 쉽게 정규화한 파생본으로 보는 것이 맞다. +- `파일 1개 : MD 1개` 구조가 가장 단순하고 운영 가능성이 높다. + +## 2. 왜 Markdown인가 + +- 사람 검토가 쉽다. +- LLM이 잘 읽는다. +- front matter를 붙이기 쉽다. +- OCR 추가 결과, 요약, 링크, 표 변환 결과를 누적하기 쉽다. +- 향후 임베딩 모델이 바뀌어도 같은 문서를 재활용하기 쉽다. + +## 3. 파일명 규칙 제안 + +- 기본 규칙: 원본 파일명 유지 + 원본 확장자 표시 + `.md` +- 예시: + - `사업계획서.pdf -> 사업계획서_pdf.md` + - `로고 시안.jpg -> 로고 시안_jpg.md` + - `매출 보고서 2025.hwp -> 매출 보고서 2025_hwp.md` + +## 4. 폴더 구조 규칙 제안 + +- 원본 폴더 구조는 유지한다. +- 요약/정규화 저장소도 같은 상대 경로를 따라간다. +- 예시: + - 원본: `.../부서A/2025/매출.pdf` + - 파생: `.../부서A/2025/매출_pdf.md` + +## 5. 파일 종류별 중간표현 방식 + +| 파일 타입 | Markdown에 담을 핵심 | +|-----------|----------------------| +| PDF | 추출 텍스트, 표, 이미지/페이지 정보, OCR 상태 | +| HWP/DOCX | 제목, 본문, 표, 문단 구조 | +| XLSX | 시트별 표, 주요 숫자, 차트 존재 여부 | +| PPTX | 슬라이드별 제목, 본문, 도형/표/이미지 요약 | +| JPG/PNG | 파일 정보, OCR 텍스트, 이미지 설명, 원본 경로 | +| MP4/MOV | 파일 정보, 자막 추출 상태, 프레임/오디오 처리 상태 | + +## 6. Markdown 본문 템플릿 제안 + +1. front matter +2. 문서 개요 +3. 원본 파일 정보 +4. 자동 추출 본문 +5. 표/이미지/슬라이드 섹션 +6. 후처리 섹션 +7. OCR/LLM 보강 섹션 + +## 7. 내가 추천하는 운영 원칙 + +- 원본은 절대 덮어쓰지 않는다. +- Markdown은 재생성 가능해야 한다. +- 사람이 수정한 영역과 자동 생성 영역을 구분하는 편이 좋다. +- OCR/요약/태그 같은 후속 보강은 기존 MD에 누적 가능해야 한다. +- 모든 MD는 원본 경로를 항상 포함해야 한다. + +## 8. Markdown을 쓰지 말아야 하는 경우 + +- 원본 레이아웃 자체가 법적 증거 수준으로 보존돼야 하는 경우 +- CAD, 3D, 바이너리 포맷처럼 텍스트 기반 중간표현이 거의 무의미한 경우 +- 극단적으로 짧고 메타만 의미 있는 파일 + +## 9. 이번 단계 추천 + +- 먼저 모든 파일에 대해 최소 MD를 만든다. +- 최소 MD에는 "이 파일이 무엇인지"와 "현재 어느 정도까지 해석됐는지"만 적어도 된다. +- 이후 표 추출, OCR, 요약, 태그는 후속 배치로 누적하는 구조가 좋다. + +## 10. 관련 문서 + +- [다형식 문서 RAG 자동수집·정규화 전략 리서치](./260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md) +- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md) +- [OCR 선별 적용 정책 리서치](./260320_OCR_선별적용_정책_리서치.md) diff --git a/journey/research/rag/260320_OCR_선별적용_정책_리서치.md b/journey/research/rag/260320_OCR_선별적용_정책_리서치.md new file mode 100644 index 0000000..1e075b8 --- /dev/null +++ b/journey/research/rag/260320_OCR_선별적용_정책_리서치.md @@ -0,0 +1,93 @@ +--- +tags: [research, rag, robeing, ocr, policy, cost] +--- + +# OCR 선별 적용 정책 리서치 + +## 상태 + +- proposed + +**작성일**: 2026-03-20 +**목적**: OCR을 모든 파일에 전수 적용하지 않고, 가치가 높은 파일에 선별 적용하는 기준을 정리한다. + +--- + +## 1. 결론 + +- OCR은 필요하지만 전수 OCR은 비효율적이다. +- 먼저 기본 메타를 뽑고, 그 메타를 바탕으로 OCR 필요 대상을 고르는 것이 맞다. +- OCR은 "문서를 이해하기 위한 기본값"이 아니라 "텍스트 추출이 부족한 파일을 보강하는 수단"으로 둬야 한다. + +## 2. 왜 전수 OCR이 비효율적인가 + +- 이미지가 많은 파일은 시간이 오래 걸린다. +- 로고, 장식 이미지, 단순 사진까지 OCR하면 비용과 시간이 급증한다. +- 실제 검색에 도움이 되는 파일과 그렇지 않은 파일을 구분하지 못한다. + +## 3. OCR 우선 대상 조건 제안 + +- `text_length`가 매우 낮다. +- `image_count`가 높다. +- 파일 타입이 JPG/PNG/PDF 스캔본이다. +- 계약서, 제안서, 보고서처럼 문맥 가치가 높다. +- 사람이 "텍스트가 안 잡힌다"고 피드백한 파일이다. + +## 4. 예시 규칙 + +| 조건 | 해석 | 추천 액션 | +|------|------|-----------| +| `text_length < 1000` and `image_count >= 3` | 스캔 PDF 가능성 높음 | OCR 후보 | +| `file_type in (jpg, png)` | 텍스트 원문 없음 | OCR 후보 | +| `file_type = pdf` and `table_count = 0` and `image_count > 5` | 그래프/이미지 중심 PDF 가능성 | OCR 또는 이미지 설명 후보 | +| `file_type in (docx, hwp)` and `text_length` 충분 | 이미 본문 확보 | OCR 불필요 | + +## 5. OCR 후 MD에 추가할 내용 + +- OCR 텍스트 원문 +- OCR 수행 시각 +- OCR 엔진 +- OCR 신뢰도 +- OCR 대상 이미지/페이지 정보 + +## 6. 내가 추천하는 처리 전략 + +### 6.1 1단계 + +- 모든 파일에 대해 최소 MD와 기본 메타를 만든다. + +### 6.2 2단계 + +- 메타 기준으로 OCR 후보군만 분리한다. + +### 6.3 3단계 + +- OCR 결과를 기존 MD에 섹션으로 추가한다. + +### 6.4 4단계 + +- OCR 전/후 검색 품질 차이가 큰 유형만 정책화한다. + +## 7. LLM과 OCR의 역할 분리 + +- OCR은 문자 인식이다. +- LLM은 요약, 태그, 설명, 캡션 보강이다. +- OCR을 먼저 하고, LLM은 OCR 결과가 붙은 문서를 후속 해석하는 편이 맞다. + +## 8. 운영 상태 필드 제안 + +- `ocr_status: pending | completed | skipped | failed` +- `ocr_reason` +- `ocr_engine` +- `ocr_confidence` + +## 9. 추천 보류 + +- 초기 단계부터 이미지 캡션 생성까지 모두 전수 적용 +- OCR과 LLM 해석을 한 배치에 섞는 것 +- OCR 실패 파일을 즉시 수동 처리 대상으로 돌리는 것 + +## 10. 관련 문서 + +- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md) +- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md) diff --git a/journey/research/rag/260320_PGVector_JSONB_RAG_스키마_설계_리서치.md b/journey/research/rag/260320_PGVector_JSONB_RAG_스키마_설계_리서치.md new file mode 100644 index 0000000..6e2668d --- /dev/null +++ b/journey/research/rag/260320_PGVector_JSONB_RAG_스키마_설계_리서치.md @@ -0,0 +1,134 @@ +--- +tags: [research, rag, robeing, pgvector, jsonb, postgres, schema] +--- + +# PGVector·JSONB RAG 스키마 설계 리서치 + +## 상태 + +- proposed + +**작성일**: 2026-03-20 +**목적**: Markdown 중간표현, 메타데이터, 청크, 임베딩을 PostgreSQL 중심으로 관리하는 스키마 방향을 정리한다. + +--- + +## 1. 결론 + +- 현재 로빙 구조에서는 별도 벡터 DB보다 PostgreSQL + PGVector + JSONB가 더 실용적이다. +- 문서 원본 레벨과 청크 레벨을 분리해 관리해야 한다. +- 사람이 읽는 Markdown과 검색이 읽는 청크를 분리하면 재처리와 품질 개선이 쉬워진다. + +## 2. 권장 테이블 분리 + +| 테이블 | 역할 | +|--------|------| +| `document_files` | 원본 파일 및 Markdown 파생본 단위 관리 | +| `document_chunks` | 임베딩·검색용 청크 관리 | +| `document_relations` | 명시적 문서 연결 관리 | +| `document_jobs` | OCR/임베딩/동기화 작업 상태 관리 | + +## 3. `document_files` 권장 필드 + +- `id` +- `source_path` +- `md_path` +- `title` +- `file_type` +- `status` +- `author` +- `created_at` +- `modified_at` +- `indexed_at` +- `metadata_jsonb` +- `content_hash` + +## 4. `document_chunks` 권장 필드 + +- `id` +- `document_file_id` +- `chunk_index` +- `chunk_type` +- `content` +- `content_tsv` +- `embedding` +- `token_count` +- `metadata_jsonb` +- `created_at` + +## 5. 추천 SQL 초안 + +```sql +create table if not exists document_files ( + id bigserial primary key, + source_path text not null unique, + md_path text not null, + title text not null, + file_type text not null, + status text not null default 'active', + author text, + created_at timestamptz, + modified_at timestamptz, + indexed_at timestamptz default now(), + content_hash text, + metadata_jsonb jsonb not null default '{}'::jsonb +); + +create table if not exists document_chunks ( + id bigserial primary key, + document_file_id bigint not null references document_files(id) on delete cascade, + chunk_index integer not null, + chunk_type text not null default 'text', + content text not null, + content_tsv tsvector, + token_count integer, + metadata_jsonb jsonb not null default '{}'::jsonb, + embedding vector(768), + created_at timestamptz not null default now(), + unique (document_file_id, chunk_index) +); + +create index if not exists idx_document_files_metadata_jsonb + on document_files using gin (metadata_jsonb); + +create index if not exists idx_document_chunks_metadata_jsonb + on document_chunks using gin (metadata_jsonb); + +create index if not exists idx_document_chunks_tsv + on document_chunks using gin (content_tsv); + +create index if not exists idx_document_chunks_embedding_hnsw + on document_chunks using hnsw (embedding vector_cosine_ops); +``` + +## 6. 내가 추천하는 검색 방식 + +- 1차: SQL 필터로 범위를 줄인다. +- 2차: `tsvector` 키워드 검색과 PGVector 의미 검색을 함께 돌린다. +- 3차: 결과를 합성해 상위 청크를 고른다. +- 4차: 필요시 `document_files.metadata_jsonb`와 `related` 관계를 따라 확장한다. + +## 7. JSONB를 넣는 이유 + +- front matter 전체를 유연하게 저장할 수 있다. +- 파일 타입별 메타 차이를 허용하기 쉽다. +- SQL 필터와 운영 상태 갱신이 쉽다. +- 향후 메타 항목이 늘어나도 마이그레이션 부담이 줄어든다. + +## 8. 내가 반대한 구조 + +- 문서 전체를 한 테이블 한 컬럼에만 몰아넣는 방식 +- 메타데이터를 JSONB 없이 text 배열로만 관리하는 방식 +- 청크 테이블 없이 문서 전체에만 벡터를 매다는 방식 + +## 9. 운영 관점 추천 + +- `content_hash`로 재처리 필요 여부를 판정한다. +- `status`와 `metadata_jsonb` 안의 `sync_status`, `ocr_status`, `embedding_status`를 함께 관리한다. +- soft delete를 우선 사용해 감사 추적과 복구 가능성을 남긴다. + +## 10. 관련 문서 + +- [다형식 문서 RAG 자동수집·정규화 전략 리서치](./260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md) +- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md) +- [PostgreSQL 그래프 확장 설계 리서치](./260320_PostgreSQL_그래프확장_설계_리서치.md) diff --git a/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md b/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md new file mode 100644 index 0000000..58a246d --- /dev/null +++ b/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md @@ -0,0 +1,130 @@ +--- +tags: [research, rag, robeing, postgres, graph, relations] +--- + +# PostgreSQL 그래프확장 설계 리서치 + +## 상태 + +- proposed + +**작성일**: 2026-03-20 +**목적**: 별도 그래프 DB 없이 PostgreSQL 안에서 문서 연결성과 탐색성을 얼마나 가져갈 수 있는지 정리한다. + +--- + +## 1. 결론 + +- 지금 단계에서 별도 그래프 DB를 바로 도입할 필요는 없다. +- PostgreSQL만으로도 문서 간 연결, 태그 기반 연결, 재귀 탐색은 상당 부분 구현 가능하다. +- 로빙의 현재 목표는 "그래프 DB 도입" 자체가 아니라 "근거 문서 연결성을 높이는 것"이므로, 우선 Postgres 확장으로 충분하다. + +## 2. 연결 원천 + +- front matter의 `related` +- 공통 `tags` +- 공통 `keywords` +- 같은 폴더/프로젝트/작성자 +- 벡터 유사도 상 가까운 문서 + +## 3. 권장 테이블 + +```sql +create table if not exists document_relations ( + id bigserial primary key, + from_document_id bigint not null references document_files(id) on delete cascade, + to_document_id bigint not null references document_files(id) on delete cascade, + relation_type text not null, + weight numeric(6,3), + metadata_jsonb jsonb not null default '{}'::jsonb, + created_at timestamptz not null default now(), + unique (from_document_id, to_document_id, relation_type) +); + +create index if not exists idx_document_relations_from + on document_relations (from_document_id); + +create index if not exists idx_document_relations_to + on document_relations (to_document_id); + +create index if not exists idx_document_relations_metadata + on document_relations using gin (metadata_jsonb); +``` + +## 4. relation_type 예시 + +- `explicit_related` +- `same_folder` +- `same_project` +- `shared_tag` +- `shared_keyword` +- `semantic_neighbor` +- `derived_from` + +## 5. 내가 추천하는 연결 생성 방식 + +### 5.1 명시 연결 우선 + +- front matter의 `related`는 사람이 검증한 연결이므로 신뢰도가 높다. + +### 5.2 규칙 기반 연결 다음 + +- 같은 폴더, 같은 프로젝트, 같은 태그 등은 자동 생성하기 쉽다. + +### 5.3 벡터 기반 연결은 후순위 + +- 유사도만으로 연결하면 오탐이 많을 수 있다. +- `semantic_neighbor`는 보조 연결로만 두는 것이 맞다. + +## 6. 재귀 탐색 예시 + +```sql +with recursive related_docs as ( + select + df.id, + df.title, + 0 as depth + from document_files df + where df.id = $1 + + union all + + select + df2.id, + df2.title, + rd.depth + 1 + from related_docs rd + join document_relations dr + on dr.from_document_id = rd.id + join document_files df2 + on df2.id = dr.to_document_id + where rd.depth < 3 +) +select distinct id, title, min(depth) as min_depth +from related_docs +group by id, title +order by min_depth, id; +``` + +## 7. 왜 이 정도면 충분한가 + +- 로빙이 필요로 하는 것은 수십억 노드 그래프 분석이 아니다. +- 질문에 대한 근거 문서 묶음, 연관 문서 체인, 같은 프로젝트 맥락 정도면 충분하다. +- 이 범위는 PostgreSQL과 재귀 쿼리로 관리 가능하다. + +## 8. 그래프 DB를 나중에 도입해야 하는 조건 + +- 관계 유형이 너무 많아지고 실시간 그래프 탐색이 핵심이 될 때 +- 연결 시각화가 제품의 핵심 화면이 될 때 +- 추천, 경로 분석, 중심성 분석이 주 서비스가 될 때 + +## 9. 현재 추천 + +- 지금은 PostgreSQL 안에서 `document_files`, `document_relations`, PGVector를 함께 운영한다. +- relation 생성 규칙을 먼저 고정하고, retrieval 품질 향상 여부를 검증한다. +- 그래프 DB는 필요가 입증될 때 별도로 도입한다. + +## 10. 관련 문서 + +- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md) +- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md) diff --git a/journey/research/rag/260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md b/journey/research/rag/260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md new file mode 100644 index 0000000..e62a0a4 --- /dev/null +++ b/journey/research/rag/260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md @@ -0,0 +1,109 @@ +--- +tags: [research, rag, robeing, ingestion, normalization, multimodal] +--- + +# 다형식 문서 RAG 자동수집·정규화 전략 리서치 + +## 상태 + +- proposed + +**작성일**: 2026-03-20 +**목적**: 로빙이 여러 형식의 파일을 읽고, 검색 가능하고, 자동으로 갱신되는 지식 자산으로 만드는 전체 방향을 정리한다. + +--- + +## 1. 문제 정의 + +- 로빙이 다뤄야 하는 원본은 PDF, HWP, DOCX, XLSX, PPTX, JPG, PNG, MP4처럼 형식이 매우 다양하다. +- 파일 수가 수만 건 규모로 커지면 단순 텍스트 추출만으로는 관리가 무너진다. +- 파일이 계속 생성·수정·삭제되므로 일회성 적재가 아니라 지속 동기화 구조가 필요하다. +- 최종 목표는 단순 검색기가 아니라, 로빙이 근거를 찾아 읽고 답변하고, 점점 더 똑똑해지는 구조다. + +## 2. 이번 리서치의 결론 + +- **원본 보존, 중간표현 정규화, 저장계층 분리**가 핵심이다. +- 원본 파일은 그대로 두고, 로빙이 읽는 표준 중간표현을 별도로 생성해야 한다. +- 중간표현은 Markdown을 기본으로 하고, 메타데이터는 front matter와 PostgreSQL JSONB 양쪽에 반영 가능하게 설계한다. +- 검색은 `키워드 검색 + 벡터 검색 + 연결 탐색`을 함께 가져가야 한다. +- OCR과 LLM은 전체 전수 적용이 아니라 메타 기반 선별 적용이 맞다. + +## 3. 목표 아키텍처 + +| 계층 | 역할 | 권장 형태 | +|------|------|-----------| +| 원본 계층 | 실제 파일 보존 | NAS/파일시스템 원본 | +| 중간표현 계층 | 로빙이 읽는 표준 문서 | Markdown 1:1 파생본 | +| 메타 계층 | 검색/운영/동기화 상태 | front matter + JSONB | +| 검색 계층 | 키워드/의미/연결 검색 | PostgreSQL + PGVector | +| 확장 계층 | 그래프형 연결 탐색 | related/tags 기반 Postgres 그래프 | + +## 4. 내가 추천하는 설계 원칙 + +### 4.1 Markdown을 중간표현으로 둔다 + +- 이유 1: 사람도 읽을 수 있고, LLM도 읽기 쉽다. +- 이유 2: 파일 하나에 대한 요약, OCR 추가 결과, 후속 분석을 누적하기 쉽다. +- 이유 3: 나중에 임베딩을 다시 만들더라도 원본 재파싱 없이 중간표현만 다시 읽으면 된다. + +### 4.2 원본과 파생본은 1:1 대응으로 관리한다 + +- `원본 파일 1개 -> MD 파일 1개`가 기본이다. +- 파일 수가 많을수록 폴더 구조 유지가 중요하다. +- 이 방식은 삭제, 재생성, 부분 재처리, 감사 추적에 모두 유리하다. + +### 4.3 PostgreSQL을 중심 허브로 둔다 + +- 이미 PGVector를 쓰고 있으면 별도 벡터 DB를 늘리는 것보다 운영 복잡도를 줄이는 편이 낫다. +- 메타데이터, 문서 상태, 임베딩, 문서 간 관계를 한 DB에서 관리할 수 있다. +- Chroma/FAISS는 빠른 실험에는 유리하지만, 로빙의 장기 운영 SSOT로는 PostgreSQL 쪽이 더 일관적이다. + +## 5. 처리 흐름 제안 + +1. 원본 스캔 +2. 파일 타입 식별 +3. 기본 메타 추출 +4. Markdown 파생본 생성 +5. 선별 OCR 또는 후처리 판단 +6. 문단/청크 단위 분리 +7. 임베딩 생성 +8. PostgreSQL 적재 +9. 생성·수정·삭제 동기화 반영 + +## 6. 자동화 관점의 핵심 포인트 + +- 새 파일 생성 시: 같은 상대 경로에 MD 생성 +- 파일 수정 시: MD와 임베딩 재생성 필요 여부 판정 +- 파일 삭제 시: MD와 DB 레코드를 hard delete하지 말고 `deleted` 상태 우선 기록 +- OCR 미적용 파일은 `ocr_pending` 같은 상태로 남겨 후속 배치 대상화 + +## 7. 왜 이 구조가 로빙을 더 똑똑하게 만드는가 + +- 로빙은 원본 형식에 직접 종속되지 않고, 표준화된 중간표현을 읽게 된다. +- front matter와 JSONB 메타를 통해 "표가 많은 문서", "이미지가 많은 PDF", "최근 수정된 계약서" 같은 질의를 더 잘 처리할 수 있다. +- PGVector는 의미 검색을 맡고, 메타 조건은 SQL이 맡고, related/tags는 연결 탐색을 맡는다. +- 결과적으로 "단순 벡터 검색"보다 훨씬 정교한 근거 회수와 응답 합성이 가능해진다. + +## 8. 이번 단계에서 보류해야 할 것 + +- 모든 파일에 전수 OCR +- 모든 파일에 전수 LLM 요약 +- 별도 그래프 DB를 즉시 도입하는 것 +- 원본 형식별 완벽 보존을 목표로 지나치게 복잡한 파서 체인을 먼저 만드는 것 + +## 9. 추천 실행 순서 + +1. Markdown 중간표현 규칙 고정 +2. front matter 메타 스키마 고정 +3. PostgreSQL 기본 테이블과 JSONB 구조 고정 +4. OCR 선별 정책 고정 +5. 100~500개 파일로 샘플 검증 +6. 이후 배치 자동화와 증분 동기화로 확대 + +## 10. 관련 문서 + +- [Markdown 중간표현 SSOT 설계 리서치](./260320_MD_중간표현_SSOT_설계_리서치.md) +- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md) +- [OCR 선별 적용 정책 리서치](./260320_OCR_선별적용_정책_리서치.md) +- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md) +- [PostgreSQL 그래프 확장 설계 리서치](./260320_PostgreSQL_그래프확장_설계_리서치.md) diff --git a/journey/research/rag/README.md b/journey/research/rag/README.md new file mode 100644 index 0000000..0fdec8a --- /dev/null +++ b/journey/research/rag/README.md @@ -0,0 +1,36 @@ +--- +tags: [research, rag, robeing, index] +--- + +# RAG 리서치 인덱스 + +## 목적 + +- 로빙이 PDF, HWP, DOCX, XLSX, PPTX, JPG, PNG, 동영상 등 여러 형식의 데이터를 읽고 처리하는 방식을 리서치 단위로 분리 정리한다. +- 문서 중간표현, 메타데이터, OCR, 벡터 검색, PostgreSQL 기반 그래프 확장까지 단계별로 분리해 SSOT 후보를 만든다. +- 아직 구현·운영에서 완전히 고정되지 않은 내용은 `research`에 두고, 반복 검증된 것만 `plans`, `worklog`, `0_VALUE`로 승격한다. + +## 2026-03-20 추가된 문서 + +- [다형식 문서 RAG 자동수집·정규화 전략 리서치](./260320_다형식문서_RAG_자동수집_정규화_전략_리서치.md) +- [Markdown 중간표현 SSOT 설계 리서치](./260320_MD_중간표현_SSOT_설계_리서치.md) +- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md) +- [OCR 선별 적용 정책 리서치](./260320_OCR_선별적용_정책_리서치.md) +- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md) +- [PostgreSQL 그래프 확장 설계 리서치](./260320_PostgreSQL_그래프확장_설계_리서치.md) + +## 읽는 순서 추천 + +1. 전체 방향: `다형식문서 RAG 자동수집·정규화 전략` +2. 중간표현 원칙: `MD 중간표현 SSOT 설계` +3. 메타데이터 범위: `Front Matter 메타데이터 설계` +4. 비용 절감 정책: `OCR 선별 적용 정책` +5. 실제 저장 구조: `PGVector·JSONB RAG 스키마 설계` +6. 연결성 확장: `PostgreSQL 그래프 확장 설계` + +## 이번 묶음의 핵심 결론 + +- 원본 파일은 보존하고, 로빙이 읽는 중간표현은 `파일 1개 : MD 1개` 구조를 기본으로 잡는다. +- 검색용 메타와 운영용 메타는 front matter와 PostgreSQL JSONB에 동시에 반영 가능한 형태로 설계한다. +- OCR과 LLM은 전수 적용이 아니라 선별 적용으로 비용과 시간을 제어한다. +- 벡터 검색, 키워드 검색, 문서 연결 탐색은 분리하지 않고 PostgreSQL 중심으로 묶는 편이 현재 로빙 운영에 가장 실용적이다.