최영선의 블로그

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

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

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

메타데이터는 본문을 설명하는 부가 정보라기보다 검색 후보군을 줄이는 첫 번째 인덱스입니다. RAG 검색이 생각보다 엉뚱한 결과를 내는 가장 흔한 이유는 “비슷한 내용”과 “찾고 싶은 범위”를 분리하지 않았기 때문입니다. 분기, 문서 종류, 출처 같은 조건은 임베딩만으로 깔끔하게 처리되지 않습니다.이번 예제는 작은 문서 세 개를 FAISS에 넣고, filter 파라미터로 category와 quarter를 바꾸면서 검색 결과가 어떻게 달라지는지 확인합니다.메타데이터 스키마 설계검색 스키마는 필드 수를 늘리는 일이 아니라 실제로 후보군을 줄일 키를 좁혀 가는 일에 가깝습니다.필터가 후보군을 줄이는 흐름의미상 비슷한 청크가 많아도 필터가 먼저 범위를 좁혀 주면 검색 결과가 훨씬 덜 흔들립니다.실행 예제from ..

청킹은 텍스트를 잘게 자르는 작업이 아니라 검색이 버틸 수 있는 문맥 단위를 설계하는 작업입니다.청킹을 한 번 잘못 잡으면 뒤 단계가 모두 비효율적이 됩니다. 너무 작으면 답변 맥락이 잘리고, 너무 크면 검색 결과에 잡음이 섞입니다.이번 예제는 FAQ, 매뉴얼, 정책 문서 세 가지 텍스트를 같은 분할기로 돌려 보고, 문서 유형별 프리셋이 왜 필요한지 숫자로 보여줍니다.문서 유형별 청킹 전략 흐름같은 분할기를 쓰더라도 문서 유형마다 경계와 겹침의 기본값을 다르게 잡아야 검색 잡음을 줄일 수 있습니다.재귀 분할기 구분자 후퇴 순서재귀 분할기의 장점은 의미 있는 큰 경계를 먼저 살려 보고, 안 되면 더 작은 경계로 천천히 내려간다는 점입니다.실행 예제from __future__ import annotation..

PDF 파싱의 첫 목표는 “보이는 문서”를 “검증 가능한 문자열 목록”으로 바꾸는 것입니다.실무에서 PDF 파싱 예제를 설명할 때 가장 먼저 막히는 부분은 샘플 파일입니다. 저장소에 PDF를 커밋하지 않아도 글만 보고 바로 실행할 수 있어야 재현성이 생깁니다.이번 예제는 reportlab으로 PDF를 스크립트 안에서 만들고, pypdf로 다시 읽어서 페이지별 텍스트와 문자 수를 출력합니다. 문서 수집 파이프라인의 출발점으로 딱 맞는 구조입니다.PDF 파싱 흐름입문 예제에서는 생성과 추출을 한 스크립트에 넣어 두면 입력 재현성과 출력 검증이 동시에 잡힙니다.페이지 구조와 추출 포인트 같은 PDF라도 텍스트, 표, 이미지가 섞여 있으므로 추출 전략을 한 가지로 고정하면 품질 차이를 놓치기 쉽습니다.실행 예제..

벡터 검색 101 시리즈 (6/6)예제 코드: github.com/yeongseon-books/vector-search-101지금까지 임베딩, 유사도 계산, FAISS, 청킹을 각각 따로 다뤘습니다. 이번 글에서는 이 부품들을 하나의 실행 가능한 파이프라인으로 조립합니다. 문서 파일을 불러오고, 청크로 나누고, 임베딩하고, FAISS 인덱스에 저장하고, 자연어 쿼리로 검색하는 전체 흐름입니다.마지막에는 키워드 검색과 벡터 검색을 결합한 하이브리드 검색의 기본 개념도 살펴봅니다.다룰 내용은 다음과 같습니다.텍스트 파일에서 문서 불러오기청킹 → 임베딩 → FAISS 인덱스 구축 전체 흐름인덱스 저장과 불러오기자연어 쿼리로 검색하고 결과 출력하기하이브리드 검색 개념과 기본 구현 이 장의 핵심: 벡터 검색 파이..

벡터 검색 101 시리즈 (5/6)예제 코드: github.com/yeongseon-books/vector-search-101임베딩 모델은 처리할 수 있는 토큰 수에 한계가 있습니다. all-MiniLM-L6-v2는 최대 256 서브워드 토큰입니다. PDF 한 페이지만 해도 이 한계를 금방 넘습니다. 긴 문서를 통째로 임베딩하면 잘려서 중요한 내용이 날아가거나, 너무 많은 정보가 한 벡터에 압축되어 검색 정확도가 떨어집니다.청크(chunk)는 긴 문서를 임베딩 가능한 크기의 단위로 나눈 것입니다. 어떻게 나누느냐가 검색 품질에 직접 영향을 줍니다. 청크가 너무 작으면 문맥이 끊기고, 너무 크면 관련 없는 내용이 섞입니다.이번 글에서 다룰 내용은 다음과 같습니다.청크 크기와 오버랩의 기본 개념고정 크기 청..

벡터 검색 101 시리즈 (4/6)예제 코드: github.com/yeongseon-books/vector-search-101문서가 수천, 수만 건이 되면 NumPy 브루트 포스 검색은 느려집니다. 차원이 384인 벡터 10만 개를 쿼리 한 번에 비교하려면 3,840만 번의 곱셈이 필요합니다. 검색 지연이 수백 밀리초에서 수 초로 늘어나면 실제 서비스에 쓰기 어렵습니다.FAISS(Facebook AI Similarity Search)는 이 문제를 푼 라이브러리입니다. 정확도를 조금 희생해서 속도를 크게 높이는 근사 최근접 이웃(ANN) 검색을 지원합니다. 10억 개 규모 벡터도 처리할 수 있고, C++로 작성되어 있어서 CPU와 GPU 모두에서 빠릅니다.이번 글에서 다룰 내용은 다음과 같습니다.FAISS..

벡터 검색 101 시리즈 (3/6)예제 코드: github.com/yeongseon-books/vector-search-101벡터를 만들었다면 다음 질문은 "어떻게 비교하는가"입니다. 벡터 간 거리를 재는 방법은 여러 가지이고, 어떤 척도를 쓰느냐에 따라 검색 결과가 달라집니다. 코사인 유사도가 가장 널리 쓰이지만, 내적(dot product)과 유클리드 거리(L2)가 더 적합한 상황도 있습니다.이번 글에서는 세 가지 거리 척도를 직접 계산해 보고, 정규화가 왜 중요한지, 그리고 브루트 포스 방식으로 최근접 이웃을 찾는 방법까지 다룹니다.코사인 유사도, 내적, 유클리드 거리 직접 구현정규화와 거리 척도의 관계브루트 포스 최근접 이웃 검색 구현실제 쿼리를 입력해 검색 결과 확인하기각 척도를 언제 쓸 것인가..