점점 더 많은 사람들이 검색 엔진 대신 모델에게 물어보며 공급업체 탐색을 시작하고 있습니다. 그리고 비교를 위해 10가지 옵션을 요청하지 않습니다. 추천을 요청하고 두세 개의 이름을 받습니다. 만약 당신의 회사가 그곳에 없다면, 8위에 머문 것이 아닙니다. 답변에 포함되지 않은 것입니다.

다음 질문은 당연합니다. 이것이 바뀌는 데 얼마나 걸릴까요? 하지만 그 전에 더 지루하고 더 중요한 문제가 있는데, 바로 어떻게 측정하느냐 하는 것입니다. 제가 이 글을 쓰는 이유는 이 부분이 거의 언급되지 않으며, 보고서가 망가지는 지점이기 때문입니다.

스크린샷은 측정이 아니다

이것은 가장 흔하면서도 논의하기 가장 어려운 오류입니다. 왜냐하면 스크린샷이 증거처럼 보이기 때문입니다.

대화형 앱 (Conversational app)의 답변은 계정 이력, 세션, 공급업체의 내부 라우팅 (Routing), 해당 질의가 웹 검색을 활성화했는지 여부, 그리고 질문이 이루어지는 지역에 따라 달라집니다. 같은 날 같은 질문을 하는 두 사람도 서로 다른 답변을 받습니다. 같은 사람이 두 번 질문할 때도 마찬가지입니다.

즉, 출력은 결정론적 (Deterministic)이지 않으며 도구는 안정적이지 않습니다. 스크린샷은 재구성할 수 없는 맥락 속에서 단 한 번 일어난 일을 알려줄 뿐입니다. 추적 지표 (Metric)로서는 아무런 쓸모가 없습니다.

정말로 유용한 것은 일련의 데이터입니다. 동일한 질의를, 글자 그대로, 동일한 엔진에 대해, 동일한 분류 기준을 가지고, 시간에 걸쳐 반복하는 것입니다. 단일 지점의 절대값은 중요하지 않습니다. 중요한 것은 지점 간의 차이입니다.

라벨이 아닌 질의 텍스트를 고정하라

이것은 그럴듯해 보이지만 거짓된 결과를 낳는 프로세스 상의 버그 (Bug)입니다.

만약 스프레드시트에 질문한 정확한 텍스트 대신 "챗봇 질의"와 같은 라벨을 저장한다면, 두 달 뒤에는 아무도 그 문구 (Wording)를 기억하지 못할 것입니다. 그리고 문구는 결과를 바꿉니다. "아르헨티나에서 X를 하는 곳은 어디인가"라고 묻는 것과 "아르헨티나의 최고의 X 기업"이라고 묻는 것은 서로 다른 목록을 반환합니다.

라운드(rounds) 사이에 텍스트가 변경되면 시리즈의 비교 가능성이 사라지지만, 그래프는 여전히 예쁘게 그려집니다. 문자열 리터럴(string literal)을 버전 관리하여 저장하세요. 쿼리(query)를 변경해야 한다면, 기존 시리즈를 오염시키는 대신 새로운 시리즈를 시작하십시오.

하나처럼 보이는 두 가지 도구

웹 검색(web search) 기능이 활성화된 모델에게 묻는 것과 그렇지 않은 모델에게 묻는 것은 서로 다른 두 가지 측정 방식이며, 서로 모순됩니다. 동일한 쿼리가 한쪽에서는 언급(mention)을 생성하고, 다른 쪽에서는 언급되지 않을 수 있습니다.

이는 모델의 오류가 아니라 서로 다른 두 가지 대상이기 때문입니다. 하나는 모델이 '지금 무엇을 찾고 있는지'를 알려주고, 다른 하나는 모델에 '무엇이 내재되어 있는지'를 알려줍니다. 이 둘을 하나의 시리즈에 섞으면 나중에 "알고리즘의 변동성(volatility)" 때문이라고 설명하게 되는 진동(oscillations)이 발생하지만, 실제로는 측정 도구가 바뀌었기 때문입니다.

시리즈의 각 데이터 포인트에는 무엇으로 측정했는지를 반드시 기록해야 합니다.

퍼센트가 아닌 세 가지 상태

