3.8 KiB
3.8 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방향은 설계가 아니라 현재 운영 코드와 문서가 함께 따라가야 하는 실제 기준이 됐다.- 따라서 이 아이디어 문서는 신규 구상보다
왜 이 구조를 유지하는가를 설명하는 상위 맥락 문서로 읽는 편이 맞다.
단계 구분
1차
- 원본 스캔
- 파일별 MD 생성
- front matter 최소 메타 생성
- 요약/설명 기본값 생성
2차
- PostgreSQL 적재
- JSONB 메타 관리
- 청크 분리
- PGVector 임베딩/검색 붙이기
3차
- OCR 선별 적용
- 문서 관계 확장
- 동기화 자동화
- 품질 측정 및 재처리 정책화
로빙 적용 1
- 로빙 질의 경로에 이 저장 계층을 실제 연결한다.
- 질문이 들어왔을 때 메타 필터 + 벡터 검색 + 관계 확장을 거쳐 근거 문서를 회수하는 최소 폐회로를 만든다.