벡터 유사도 점수, AI 인용 확률로 읽어도 될까

벡터 유사도 점수가 높다는 이유만으로 원고의 AI 인용 가능성이 높다고 보고하지 않는다. 그 점수는 정한 임베딩 모델과 검색 대상에서 질문과 가까운 후보를 찾는 값이다. 후보 문서가 질문의 조건에 답하는지, 실제 답변이 어떤 문장을 근거로 사용했는지까지 확인해야 한다. 별도로 계산한 점수를 외부 AI의 내부 선택 확률로 바꾸어 쓰면 측정한 대상이 달라진다.

“무선 연결을 지원하는 휴대용 프로젝터를 콘센트 없이 쓸 수 있나요?”라는 질문을 가정하자. 무선 화면 연결을 설명한 문서는 주제가 비슷해도 전원 사용 조건에 답하지 않을 수 있다. 이 차이는 유사어를 더 넣거나 높은 점수의 문서만 고르는 것으로 확인되지 않는다. 아래 문서 비교는 설명용 설계이며 실제 제품의 사양·검색 결과·임베딩 점수를 계산한 사례가 아니다.

비슷한 후보를 찾는 값과 정확한 답을 나눈다

Azure AI Search는 같은 임베딩 모델이 만든 공간에서 질문 벡터와 가까운 문서 벡터를 찾고, 설정한 유사성 기준으로 후보를 정렬한다고 설명한다. 코사인은 벡터 사이의 각도에 관한 기준이다. 여기서 가까운 문서를 찾았다는 결과는 질문에 필요한 사실과 조건이 모두 들어 있다는 내용 검수를 대신하지 않는다.

무선 화면 공유의 소개가 후보에 들어왔다고 가정하면, 먼저 질문이 연결 방식과 전원 중 무엇을 확인하려는지 읽는다. 후보 본문에 대상 모델·전원 조건·예외가 있는지 대조한다. 다른 모델의 배터리 설명이나 일반적인 휴대성 표현은 대상 제품의 콘센트 없는 사용을 증명하지 않는다. 문서의 주제가 가까운지와 그 문장으로 답할 수 있는지는 별도 판단이다.

점수에 필요한 조건도 보존한다. 질문 원문, 임베딩 모델, 검색한 문서와 버전, 어떤 부분을 벡터로 만들었는지, 필터와 정렬 방식을 함께 남긴다. 다른 모델이나 문서 묶음에서 얻은 값이 커졌다고 바로 원고가 좋아졌다고 보고하지 않는다. 먼저 계산 대상과 비교 기준이 같은지 확인해야 한다.

같은 score라는 이름도 계산하는 단계가 다르다

Microsoft는 Azure의 코사인 기반 @search.score가 질문과 문서의 원래 코사인 값 자체가 아니라 정렬에 쓰기 위한 변환 값이라고 명시한다. “유사도”와 API가 반환한 “검색 점수”를 같은 숫자로 읽으면 이 구분이 사라진다. 점수를 받았을 때는 필드 이름뿐 아니라 검색 모드와 계산 정의를 확인한다.

혼합 검색에서는 텍스트와 벡터 등 여러 결과의 순위를 RRF로 결합한다. 이는 원래 코사인 값들을 그대로 평균한 결과가 아니다. 같은 @search.score 필드도 검색 방식에 따라 알고리즘과 크기가 다르다. 작은 혼합 점수를 큰 벡터 점수와 직접 비교해 덜 관련 있다고 판정할 수 없다.

RRF 점수는 결합하는 쿼리 수와 가중치 조건도 함께 읽어야 한다. 더 많은 결과 목록을 결합하거나 특정 벡터 결과의 비중을 바꾼 뒤 점수가 달라졌다면, 그 변화는 구성 변경의 영향을 포함한다. 원고의 내용이 바뀌지 않았는데 계산값이 커진 일을 내용의 개선이나 AI 인용 증가로 보고하지 않는다.

Semantic 재정렬은 후보 검색·혼합 뒤에 수행되며 @search.rerankerScore를 별도로 보고한다. 검색 점수와 재정렬 점수는 같은 척도가 아니므로 더해 하나의 인용 점수를 만들지 않는다. 어떤 단계의 값인지 알아야 후보를 더 찾을지, 찾은 자료의 의미와 조건을 다시 검토할지 정할 수 있다.

표는 Azure 공식 정의를 이해하기 위한 비교다. 모든 검색 서비스가 같은 필드·척도·절차를 쓴다는 뜻은 아니다. 다른 시스템의 점수를 평가할 때도 해당 문서에서 계산 대상·모드·조건을 읽고, 실제로 어떤 원문이 후보에 들어갔는지 확인한다. 정의를 모르는 값을 백분율로 바꾼다고 인용 확률이 되지는 않는다.

찾은 자료와 답변에 사용된 근거를 연결한다

Microsoft Foundry의 RAG 설명은 자료를 검색하고, 질문과 함께 모델에 제공한 뒤, 답변을 생성하는 흐름을 구분한다. 문서 제목·URL·파일 이름 같은 메타데이터는 출처 연결을 돕는다. 검색 후보의 점수, 모델에 넘긴 자료, 최종 답변의 출처 문장은 각각 다른 단계의 기록이다.

