• 목록

벡터 검색 결과가 기대와 다를 때 임베딩 모델부터 바꾸기 쉽습니다. 하지만 검색 대상이 잘못 제한되어 있거나 필터가 예상과 다른 단계에서 적용되면 좋은 문서가 후보에 들어오지 못할 수 있습니다.

검색 범위를 정하는 조건과 후보의 유사도를 비교하는 일을 나누어 살펴봅니다.

AI 생성 삽화 · 벡터 검색의 필터와 유사도, 검색 범위를 먼저 이해하기 주제를 설명하는 이미지입니다.

핵심 정리
필터는 검색 대상의 조건을 정하고 유사도는 후보의 가까움을 비교합니다. 필터가 적용되는 위치와 메타데이터 상태를 확인한 뒤 결과 수와 관련성을 함께 평가해야 합니다.

1. 검색할 수 있는 문서부터 정의합니다

사내 문서 검색을 가상으로 생각하면 공개 여부와 언어, 문서 유형 등 조건이 있을 수 있습니다. 이 조건은 질문과 문장의 의미가 얼마나 비슷한지와 다른 문제입니다.

한국어 안내문만 보여 주려는 서비스라면 문서 언어 정보가 정확하게 저장되어 있는지부터 확인해야 합니다. 의미가 가까운 영어 문서가 검색되었다고 임베딩이 반드시 잘못된 것은 아닙니다.

원하는 범위를 요청에 표현했는지 먼저 볼 필요가 있습니다. 필터를 설명할 때는 사용자가 선택한 조건과 서버가 반드시 적용해야 하는 조건을 나누어 적습니다.

권한과 관련된 조건을 사용자가 보낸 값만 믿고 정하는 구조는 피해야 합니다. 검색 기능의 필터를 넣었다는 사실만으로 접근 통제가 완성되었다고 판단하지 않고 인증된 사용자와 문서 접근 정책을 별도로 검증하는 설계가 필요합니다.

2. 유사도는 대상 안에서의 순서를 설명합니다

벡터 검색은 표현된 벡터의 가까움을 바탕으로 후보를 찾는 방식입니다. 범위를 좁혔다고 그 안에 질문의 답이 반드시 있는 것은 아닙니다.

Elastic의 kNN 안내도 조건에 맞는 후보 중 가까운 문서를 찾더라도 그 문서들이 충분히 관련 있지 않을 수 있음을 설명합니다. 따라서 결과가 몇 개 나왔다는 사실과 유용한 답을 찾았다는 사실을 나누어 봐야 합니다.

학습용 예로 여행 규정 문서만 남겨 두고 장비 반납을 질문하는 상황을 생각할 수 있습니다. 제한한 범위 자체에 답이 없다면 상대적으로 가까운 문서가 나와도 목적을 충족하지 못합니다.

결과 점수만 볼 것이 아니라 원문이 실제 질문을 해결하는지 확인해야 합니다. 점수의 해석도 사용하는 거리 함수와 제품의 점수 변환 방식에 따라 달라질 수 있으므로 다른 시스템의 숫자와 바로 비교하지 않습니다.

3. 사전 필터와 사후 필터를 구분합니다

필터 조건을 검색 과정에 반영하는 방식과 가까운 후보를 먼저 찾은 뒤 조건에 맞지 않는 결과를 제거하는 방식은 결과 수가 다를 수 있습니다. Elastic의 kNN 문서는 이 차이를 사전 필터와 사후 필터로 설명하며, 필터를 지정한 위치에 따라 동작이 달라지는 경우를 보여 줍니다.

같은 필터 문장을 넣었다고 적용 단계도 같을 것이라고 생각하지 않는 것이 좋습니다. 여기서 사전이라는 말은 모든 엔진이 반드시 전체 데이터를 먼저 물리적으로 분리한다는 뜻은 아닙니다.

검색 중 조건을 반영하는 구체적인 방법은 구현에 따라 확인해야 합니다. 사용하는 API에서 필터를 어디에 넣어야 하는지 공식 문서를 읽고 실제 결과를 점검합니다.

특정 제품의 쿼리 구조를 다른 벡터 데이터베이스에 그대로 옮기면 의미가 달라질 수 있으므로 개념과 문법을 구분해 학습합니다.

4. 가상 문서 여섯 개로 차이를 확인합니다

가상 후보 여섯 개를 유사도 순서로 적고 첫 세 문서 중 한 개만 한국어라고 가정해 봅니다. 먼저 세 개를 고른 뒤 한국어만 남기면 한 개가 남습니다.

반면 한국어 조건을 충족하는 후보 안에서 세 개를 찾는 과제는 다른 결과를 요구합니다. 이는 제품 벤치마크가 아니라 후보 선택 순서를 보여 주기 위한 직접 만든 예시입니다.

실제 근사 검색은 탐색 예산과 인덱스 조건의 영향도 받으므로 이 작은 목록이 구현 전체를 설명하지는 않습니다. 예시를 확장할 때는 조건에 맞는 문서가 아예 두 개뿐인 상황도 만들어 볼 수 있습니다.