수치를 왜곡하는 또 다른 지점은 분류(classification)입니다. 다음과 같이 불연속적인(discrete) 상태를 갖는 것이 좋습니다.

• 부재 (Ausente) — 나타나지 않음.
• 언급됨 (Mencionada) — 모델이 답변 본문에서 이름을 언급하지만, 사이트를 인용(cite)하지는 않음. 존재는 알고 있지만, 소스(source)를 읽고 있는 것은 아님. 이는 취약한 상태로, 다음 라운드에서 공고해질 수도 있고 사라질 수도 있음.
• 인용됨 (Citada) — 도메인이 출처(sources) 블록에 나타남. 모델이 말하는 내용을 뒷받침하며 트래픽(traffic)까지 보냄.

이 세 가지를 하나의 "가시성 지수(visibility index)"로 통합하면 실제로는 존재하지 않는 개선이 나타날 수 있습니다. 즉, '부재'에서 '언급됨'으로 넘어가는 것이 구조적인 변화 없이 수치만 부풀리는 결과를 초래합니다.

분류를 자동화할 때의 구현 디테일: 브랜드 이름을 부분 문자열(substring)로 검색하면 브랜드명이 짧거나 다른 단어에 붙어 있을 때 거짓 양성(false positives)이 발생하며, 악센트(accent)나 유니코드 정규화(Unicode normalization) 문제로 인해 거짓 음성(false negatives)이 발생할 수 있습니다. 분류기를 신뢰하기 전에 엣지 케이스(edge cases) 세트를 구축할 가치가 있습니다.

그리고 이제, 얼마나 걸리는가

이러한 조건 하에서, 반복적으로 나타나는 현상은 다음과 같습니다:

브랜드 관련 질의 —"특정 회사가 무엇인가요"—가 가장 먼저 움직입니다. 카테고리 관련 질의 —"특정 국가에서 특정 분야의 최고의 기업은 어디인가요"—는 그보다 훨씬 나중에 움직입니다. 그리고 구매 의도 관련 질의 —"특정 분야를 위해 누구를 고용해야 하나요"—는 가장 마지막에 나타나며, 바로 이 질의들이 고객을 데려옵니다.

각 사례에서 모델이 무엇을 필요로 하는지 생각해보면 이는 타당합니다. 귀하의 회사가 무엇을 하는지 답변하기 위해서는 귀하에 대한 신뢰할 수 있는 정보를 찾는 것만으로 충분합니다. 하지만 귀하를 상위 3개 목록에 포함시키려면, 모델은 귀하를 해당 산업군 전체와 비교하여 귀하가 그 자리에 있을 자격이 있다고 결정해야 합니다.

첫 번째 움직임은 보통 4주 차 근처에서 나타납니다. 그 전에는 작업이 완료되었으나 아직 눈에 보이지 않는 상태일 뿐이며, 이는 작동하지 않는 것과는 다릅니다. 바로 이 지점에서 대부분의 기업이 전략을 변경하는데, 이는 이전 전략이 막 성과를 내기 시작하려는 시점입니다.

측정하며 배우는 것들

자사 웹사이트가 정보원이 아닐 수도 있다는 점입니다. 모델이 귀하의 텍스트를 사용하여 귀하의 회사를 설명하면서도, 귀하의 도메인 대신 제3자 디렉토리를 인용하는 것은 충분히 가능한 일입니다. 설명(description)은 전달되었지만, 출처(attribution)는 전달되지 않은 것입니다.

그리고 인지(recognition)가 포함(inclusion)을 의미하지는 않는다는 점입니다. 모델은 귀하가 이름을 언급할 때는 귀하를 잘 설명할 수 있지만, 카테고리에 대해 물었을 때는 귀하를 포함하지 않을 수 있습니다. 이 둘은 서로 다른 질문이며, 두 가지 모두를 실행해 보아야 합니다.

이 중 그 어떤 것도 편법으로 해결되지 않습니다. 무엇을 움직여야 할지 알 수 있을 만큼 충분한 시간 동안, 반복 가능한 조건 하에서 측정함으로써 해결됩니다.

저는 기업에 적용되는 AI 자동화에 대해 글을 씁니다. 이 글의 원문은 varka.tech에 있습니다.