검색·인덱싱 방식과 에이전트 지식 통합 선택

앞 노트에서 「근거를 대게 하려면 검색」까지 정했다면, 다음 물음은 어떤 검색이냐입니다. AI-103은 이 자리를 구현이 아니라 설계로 묻습니다 — 코드를 쓰게 하는 대신 요구사항을 주고 검색 방식·청킹·메모리를 고르게 합니다. 고르는 기준이 서로 얽혀 있어서, 하나를 정하면 다음 것의 선택지가 줄어드는 구조입니다.

세 가지 검색과 고르는 기준

키워드 검색은 질의에 나온 낱말이 문서에 몇 번 나오는지로 점수를 매기는 방식이고 Azure AI Search는 BM25라는 함수를 씁니다. 벡터 검색은 질의와 문서를 임베딩 모델로 벡터로 바꾼 뒤 벡터 사이 거리로 찾습니다. 하이브리드 검색은 둘을 같이 돌려 결과를 합칩니다.

요구사항에 정확한 식별자가 나오면(주문번호·모델명·법조문 번호) 키워드가 반드시 섞여야 하고, 사용자가 자기 말로 묻는다가 나오면 벡터가 필요합니다. 둘 다면 하이브리드입니다. 시험에서 「사내 위키를 자연어로 검색하되 오류 코드로도 찾을 수 있어야 한다」 같은 문장이 나오면 답은 거의 하이브리드입니다.

하이브리드가 두 결과를 합치는 방법이 RRF(Reciprocal Rank Fusion)입니다. 점수를 직접 더하지 않고 등수만 씁니다 — BM25 점수와 벡터 유사도는 눈금이 달라 그대로 더할 수 없기 때문입니다.

$\mathrm{RRF}(d) = \sum_{r} \frac{1}{k + \mathrm{rank}_r(d)}$

여기서 $r$은 합칠 결과 목록 하나하나이고 $\mathrm{rank}_r(d)$는 그 목록에서 문서 $d$의 등수, $k$는 상수로 60을 씁니다. $k$가 크면 1등과 5등의 점수 차이가 작아져 한 목록에서 1등이라는 사실보다 여러 목록에 고루 올랐다는 사실이 더 세게 반영됩니다.

설계로 고른 것이 코드에서는 한 호출의 인자로 나타납니다. 아래가 하이브리드 질의의 뼈대이고, 텍스트 질의와 벡터 질의를 같은 호출에 함께 넣는 것이 하이브리드의 전부입니다.

from azure.core.credentials import AzureKeyCredential
from azure.search.documents import SearchClient
from azure.search.documents.models import VectorizableTextQuery

search = SearchClient(
    endpoint="https://my-search.search.windows.net",
    index_name="policies",
    credential=AzureKeyCredential(key),
)

results = search.search(
    search_text="환불이 안 되는 경우",                 # 키워드(BM25) 쪽
    vector_queries=[                                   # 벡터 쪽
        VectorizableTextQuery(
            text="환불이 안 되는 경우", k_nearest_neighbors=50, fields="contentVector"
        )
    ],
    select=["title", "section", "content"],
    top=5,
)

k_nearest_neighbors는 벡터 쪽이 후보를 몇 개까지 뽑아 융합에 넘길지이고, top은 융합을 끝내고 최종적으로 돌려줄 개수입니다. 앞엣것을 너무 작게 잡으면 좋은 문서가 융합 전에 이미 떨어져 나가고, 너무 크게 잡으면 뒤에 붙는 재순위 단계의 비용이 늘어납니다.

그 위에 시맨틱 랭커를 한 겹 더 얹을 수 있습니다. 1차 검색이 뽑아 온 상위 후보를 언어 모델이 다시 읽어 질의와의 의미적 맞음새로 순서를 바꾸는 단계입니다. 정확도는 올라가지만 호출마다 비용과 지연이 붙으므로, 후보를 몇 개까지 넘길지가 곧 비용 손잡이가 됩니다.