이때 세 개를 요청했다는 이유만으로 세 결과를 보장할 수는 없습니다. 결과가 부족한 이유를 필터 통과 문서 수와 검색 설정, 관련성 조건으로 나누어 생각하는 연습이 중요합니다.

5. 메타데이터 갱신이 빠졌는지 확인합니다

문서 본문을 수정했더라도 언어와 공개 상태, 문서 버전 같은 메타데이터가 예전 값이면 필터 결과가 기대와 달라질 수 있습니다. 이 부분은 모델 성능 문제와 구분해서 조사해야 합니다.

검색 요청에 사용된 조건과 실제 색인된 필드 값을 한 문서씩 대조하는 방법을 생각할 수 있습니다. 날짜 조건을 쓴다면 생성일과 수정일 중 어느 필드인지 이름만으로 혼동하지 않습니다.

이 글의 점검 순서는 운영 설계를 위한 제안이며 모든 시스템에 같은 필드가 있다는 뜻은 아닙니다. 데이터가 없는 값과 빈 문자열을 어떻게 다루는지도 사용 중인 시스템에서 확인합니다.

문서를 여러 조각으로 나눴다면 각 조각에 필요한 조건이 연결되어 있는지 검토합니다. 원문만 수정하고 검색용 자료가 갱신되지 않은 경우를 구별할 수 있도록 버전 정보를 남기는 편이 좋습니다.

6. 평가에서는 결과 수와 답의 적합성을 따로 적습니다

검색 실험을 할 때는 질문, 필터 조건, 요청한 수량, 실제 결과 수, 정답에 도움이 된 문서를 함께 기록할 수 있습니다. 조건을 바꾼 실험과 임베딩을 바꾼 실험을 동시에 진행하면 개선 원인을 구분하기 어렵습니다.

먼저 같은 질문과 같은 자료로 한 요소씩 비교하는 편이 설명하기 쉽습니다. 관련 문서가 필터 밖에 있었는지, 후보에는 들어왔지만 순위가 낮았는지 구분하면 다음 작업이 달라집니다.

생성형 답변을 연결한 서비스라면 검색 단계의 원문도 별도로 확인합니다. 최종 답변이 매끄럽다는 이유만으로 검색이 정확했다고 판단하지 않습니다.

가상 평가표에는 관련 문서 없음이라는 결과도 남길 수 있어야 합니다. 무조건 답변을 만드는 것이 목적이 아니라 어떤 범위에서 어떤 근거를 찾았는지 확인하는 것이 평가의 출발점입니다.

7. 검색 결과가 줄었을 때 범위를 임의로 풀지 않습니다

결과 수가 적다는 이유로 필수 조건을 제거해 다시 검색하는 방식은 신중하게 설계해야 합니다. 특히 접근 범위를 정하는 조건과 사용자가 선택한 편의 조건은 다르게 다뤄야 합니다.

필수 조건을 유지한 채 검색 결과가 부족하다고 안내하거나 허용된 범위 안에서 질문을 구체화하는 흐름을 생각할 수 있습니다. 이 부분은 이 글에서 제안하는 설계 원칙이며 특정 제품의 자동 동작을 설명하는 것은 아닙니다.

개발 기록에는 어떤 조건을 바꿀 수 있고 어떤 조건은 유지해야 하는지 적습니다. 디버깅용으로 필터 없는 결과를 확인할 때도 접근 권한과 데이터 취급 범위를 지켜야 합니다.

벡터 검색을 개선하는 일은 유사도 모델만의 문제가 아닙니다. 대상 범위와 데이터 상태, 후보 선택 과정을 함께 이해해야 결과가 왜 나왔는지 설명할 수 있습니다.

8. 자주 묻는 질문

Q1. 필터가 정확하면 검색 결과도 정확한가요?

필터는 대상 조건을 맞추는 역할입니다. 조건에 맞는 문서 안에 답이 있는지와 유사도 순위가 적절한지는 별도로 평가해야 합니다.

Q2. 결과를 다섯 개 요청했는데 적게 나오는 이유는 뭔가요?

조건을 통과한 문서 수와 필터 적용 단계, 관련성 조건 등을 확인해야 합니다. 요청 개수만으로 항상 같은 수의 결과가 나온다고 가정하지 않습니다.

Q3. 필터를 넣으면 검색이 항상 빨라지나요?

구현과 검색 방식에 따라 다릅니다. Elastic 문서는 근사 검색에서 필터가 탐색 부담을 늘리는 경우도 설명하므로 실제 조건에서 측정해야 합니다.

Q4. 권한 조건도 검색창에서 받은 값을 쓰면 되나요?

사용자 입력만으로 접근 범위를 결정해서는 안 됩니다. 인증된 사용자와 서버의 접근 정책을 기준으로 필수 조건을 적용하고 별도로 검증해야 합니다.

참고 자료

• Elastic: kNN search와 필터
• Elastic: kNN query의 사전·사후 필터