Claude

TL;DR: LLM에게 “어디부터 어디까지"만 묻고, 텍스트는 서버가 직접 꺼내면 됩니다. 3페이지 실측 기준 Output 토큰 90% 감소, 레이턴시 87% 감소, 비용 61% 절감. 배경: Docling에서 PyMuPDF + VLM으로 건축 법규 검토 AI를 만들면서, 건축 고시/지침 PDF를 의미 단위의 청크(chunk)로 나눠야 했습니다. RAG 파이프라인의 검색 단위로 사용하기 위해서입니다. 처음에는 IBM의 Docling을 사용했습니다. OCR 모델로 문서 구조를 파악한 뒤 청킹하는 방식인데, 두 가지 문제가 있었습니다: 무거움: OCR·레이아웃 분석 모델(RT-DETR 등)이 포함되어 Docker 이미지 크기와 처리 시간이 큼 커스텀 어려움: 내부 파이프라인이 블랙박스에 가까워, 건축 문서 특유의 계층 구조(장 > 조 > 항 > 호)나 표 처리를 세밀하게 제어하기 어려움 그래서 OCR 모델을 걷어내고 PyMuPDF로 텍스트와 폰트 메타데이터를 직접 추출하는 방식으로 전환했습니다. 구조 분석은 멀티모달 LLM(VLM)의 Vision 기능으로 대체하면 OCR 의존성을 완전히 제거하면서도 커스텀이 자유롭습니다. ...

건축 법규검토 AI에서 “4층 이하"와 “4층 이상"을 혼동하면 어떻게 될까? 높이 상한이 뒤집혀 불법 건축물이 합법으로 판정된다. 이 글은 그 한 글자 차이를 잡기 위한 여정이다. 문제: PDF 표가 검색되지만 신뢰하기 어렵다 건축 법규검토 시스템은 지구단위계획 고시, 설계 지침서 등 건축 관련 PDF를 분석하여 건폐율, 용적률, 높이제한 등의 기준을 추출한다. PDF 전처리 파이프라인은 Docling을 사용해 문서를 파싱하고, 텍스트를 청킹한 후 임베딩을 생성하여 하이브리드 검색(키워드 + 시맨틱)을 지원한다. Docling의 HierarchicalChunker는 표 내용도 마크다운 형태로 청킹하여 검색 인덱스에 포함한다. 표가 아예 빠지는 건 아니다. 문제는 그 마크다운의 품질이었다. ...