검색 목록에 있던 문서가 실제 모델 입력에 포함됐는지 확인할 수 있다면 그 자료를 대조한다. 이어 답변에서 어느 문장에 어떤 출처가 연결됐는지 읽는다. 문서가 검색됐다는 사실만으로 모든 내용이 사용됐다고 보거나, 출처 링크가 있다는 것만으로 질문의 조건에 정확히 답했다고 판단하지 않는다. 중간 자료를 받을 수 없다면 사용 여부를 추정으로 채우지 않는다.

Foundry는 검색이 무관하거나 불완전한 구절을 반환하면 근거를 제공해도 불완전하거나 부정확한 답이 나올 수 있다고 설명한다. 자료 준비·검색 설정·질문과 지시도 품질에 영향을 준다. 점수와 링크가 있어도 대상 모델·조건·예외를 잘못 가져온 답은 내용 검수에서 따로 확인해야 한다.

이 표에는 점수나 실제 제품의 결론을 만들지 않았다. 후보가 무엇이든 원자료의 해당 모델·조건이 확인돼야 답할 수 있다. 배터리 기능의 일반 설명이 발견됐는데 대상 모델 자료가 없다면, 그 일반 설명을 특정 제품의 사용 가능 판정으로 바꾸지 않는다. 필요한 자료가 없는 상태를 구체적으로 남기는 것이 점수만 높은 답보다 유용하다.

청크를 줄일 때는 답의 조건이 함께 남는지 본다

자체 검색 시스템에서 문서를 나누어 색인하는 일과 공개 웹 원고를 무조건 짧게 자르는 일도 구분한다. 어떤 단위를 검색 후보로 만들고 모델에 넘기는지에 따라 확인할 문맥이 달라진다. 주제 소개만 남고 모델·적용 범위·예외가 떨어져 나간 조각은 문장이 매끄러워도 질문에 잘못 적용될 수 있다.

프로젝터 안내를 나눈다면 무선 연결 설명과 전원 조건의 관계를 읽을 수 있는지 확인한다. 제목·대상 모델·앞뒤 조건과 원문 위치를 보존하고, 답에 필요한 다른 절로 연결할 수 있는지 본다. 더 작은 단위로 바꾼 뒤 어떤 후보가 들어오고 어떤 조건이 빠졌는지 평가해야 한다. 문장 수를 줄였다는 사실만으로 선택이 좋아졌다고 판단하지 않는다.

Google의 공개 지침은 AI를 위해 내용을 작은 조각으로 나눌 의무나 이상적인 페이지 길이가 없다고 설명한다. 독자가 읽기 쉬운 문단·절·제목을 권하며, 같은 뜻의 모든 질문 변형을 따로 만들 필요도 없다고 안내한다. 자체 인덱스의 청크 설정을 모든 공개 원고의 고정 문장 수 처방으로 옮기지 않는다.

자체 계산값을 외부 AI의 내부 지표로 바꾸지 않는다

Google은 외부 도구가 내부 순위·AI 시스템에 접근하지 못한다고 명시하고, 그런 내부 지표나 순위 성공을 주장하는 도구를 경계하라고 안내한다. 별도 임베딩 모델로 계산한 질문/원고의 유사도는 그 계산 범위의 자료다. 이를 Google 내부의 인용 선택 점수라고 제시하면 공식적으로 확인한 범위를 넘는다.

점수 기반 제안을 받으면 계산한 모델·대상 문서/구절·질문·검색 모드·비교 조건과 높은/낮은 후보 원문을 함께 받는다. 내용에서 무엇을 고쳐야 하는지도 문장 위치와 독자 질문으로 연결한다. “유사도를 높이자”는 목표만으로 전원 조건의 누락을 고칠지, 대상 모델을 바로잡을지, 새 원자료를 찾아야 할지 결정하기 어렵다.

자체 검색을 운영한다면 후보 검색의 평가와 최종 답의 평가를 나누어 계획할 수 있다. 질문에 필요한 문서가 후보에 들어왔는지, 모델에 필요한 조건이 제공됐는지, 답변의 결론과 출처가 맞는지 단계별로 읽는다. 후보 점수는 문제를 조사하는 자료로 쓰되, 실제 외부 AI 인용의 증가를 측정한 값처럼 보고하지 않는다. 이것은 앞으로의 평가 제안이며 이번에 실행한 실험이 아니다.

공개 원고는 독자가 알고 싶은 답과 그 답이 성립하는 조건을 먼저 채운다. 의미가 비슷한 표현을 반복해 계산값을 높이는 일보다, 무선 연결과 전원을 혼동하지 않고 필요한 원자료까지 이어주는 답이 먼저다. 이후 실제 AI 답변을 관측했다면 실행 조건·원문·인용 위치를 남겨 무엇이 확인됐는지 별도로 판단한다.

공식 자료는 2026년 10월 13일 확인했다. 원문이 소개한 콘퍼런스에 참석하거나 임베딩·검색/API·제품·AI 답변을 시험하지 않았다. 프로젝터의 문서 비교·평가 계획은 가정·제안이며 실제 사양·점수·고객 인용 성과가 아니다. 대표 사진도 생성한 설명 이미지다.