인덱싱 — 밀어 넣기와 끌어오기

색인에 문서를 넣는 방법은 둘입니다. 푸시 방식은 우리 코드가 REST나 SDK로 문서를 직접 올리는 것이고, 풀 방식은 인덱서라는 구성 요소가 Blob Storage나 SQL 같은 원본에 붙어 스스로 읽어 오는 것입니다.

증분 인덱싱은 바뀐 문서만 다시 처리하는 것입니다. 매일 문서 100만 건 중 2천 건이 바뀌는 상황에서 전량 재색인은 임베딩 비용을 500배로 부풀립니다. 「비용을 낮추면서 최신 상태를 유지하라」가 나오면 여기를 짚는 문항입니다.

청킹 — 문서를 어디서 자르는가

임베딩 모델에는 입력 길이 상한이 있고, 무엇보다 긴 문서 한 통을 벡터 하나로 뭉개면 그 안의 한 문단을 찾을 수 없게 됩니다. 그래서 문서를 조각으로 잘라 조각마다 벡터를 만듭니다.

• 너무 크게 자르면 관련 없는 내용이 섞여 검색 정밀도가 떨어지고 프롬프트에 넣을 때 토큰을 낭비합니다.
• 너무 잘게 자르면 조각 하나가 맥락을 잃어 「그것은 30일입니다」처럼 무엇에 대한 말인지 모를 문장이 됩니다.
• 겹침(overlap)을 두면 경계에서 잘린 문장이 양쪽 조각에 모두 남습니다. 조각 길이의 10~25% 정도를 겹치는 것이 흔한 출발점입니다.

문서의 성격이 자르는 자리를 정합니다. 표와 절 제목이 뚜렷한 매뉴얼은 절 경계에서 자르고, 대화 로그는 발화 단위로, 코드는 함수 단위로 자릅니다. 조각마다 문서 제목과 절 제목을 머리에 붙여 두면 잘게 잘라도 맥락이 살아납니다.

Search와 Content Understanding의 역할 구분

두 도구를 헷갈리게 내는 문항이 꾸준히 나옵니다. 가르는 물음은 하나입니다 — 여럿 중에서 고르는 일인가, 한 건 안에서 뽑는 일인가.

둘은 자주 이어 붙습니다. Content Understanding이 PDF를 마크다운과 필드로 정리하면 그 결과를 Search 색인에 넣어 RAG의 근거로 씁니다.

에이전트에 지식을 붙이는 방식과 메모리

에이전트에게 지식을 주는 길은 셋입니다. 검색 도구를 붙여 인덱스를 찾게 하거나, 함수 도구를 붙여 사내 API를 부르게 하거나, 프롬프트에 사실을 직접 넣는 것입니다. 앞 둘이 도구이고 마지막은 도구가 아닙니다 — 자주 바뀌는 사실을 프롬프트에 박아 두면 배포를 다시 해야 바뀝니다.

메모리는 두 층으로 갈립니다.

대화 메모리는 스레드가 길어질수록 토큰을 먹으므로 요약하거나 최근 몇 턴만 남기는 정책이 필요하고, 장기 메모리는 저장한 사실이 낡을 수 있어 갱신·삭제 경로를 함께 설계해야 합니다. 「사용자가 지난달에 말한 배송지를 이번 대화에서도 기억해야 한다」는 장기 메모리, 「방금 말한 주문번호를 다음 도구 호출에 쓴다」는 대화 메모리입니다. 지식 저장소는 프로젝트의 연결로 등록해 두고 도구가 그 연결을 가리키게 하는 것이 기본형이라, 자격 증명이 코드나 프롬프트에 들어가지 않습니다.

연습 문제

