- 리서치 6건 + 1차 계획 + 아이디어: 현재 상태 보정 섹션 통일 - tsvector/하이브리드/AGE 구현 완료 반영, DB 수치 갱신 - 설계 별칭-운영 실체 매핑 명시, Unresolved 보강 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4.0 KiB
4.0 KiB
tags, type, status, adopted_by
| tags | type | status | adopted_by | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
ideas | open | 260320_다형식문서_RAG_1차_MD_메타_정규화_계획.md, 260320_다형식문서_RAG_2차_PGVector_JSONB_적재_계획.md, 260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md |
260320 다형식문서 자동지식화 RAG 파이프라인 아이디어
목적
- 로빙이 회사의 대량 파일 자산을 읽고, 정리하고, 검색하고, 답변 근거로 사용할 수 있는 자동 지식화 파이프라인의 큰 그림을 고정한다.
- 대상은 PDF, HWP, DOCX, XLSX, PPTX, JPG, PNG, 동영상 등 다형식 파일 전체다.
- 이 아이디어 문서는 세부 기술 결정을 모두 확정하는 문서가 아니라,
왜 이 흐름으로 가는가를 한 장으로 묶는 용도다.
핵심 아이디어
- 원본 파일은 그대로 둔다.
- 각 원본 파일마다 대응하는 Markdown 파생본을 만든다.
- Markdown에는 front matter와 기본 설명, 요약, 처리 상태를 붙인다.
- PostgreSQL에서 JSONB, PGVector, 관계 테이블을 함께 써서
메타 + 벡터 + 연결성을 한 곳에서 관리한다. - 파일이 생성·수정·삭제되면 같은 흐름으로 다시 정리한다.
왜 이 구조가 맞는가
- 원본 파일 형식이 너무 다양해서, 로빙이 매번 원본 포맷에 직접 의존하면 운영이 무너진다.
- Markdown은 사람과 LLM이 동시에 읽기 쉬운 공통 중간표현이다.
- front matter와 JSONB 메타는 검색, 필터링, OCR 선별, 동기화 판단에 모두 재사용된다.
- PGVector는 의미 검색을 맡고, PostgreSQL 관계 구조는 연결 탐색을 맡는다.
- 이 구조는 지금 로빙의 범위에서 과하지 않고, 나중에 더 크게 키워도 버티는 방향이다.
현재 상태 보정 (2026-03-22)
로빙 적용 1은 별도 계획에서 이미 구현·검증 완료. 현재 열린 체인은1차/2차/3차와 관련 리서치.- PGVector + JSONB + tsvector + Apache AGE: 설계가 아니라 운영 실체.
- tsvector + GIN: 구현 완료. 하이브리드 검색 (vector + keyword + graph RRF): 구현 완료.
- Apache AGE: companyx_docs, document_graph 그래프 2개 운용 중.
- 임베딩: Gemini Embedding 2, 768d. team_document: 1,174건 / team_document_chunk: 3,474건.
- MD 파생본: 48,906개 (본문 text_length: 0이 48,744건, 99.7% 미추출). OCR: 미구현.
- 증분 동기화 자동화: 미구현 (수동 스크립트만).
- NAS 원본: /mnt/nas/workspace/6.Company X — 53,249파일.
단계 구분
1차
- 원본 스캔
- 파일별 MD 생성
- front matter 최소 메타 생성
- 요약/설명 기본값 생성
2차
- PostgreSQL 적재
- JSONB 메타 관리
- 청크 분리
- PGVector 임베딩/검색 붙이기
3차
- OCR 선별 적용
- 문서 관계 확장
- 동기화 자동화
- 품질 측정 및 재처리 정책화
로빙 적용 1
- 로빙 질의 경로에 이 저장 계층을 실제 연결한다.
- 질문이 들어왔을 때 메타 필터 + 벡터 검색 + 관계 확장을 거쳐 근거 문서를 회수하는 최소 폐회로를 만든다.