최영선의 블로그

완성된 수집 파이프라인은 각 단계를 더 많이 붙이는 구조가 아니라 각 단계의 입출력이 이어지는 구조입니다. 시리즈 마지막 글에서는 조각별 예제를 하나의 실제 흐름으로 이어 붙입니다. 이제 중요한 것은 개별 함수보다도 단계 간 계약이 끊기지 않는지입니다.이번 예제는 세 포맷을 읽고, 청크를 만들고, 오프라인 임베딩으로 FAISS를 저장한 뒤 다시 로드해서 검색 결과를 확인합니다. 이 정도면 ingestion MVP가 끝까지 한 번 돈 것입니다.엔드투엔드 수집 파이프라인마지막 글의 핵심은 각 단계의 세부 구현보다도 앞 단계 출력이 다음 단계 입력으로 자연스럽게 이어지는지 확인하는 데 있습니다.단계별 검증 체크포인트체크포인트를 적게 두더라도 단계 경계마다 숫자와 경로를 하나씩 남기면 원인 추적 속도가 크게 빨..

다중 포맷 파이프라인의 본질은 다양한 입력을 하나의 Document 계약으로 수렴시키는 일입니다. 실제 문서 수집은 PDF만 다루지 않습니다. 운영 노트는 TXT로, 팀 런북은 Markdown으로, 외부 자료는 PDF로 들어오는 경우가 흔합니다.이번 예제는 세 포맷을 각각 읽되 최종 출력은 모두 같은 Document 구조로 맞춥니다. 그래야 이후 청킹과 인덱싱 단계가 포맷 차이를 의식하지 않아도 됩니다.포맷별 로더 라우팅 흐름다중 포맷 지원의 출발점은 로더를 많이 만드는 일보다 라우팅 책임을 한곳에 모으는 일입니다.포맷별 전처리 분기 구조포맷별 전처리는 서로 달라도 마지막 출력이 같은 본문 문자열 계약으로 수렴해야 후속 단계가 단순해집니다.실행 예제# pyright: reportMissingImports..

증분 인덱싱은 벡터 DB 기술이라기보다 파일 상태를 기억하는 운영 자동화 문제입니다.문서가 수십 개일 때는 전체 재처리도 견딜 수 있지만, 수천 개가 되면 매 실행마다 같은 비용을 내는 구조가 병목이 됩니다.이번 예제는 해시와 JSON 상태 파일만으로 added, unchanged, updated를 구분합니다. 먼저 이 단순한 기준을 확실히 이해해야 이후에 벡터 저장소 업데이트도 깔끔해집니다.증분 스캔과 변경 감지 흐름증분 인덱싱의 핵심은 파일을 읽는 비용보다 먼저 어떤 파일이 다시 처리 대상인지 좁히는 데 있습니다.상태 저장소와 해시 비교 구조mtime만 보는 방식보다 해시 비교를 같이 넣으면 운영에서 오탐과 누락을 줄이기 쉽습니다.실행 예제from __future__ import annotations..