1. 하이브리드 검색에서 문서 A는 키워드 결과 1위·벡터 결과 5위, 문서 B는 키워드 3위·벡터 2위입니다. $k = 60$인 RRF로 합칠 때 어느 쪽이 위에 옵니까?
   ① A. 1위를 차지한 목록이 있으므로
   ② B. 두 목록에 고루 높이 올랐으므로
   ③ 같다
   ④ 등수만으로는 계산할 수 없다

   ②. A는 $\frac{1}{61} + \frac{1}{65} \approx 0.01639 + 0.01538 = 0.03178$, B는 $\frac{1}{63} + \frac{1}{62} \approx 0.01587 + 0.01613 = 0.03200$입니다. B가 근소하게 앞섭니다 — $k$가 60이라 1위와 3위의 차이가 작게 눌리기 때문입니다.
2. 「고객이 자기 말로 묻지만, 문의의 절반은 오류 코드(E-4021 같은)를 그대로 적어 온다」는 요구에 알맞은 검색은?
   ① 키워드 검색만
   ② 벡터 검색만
   ③ 하이브리드 검색
   ④ 시맨틱 랭커만 단독으로

   ③. 의미 매칭과 정확한 글자 매칭이 둘 다 필요합니다. ④의 시맨틱 랭커는 1차 검색 결과를 다시 매기는 단계라 단독으로 쓸 수 없습니다.
3. 청킹을 잘못 잡은 결과로 「검색은 맞는 조각을 가져오는데 모델의 답이 무엇에 대한 말인지 모르게 나온다」가 나타났습니다. 가장 알맞은 대응은?
   ① 조각을 더 잘게 자른다
   ② 조각마다 문서·절 제목을 머리에 붙이고 겹침을 준다
   ③ 키워드 검색으로 바꾼다
   ④ 인덱서를 푸시 방식으로 바꾼다

   ②. 조각이 맥락을 잃은 증상입니다. ①은 증상을 키웁니다.
4. 매일 문서 100만 건 중 2천 건이 바뀝니다. 임베딩 비용을 줄이면서 색인을 최신으로 두는 방법은?
   ① 매일 전량 재색인
   ② 변경 감지 정책을 켜고 증분 인덱싱
   ③ 청크 크기를 두 배로 늘린다
   ④ 시맨틱 랭커를 끈다

   ②. 바뀐 2천 건만 다시 임베딩하면 됩니다. ③·④는 비용을 조금 줄이지만 최신성과는 관계가 없습니다.
5. Azure AI Search와 Content Understanding 중 「스캔한 계약서 한 부에서 계약 기간과 위약금 조항을 필드로 뽑아 달라」에 맞는 것과, 그 근거는?
   ① Search. 문서를 색인해야 하므로
   ② Content Understanding. 한 건 안에서 스키마에 맞춰 필드를 뽑는 일이므로
   ③ Search. 순위가 필요하므로
   ④ Content Understanding. 순위를 매겨야 하므로

   ②. 여럿 중에서 고르는 일이 아니라 한 건 안에서 뽑는 일입니다.
6. 「사용자가 지난 대화에서 밝힌 알레르기 정보를 몇 주 뒤 대화에서도 반영해야 한다」에 맞는 것은?
   ① 대화 메모리(스레드)
   ② 장기 메모리
   ③ 시스템 지시문에 직접 적는다
   ④ 청크 겹침을 늘린다

   ②. 대화를 넘겨 남아야 하므로 장기 메모리입니다. ③은 사용자마다 다른 사실을 담을 수 없고, 바꾸려면 배포를 다시 해야 합니다.

이 도메인의 문항은 대부분 「무엇이 걸려 있는가」를 한 문장에 심어 둡니다. 정확한 식별자가 보이면 키워드, 자기 말로 묻는다가 보이면 벡터, 조각이 맥락을 잃었다가 보이면 청킹, 대화를 넘겨 남는다가 보이면 장기 메모리입니다. 보기를 읽기 전에 요구사항에서 그 낱말을 먼저 찾는 습관이 이 절에서 가장 크게 듣습니다.