그라운딩은 언어 모델을 그럴듯하게 들리는 것에서 자신의 근거를 보여줄 수 있는 것으로 바꿔주는 요소다. 그라운딩된 답변은 질문 시점에 검색된 증거로부터 구성되며, 사용한 소스를 가리키기 때문에 독자나 다른 시스템이 이를 확인할 수 있다.
웹에서 행동하는 에이전트에게 실시간 데이터에 대한 그라운딩은 선택 사항이 아니다. 이들의 질문은 오늘의 가격, 지금의 재고 상태, 오늘 아침 페이지에 적혀 있는 내용에 관한 것이다. 이 설명글은 그라운딩이 무엇인지, 실시간 웹 그라운딩 루프가 어떻게 작동하는지, 그리고 아무도 눈치채지 못한 채 무너지는 지점이 어디인지를 다룬다. 레지덴셜 인프라가 그라운딩에 왜 중요한지에 대한 논거는 왜 LLM은 AI 그라운딩을 위해 레지덴셜 프록시가 필요한가에서 다룬다.
LLM 그라운딩이란 무엇이고, 무엇이 아닌가
| 접근 방식 | 지식의 출처 | 최신성 | 소스 인용 가능 여부 |
|---|---|---|---|
| 모델 지식만 사용 | 학습 데이터, 가중치에 고정됨 | 학습 마감 시점만큼 오래됨 | 불가능 |
| 파인튜닝 | 가중치에 학습된 새 데이터 | 마지막 학습 실행 시점만큼 오래됨 | 불가능 |
| 비공개 인덱스에 대한 검색 | 사전에 인덱싱된 문서 | 마지막 인덱싱만큼 최신 | 가능 |
| 실시간 웹 그라운딩 | 답변 시점에 검색하고 가져온 페이지 | 최신 | 가능 |
그라운딩은 답변을 검색된 증거로 제한하고 이를 인용하는 방식이다. 자체 문서에 대한 검색과 실시간 웹 그라운딩 모두 여기에 해당한다. 실시간 웹 그라운딩을 구분 짓는 점은 증거가 질문이 제기되는 시점에 가져와진다는 것이며, 이는 시간에 민감하거나 지역적이거나 학습 데이터 범위를 벗어나는 사안에 대해 에이전트가 필요로 하는 것이다.
그라운딩 루프
에이전트를 위한 실시간 웹 그라운딩 루프는 보통 일곱 단계로 이루어진다.
- 질의 계획. 사용자의 요청을 하나 이상의 검색 질의로 변환하며, 답변이 반영해야 할 시장과 언어를 포함한다.
- 검색. 검색 엔진으로부터 후보 소스를 얻는다.
- 선택. 어떤 결과를 읽을지 선택하며, 1차 소스와 권위 있는 소스를 우선한다.
- 가져오기. 페이지를 검색해온다.
- 추출. 각 페이지에서 관련 있는 구절을 뽑아낸다.
- 인용을 포함한 답변. 구절로부터 답변을 생성하고, 각 주장에 인용을 붙인다.
- 검증. 각 주장이 인용한 구절에 의해 실제로 뒷받침되는지 확인한다.
각 단계에는 지연 시간 예산이 있다. 검색과 가져오기가 대부분을 차지하며, 여러 소스를 병렬로 가져오는 것이 보통 에이전트의 응답성을 유지하는 방법이다.
그라운딩이 무너지는 지점
대부분의 그라운딩 실패는 오류를 만들어내지 않는다. 나쁜 증거를 바탕으로 한 자신감 있는 답변을 만들어낼 뿐이다.
차단되거나 챌린지된 가져오기. 챌린지 페이지나 빈 껍데기를 반환하는 가져오기는 모델에게 작업할 것을 아무것도 주지 않으며, 아무것도 주어지지 않은 모델은 그 빈틈을 기억에서 채우려는 경향을 보인다. 해결책은 가져오기 실패를 명시적으로 만드는 것이다. 빈 컨텍스트 대신 모델에게 “이 소스는 검색할 수 없었음”을 명확히 전달하고, 지어낸 소스로 답하는 것보다 더 적은 소스로 답하는 것을 선호해야 한다.
잘못된 시장이나 언어. 잘못된 국가에서 가져온 페이지는 다른 가격, 재고, 심지어 다른 제품을 보여줄 수 있다. 에이전트가 마드리드에 있는 사용자를 위해 답하고 있다면, 증거는 마드리드를 반영해야 한다. 언어와 시간대 신호를 출구지와 일치시키는 것 역시 중요하다. 프록시 지역, 시간대, 로케일 일치시키기를 참고하라.
오래된 캐시. 가져온 페이지를 캐싱하면 시간과 비용을 절약하지만, 질문이 필요로 하는 최신성보다 더 오래 유지되는 캐시는 조용히 어제의 사실을 반환한다. 캐시 유효 기간은 질의 유형에 따라 설정해야 한다. 가격과 뉴스는 짧게, 참고 자료는 길게.
렌더링 후에만 존재하는 콘텐츠. 많은 페이지가 JavaScript로 데이터를 로드한다. 일반적인 가져오기는 사실 없이 프레임만 반환한다. 웹 스크래핑 API가 필요한 시점을 참고하라.
가져온 페이지에 숨겨진 지시. 이것은 에이전트에 특화된 보안 실패다. 웹 페이지는 모델에게 지시처럼 보이도록 작성된 텍스트를 담을 수 있다. 가져온 콘텐츠를 지시로 취급하는 에이전트는 데이터를 유출하거나 사용자가 요청하지 않은 행동을 하도록 유도될 수 있다. 가져온 모든 페이지를 신뢰할 수 없는 데이터로 취급하고, 절대 명령으로 취급하지 마라. 검색된 텍스트를 에이전트의 지시와 명확히 분리하고, 검색된 콘텐츠를 기준으로 에이전트가 호출할 수 있는 도구를 제한하며, 중대한 행동에는 확인을 요구해야 한다.
인용 드리프트. 인용된 페이지는 답변이 제공된 후 바뀔 수 있다. 인용된 구절의 스냅샷이나 해시를 보관하여 인용이 계속 확인 가능하도록 유지하라.
프록시와 API가 루프에서 차지하는 위치
루프의 두 단계가 열린 웹과 맞닿아 있다: 검색과 가져오기.
검색은 보통 SERP API로 처리하는 것이 최선이며, 이는 에이전트가 검색 엔진을 직접 브라우징하지 않고도 특정 위치와 기기에 대한 구조화된 결과를 반환한다. 그 이유는 AI 에이전트가 실시간 SERP API를 필요로 하는 이유에 나와 있다.
가져오기는 프록시 인프라가 중요해지는 지점이다. 에이전트는 서로 관련 없는 여러 사이트에서, 여러 시장에 걸쳐, 흔히 병렬로 가져오며, 가장 중요한 사이트일수록 방어가 잘 되어 있는 경향이 있다. 사용자 시장의 레지덴셜 출구지는 현지 사용자가 보게 될 페이지를 반환한다. Shifter 게이트웨이를 사용하면 시장과 세션은 p.shifter.io:443에 대한 자격 증명에서 설정된다:
customer-USERNAME-country-es-city-madrid:PASSWORD
customer-USERNAME-country-es-city-madrid-sid-task-5521-ttl-600:PASSWORD
첫 번째 줄은 요청마다 출구지를 로테이션하며, 이는 여러 독립적인 소스를 병렬로 가져오는 데 적합하다. 두 번째 줄은 하나의 출구지를 10분 동안 유지하며, 일관성이 중요한 한 사이트에서의 다중 페이지 작업에 적합하다. 이 트레이드오프는 고정 vs 로테이팅 레지덴셜 프록시에 나와 있다.
렌더링된 페이지의 경우, 웹 스크래핑 API가 브라우저, 재시도, 추출을 하나의 요청에서 처리하며 성공한 응답에 대해서만 비용을 청구한다. 에이전트 인프라에 대한 제품 관점은 AI 에이전트를 위한 프록시 페이지에 있으며, 제공업체 선택 기준은 웹을 브라우징하는 AI 에이전트를 위한 최적의 프록시에 나와 있다.
최신성, 비용, 지연 시간
각 그라운딩된 답변은 여러 번의 검색과 여러 번의 가져오기 비용을 발생시키며, 각각은 지연 시간을 더한다. 세 가지 관행이 둘 다를 통제 가능하게 유지한다.
- 병렬로 가져오고 충분한 독립적인 소스가 일치하면 조기에 멈춘다.
- 질의 유형별로 캐싱하며, 유효 기간은 기저 사실이 얼마나 빨리 변하는지에 맞춘다.
- 1차 소스를 선호한다. 권위 있는 페이지 하나가 그것을 요약한 여러 페이지보다 가치 있다.
그라운딩된 에이전트 평가하기
답변 품질만이 아니라 그라운딩 자체를 직접 측정하라.
| 지표 | 측정하는 것 |
|---|---|
| 그라운드성 | 인용한 구절에 의해 뒷받침되는 주장의 비율 |
| 인용 정확도 | 인용된 페이지가 실제로 그 주장을 담고 있는지 |
| 최신성 | 시간에 민감한 질문에 대해 증거가 얼마나 최근 것인지 |
| 가져오기 실패율 | 증거를 검색할 수 없었던 빈도, 사이트와 시장별 |
| 근거 없는 답변율 | 증거가 없는데도 에이전트가 답변한 빈도 |
답변이 변하는 시간에 민감하고 시장에 특화된 질문으로 테스트 세트를 구축하고, 일정에 따라 다시 실행하라. 오늘 통과한 그라운딩된 에이전트도 소스가 마크업을 바꾸면 다음 달에 실패할 수 있다.
올바른 방향을 지키기
에이전트는 사람을 대신해 브라우징하므로 그에 맞게 행동해야 한다: 사이트 이용 약관과 크롤러 규칙을 준수하고, 요청 속도를 비례적으로 유지하며, 로그인이나 유료 장벽을 우회하지 않고, 무엇을 언제 가져왔는지 기록을 남겨야 한다. 더 넓은 틀은 AI 데이터 수집을 위한 윤리적 레지덴셜 프록시에 나와 있다.
FAQ
그라운딩은 검색 증강 생성과 같은 것인가?
검색 증강 생성은 그라운딩을 하는 한 가지 방법이다. 그라운딩은 비공개 인덱스든 실시간 웹이든, 답변을 검색되고 인용 가능한 증거에 묶어두는 더 넓은 실천이다.
에이전트는 실시간 웹 데이터에 그라운딩하기 위해 프록시가 필요한가?
적은 양에서는 필요하지 않을 수도 있다. 여러 사이트와 시장에 걸친 규모에서는, 단일 주소에서의 가져오기가 속도 제한을 받거나 차단되며, 차단된 가져오기가 가장 흔한 조용한 그라운딩 실패다.
웹 페이지에 숨겨진 지시로부터 에이전트를 어떻게 보호하는가?
가져온 콘텐츠를 신뢰할 수 없는 데이터로 취급하고, 에이전트의 지시와 분리하여 유지하며, 검색된 콘텐츠가 트리거할 수 있는 도구를 제한하고, 중대한 행동에는 확인을 요구하라.
에이전트가 검색 엔진을 직접 브라우징해야 하는가?
검색 단계에서는 SERP API가 보통 더 빠르고, 저렴하고, 더 신뢰할 수 있다. 브라우징은 검색이 반환한 페이지를 가져오는 데 더 적합하다.
결론
그라운딩은 질문 시점에 가져온 증거로부터 에이전트의 답변을 구성하고 이를 인용함으로써 답변을 확인 가능하게 만든다. 루프는 단순하다: 계획, 검색, 선택, 가져오기, 추출, 답변, 검증. 실패는 조용하다: 기억으로 채워진 차단된 가져오기, 잘못된 시장의 페이지, 오래된 캐시, 렌더링되지 않은 콘텐츠, 숨겨진 지시, 그리고 드리프트하는 인용.
가져오기 실패를 명시적으로 만들고, 사용자의 시장에서 가져오고, 질의 유형별로 캐싱하고, 검색된 텍스트를 신뢰할 수 없는 것으로 취급하고, 그라운드성을 직접 측정하라. 학습 데이터가 그라운딩 데이터와 어떻게 다른지에 대해서는 열린 웹에서 대규모 학습 데이터셋 구축하기를 참고하라.