ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
DOCS/journey/research/rag/260320_MD_중간표현_SSOT_설계_리서치.md
happybell80 21b0d5b9ce close: RAG 열린 문서 8/10 닫기 — 200개 기준 구현 완료 
- 아이디어 1: 계획 1~3차 + 적용1로 채택 완료
- 2차 계획: PGVector 적재 + tsvector + 하이브리드 + AGE 구현 완료
- 리서치 6: 설계 목적 달성, Unresolved는 후속 문서로 이관
- 남은 열린 문서: 1차 계획(본문 미추출), 3차 계획(OCR/동기화)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-22 09:07:48 +09:00

4.3 KiB
Raw Blame History

tags, type, status, closed_date, closed_reason, research_target
tags type status closed_date closed_reason research_target
research
rag
robeing
markdown
ssot
intermediate-format
research closed 2026-03-22 설계 목적 달성, 200개 대상 구현 완료, Unresolved는 3차 계획 또는 후속 문서로 이관 다형식 원본을 위한 Markdown 중간표현 SSOT 규칙 정리

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, 요약, 태그는 후속 배치로 누적하는 구조가 좋다.

현재 상태 보정 (2026-03-22)

  • MD 파생본: 48,906개 생성 완료. 본문 text_length: 0이 48,744건(99.7% 미추출).
  • NAS 원본: /mnt/nas/workspace/6.Company X — 53,249파일.
  • OCR: 미구현. 본문 채움의 핵심 과제가 여전히 열려 있다.
  • DB 적재: team_document 1,174건 / team_document_chunk 3,474건 (임베딩: Gemini Embedding 2, 768d).

Unresolved

  • 99.7% 본문 미추출 상태를 어떤 우선순위와 배치로 해소할지 아직 정해지지 않았다.
  • 원본 53,249건과 MD 48,906건의 차이를 설명하는 실패/스킵 기준이 문서화되지 않았다.

10. 관련 문서