docs: add multimodal rag research set

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)

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)

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)

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)

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)

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)

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 중심으로 묶는 편이 현재 로빙 운영에 가장 실용적이다.