PC 전체 임베딩, 파일을 모두 넣으면 검색도 좋아질까

PC의 자료를 한꺼번에 임베딩하면 오래된 문서도 질문 한 번에 찾을 수 있을까. 한 커뮤니티에서는 전체 파일을 대상으로 작업한 뒤 업무가 편해졌다는 경험과 함께 중복 파일과 검색 결과가 뒤섞이지 않느냐는 질문이 나왔다. 핵심은 얼마나 많이 넣었느냐보다 질문에 맞는 원문을 다시 찾아낼 수 있느냐다.

임베딩은 파일 전체를 기억시키는 작업이 아니다

임베딩은 추출한 텍스트를 의미 검색에 쓸 수 있는 숫자 벡터로 바꾼다. 답변할 때는 질문과 가까운 문서 조각을 찾아 모델에 전달한다. Open WebUI의 RAG 설명도 문서 분할, 임베딩, 벡터 저장, 관련 조각 검색을 별도 단계로 구분한다. PC의 모든 내용이 매번 모델에 들어가는 방식은 아니다. (docs.openwebui.com)

이 차이를 놓치면 기대가 어긋난다. 검색 후보에 들어간 파일도 해당 질문에서 선택되지 않으면 답변의 근거가 되지 않는다. 실제 사용자들 사이에서도 자료를 넣었는데 일부 문서가 답에서 빠진다는 불만이 있다. 다만 개별 경험만으로 특정 제품의 검색 성능을 일반화할 수는 없다.

시작점은 ‘PC 전체’라는 범위가 아니다. 제안서 초안을 찾으려는지, 지난 프로젝트의 결정 이유를 확인하려는지부터 정해야 한다. 두 질문은 필요한 폴더와 검색 기준이 다르다. 커뮤니티에서 전체 인덱스가 유용했다는 의견은 참고할 만하다. 다만 어떤 질문에서 효과가 났는지까지 확인된 사례는 아니다.

파일은 추출하고 걸러낸 뒤 임베딩한다

재현 가능한 입력은 문서가 모인 폴더와 그 안의 PDF, Markdown, 텍스트 파일이다. Open WebUI에서는 Workspace의 Knowledge에서 지식베이스를 만들고 파일을 추가할 수 있다. 지원되는 환경에서는 로컬 디렉터리를 동기화해 변경된 파일만 다시 처리하는 방식도 제공한다. 개인 개발자라면 우선 하나의 업무 폴더로 입력 범위를 좁혀 시험할 수 있다. (docs.openwebui.com)

순서는 파일 선정, 텍스트 추출, 문서 분할, 임베딩, 검색 시험이다. 스캔 PDF처럼 본문이 이미지라면 글자가 추출되는지 먼저 확인해야 한다. Open WebUI의 문제 해결 문서는 이런 경우 OCR을 포함한 추출 방식 점검을 안내한다. 텍스트가 비어 있다면 임베딩 설정을 바꿔도 찾을 본문이 없다. (docs.openwebui.com)

전처리는 모든 문서를 사람이 다시 편집하라는 말이 아니다. 우선 임시 파일과 불필요한 사본을 빼고 검색 결과에 표시할 파일명과 원본 위치를 유지한다. 그다음 질문에 답하는 문단이 통째로 잘리지 않는지 분할 결과를 살핀다. Open WebUI 문서에 따르면 분할 설정을 바꾼 뒤 기존 지식베이스에 반영하려면 재인덱싱을 고려해야 한다. (docs.openwebui.com)

민감한 자료라면 ‘내 PC에서 실행한다’는 설명만 믿어서는 안 된다. Open WebUI는 채팅 모델이 로컬이어도 추출기나 임베딩 제공자는 별도로 설정될 수 있다고 명시한다. 파일을 넣기 전에 각 단계의 처리 위치를 확인해야 한다. (docs.openwebui.com)

중복 파일은 넣기 전과 찾은 후에 다룬다

같은 문서의 복사본이나 수정본이 많으면 비슷한 조각이 검색 후보를 차지할 수 있다. 먼저 동일 파일을 식별하고 수정본은 서로 다른 문서로 남길지 결정하는 편이 명확하다. LlamaIndex의 ingestion pipeline은 문서 ID와 해시를 비교한다. 동일 ID에 변경이 없으면 처리를 건너뛰고 내용이 바뀌면 다시 처리하는 방식을 문서화했다. (docs.llamaindex.ai)

해시 중복 제거와 검색 결과 정리는 다른 일이다. 글자가 조금 다른 두 회의록은 동일 파일로 판정되지 않아도 검색에서는 거의 같은 답을 줄 수 있다. 이때는 결과에 원본 파일과 작성 시점이 드러나야 수정본을 가려낼 수 있다. 커뮤니티에서 나온 ‘검색 결과와 임베딩 자료가 겹치지 않느냐’는 의문도 이 단계의 문제로 풀어야 한다.

검색 결과가 겹친다고 무조건 하나만 남길 수는 없다. 초안과 최종본의 차이를 묻는 질문에는 둘 다 필요하다. 반대로 현재 유효한 계약 문구를 묻는다면 예전 초안이 앞에 나오는 상황을 피해야 한다. 어떤 버전을 우선할지는 임베딩 자체가 아니라 파일 선정과 검색 조건에서 정한다.

도메인 분류는 질문의 범위를 좁힌다

커뮤니티에서는 질문의 표현을 활용하면서 업무 영역별 기억을 나눠 다듬는 방식이 언급됐다. 구현할 때는 먼저 프로젝트별 지식베이스를 나누거나 문서에 프로젝트·자료 종류 같은 메타데이터를 붙일 수 있다. 질문이 들어오면 해당 범위에서 찾고 필요한 경우 다른 범위로 넓힌다. 모든 기록을 하나의 검색 결과 목록에서 경쟁시키는 방식과는 차이가 있다.

다만 의미 검색만으로 파일명, 제품 번호, 정확한 문구까지 안정적으로 찾는다고 기대할 수는 없다. Qdrant는 의미를 찾는 dense 검색과 정확한 단어를 찾는 sparse 검색을 함께 쓰는 하이브리드 검색을 설명한다. Open WebUI 역시 설정에 따라 키워드 검색과 벡터 검색, 재정렬을 결합한다. 고유명사가 많은 업무 폴더라면 두 검색 방식의 결과를 따로 비교할 이유가 있다. (qdrant.tech)

코딩 에이전트가 검색 도구를 쓴다면 또 하나의 경계가 생긴다. 에이전트가 어느 지식베이스를 검색할지 선택할 수 있어도 실제로 검색하지 않은 파일은 근거가 아니다. Open WebUI 문서는 도구 호출 방식에 따라 모델이 지식베이스를 검색할지 결정한다고 설명한다. 답이 유창한지보다 검색한 원문이 질문에 맞는지 살펴야 한다. (docs.openwebui.com)

반복 질문은 시스템의 학습보다 검색 시험에 가깝다

질의응답을 되풀이하며 구성을 조정한다는 커뮤니티 경험은 실용적이다. 다만 질문을 여러 번 한다고 임베딩 모델이 자동으로 개인 파일을 학습하는 것은 아니다. 질문과 기대하는 원문을 짝지어 놓고 검색 결과에 그 원문이 나타나는지 확인하는 시험으로 이해하는 편이 정확하다.

가령 ‘지난 제안서에서 납기를 바꾼 이유’와 ‘최종 납기일’을 따로 물어본다. 전자는 관련 맥락을, 후자는 정확한 버전의 문구를 찾아야 한다. 원하는 원문이 빠졌다면 답변 문체보다 파일 추출, 검색 범위, 중복, 키워드 검색을 먼저 점검한다. 원문은 찾았는데 답이 다르면 그때 모델에 전달된 문맥을 살핀다.

작은 팀에서 중요한 산출물은 거대한 벡터 저장소 자체가 아니다. 자주 묻는 질문마다 어떤 파일이 근거였고 어떤 질문에서 빠졌는지를 확인할 수 있는 검색 체계다. ‘전체 작업의 약 60%’라는 커뮤니티의 진행 상황도 완성도나 정확도 수치로 읽을 수 없다. PC 전체 임베딩의 성패는 남은 파일 수보다 다음 질문에 필요한 원문을 제대로 가져오는지에 달려 있다.