크롤러, 검색 엔진 및 생성 AI 회사의 속임수

게시 됨: 2023-07-13

지난 몇 달 동안 생성 AI 제품의 붐으로 인해 많은 웹 사이트가 대책을 마련했습니다.

기본 관심사는 다음과 같습니다.

AI 제품은 언어 모델(소위 대규모 언어 모델 또는 줄여서 LLM)을 훈련하기 위해 대량의 콘텐츠 소비에 의존하며 이 콘텐츠는 어딘가에서 가져와야 합니다. AI 회사는 교육 데이터를 얻기 위해 대규모 크롤링을 허용하는 웹의 개방성을 보고 있지만 Reddit, Stack Overflow 및 Twitter를 비롯한 일부 웹 사이트 운영자는 이에 동의하지 않습니다.

이 흥미로운 질문에 대한 이 답변은 의심할 여지없이 전 세계 법원에서 소송을 제기하게 될 것입니다.

이 문서에서는 비즈니스 및 기술 측면에 초점을 맞춰 이 질문을 살펴봅니다. 그러나 시작하기 전에 몇 가지 사항을 살펴보겠습니다.

  • 이 주제가 다루어지고 이 기사에 몇 가지 법적 논쟁이 포함되어 있지만 저는 변호사가 아니며 귀하의 변호사가 아니며 어떤 종류의 조언도 제공하지 않습니다. 법률 자문이 필요하면 좋아하는 변호사 고양이와 대화하세요.
  • 나는 수년 전에 주로 웹 검색에서 Google에서 일했습니다. 저는 아래에 몇 가지 Google 사례를 인용하더라도 어떤 형태나 형태로든 Google을 대표하여 말하지 않습니다.
  • 이것은 빠르게 움직이는 주제입니다. 내가 이 글을 다 쓴 시간과 당신이 그것을 읽고 있는 시간 사이에 업계에서 중요한 일이 일어났을 것이고 내가 뭔가를 놓쳤을 것이라는 것이 보장됩니다!

검색 엔진과 웹사이트 간의 '거래'

Google 또는 Bing과 같은 최신 검색 엔진이 작동하는 방식부터 시작합니다. 지나치게 단순화된 용어로 검색 엔진은 다음과 같이 작동합니다.

  • 검색 엔진에는 URL 목록이 있습니다. 각 URL에는 URL이 검색 엔진의 결과 페이지에 표시하는 데 중요하거나 유용할 수 있음을 나타내는 메타데이터("신호"라고도 함)가 있습니다.
  • 이러한 신호를 기반으로 검색 엔진에는 신호가 나타내는 내용에 따라 "중요도" 순서로 이러한 URL을 가져오는 프로그램인 크롤러인 봇이 있습니다. 이를 위해 Google의 크롤러는 Googlebot이라고 하고 Bing의 크롤러는 Bingbot입니다(둘 다 광고와 같은 다른 목적을 위해 더 많은 것을 가지고 있음). 두 봇 모두 사용자 에이전트 헤더에서 자신을 식별하고 웹사이트에서 프로그래밍 방식으로 확인하여 콘텐츠가 스푸핑이 아닌 실제 검색 엔진 봇에 제공되고 있는지 확인할 수 있습니다.
  • 콘텐츠를 가져오면 인덱싱됩니다. 검색 엔진 인덱스는 콘텐츠를 사용자 쿼리에 일치시키고 순위를 매기는 데 사용되는 엄청난 양의 메타데이터 및 기타 신호와 함께 페이지 콘텐츠를 포함하는 복잡한 데이터베이스입니다. 색인은 Google 또는 Bing에서 검색어를 입력할 때 실제로 검색되는 항목입니다.

최신 검색 엔진, 적어도 정중한 검색 엔진은 웹사이트 운영자에게 크롤링 및 인덱싱에 대한 모든 권한을 부여합니다.

Robots Exclusion Protocol은 robots.txt 파일과 웹 페이지 자체의 메타 태그 또는 헤더를 통해 이 컨트롤이 구현되는 방식입니다. 이러한 검색 엔진은 자발적으로 로봇 배제 프로토콜을 따르며, 웹사이트의 프로토콜 구현을 단순한 힌트가 아닌 지시, 절대 명령으로 받아들입니다.

중요한 것은 프로토콜의 기본 위치는 모든 크롤링 및 인덱싱이 허용된다는 것입니다. 기본적으로 허용됩니다. 웹사이트 운영자가 적극적으로 제외 조치를 취하지 않는 한 웹사이트는 크롤링 및 색인 생성을 허용하는 것으로 간주됩니다.

이것은 검색 엔진과 웹 사이트 간의 거래에 대한 기본 프레임워크를 제공합니다. 기본적으로 웹 사이트는 검색 엔진에 의해 크롤링되고 인덱싱되며 검색자는 검색 결과에서 관련 검색어에 대한 검색 결과의 원래 웹 사이트를 직접 가리킵니다. .

이 거래는 근본적으로 경제적 교환입니다. 콘텐츠를 제작, 호스팅 및 제공하는 비용은 웹사이트에서 발생하지만 그 대가로 얻은 트래픽은 수익으로 이를 갚는다는 개념입니다.

참고 : 저는 이 거래에서 누가 더 많은 권한을 갖고 있고, 누가 더 많은 돈을 벌고, 공정하고, 훨씬 더 많은지에 대한 수많은 관련 논쟁을 의도적으로 무시하고 있습니다. 나는 이것들을 경시하는 것이 아닙니다. 단지 이 기사의 핵심 주제에서 벗어나고 싶지 않을 뿐입니다.

트래픽 접근 방식에 대한 이러한 인덱싱은 예를 들어 검색 엔진이 페이월 뒤에 콘텐츠를 인덱싱할 수 있는 경우와 같이 다른 곳에서 나타납니다. 그것은 같은 생각입니다. 웹 사이트는 검색자가 웹 사이트로 직접 돌아가도록 가리키는 검색 결과에 표시되는 대가로 콘텐츠를 공유합니다.

그리고 이 거래 프로세스의 각 단계에서 게시자가 모든 또는 일부 크롤링 또는 색인 생성을 어떤 식으로든 차단하려는 경우 게시자는 로봇 및 제외 프로토콜을 사용하는 여러 도구를 사용할 수 있습니다. 여전히 크롤링 및 인덱싱이 허용되는 것은 웹사이트가 검색 결과에 표시됨으로써 직접적인 이점을 얻기 때문입니다.

어떤 형태로든 이 주장은 실제로 법정에서 사용되어 "robots.txt 변호"로 알려지게 되었으며 기본적으로 보류되었습니다. 이 짧은 법원 사건 목록, Google과 관련된 많은 사건, 그리고 완전히 만족스럽지 않은 2007년의 이 글을 참조하십시오.

LLM은 검색 엔진이 아닙니다.

이제 LLM은 검색 엔진과 다른 짐승이라는 것이 매우 분명해졌습니다.

언어 모델의 응답은 모델 학습에 사용된 콘텐츠가 있는 웹 사이트를 직접 가리키지 않습니다. 검색 엔진에서 볼 수 있는 경제적 교환이 없으며 이것이 많은 출판사(및 저자)가 화를 내는 이유입니다.

직접적인 출처 인용이 없다는 것은 검색 엔진과 LLM의 근본적인 차이점이며 "Google과 Bing은 콘텐츠 스크랩을 허용하고 OpenAI는 허용하지 않는 이유는 무엇입니까?"라는 매우 일반적인 질문에 대한 답입니다. (이 질문에 대해 좀 더 정중한 표현을 사용하고 있습니다.)

Google과 Bing은 생성 AI 응답에 소스 링크를 표시하려고 시도하지만 이러한 소스는 표시되는 경우 완전한 세트가 아닙니다.

이로 인해 관련 질문이 생깁니다. 아무런 대가도 받지 못하는 경우 웹사이트에서 콘텐츠를 언어 모델 교육에 사용하도록 허용해야 하는 이유는 무엇입니까?

그것은 매우 좋은 질문이며 아마도 우리가 사회로서 답해야 할 가장 중요한 질문일 것입니다.

LLM은 현재 LLM 세대의 주요 단점(예: 환각, 인간 운영자에 대한 거짓말, 편견 등)에도 불구 하고 이점이 있으며 이러한 이점은 단점이 해결되는 동안에만 증가할 것입니다.

그러나이 토론에서 중요한 점은 현재 개방형 웹 기능의 기본 기둥이 LLM에 적합하지 않다는 것을 깨닫는 것입니다.

천박함

경제적 이익만을 위해 대규모 모델을 훈련시키는 데 관심이 있는 AI 회사에게는 분명히 문제가 되지 않습니다.

OpenAI는 교육 데이터 입력으로 여러 데이터 세트를 사용했으며(GPT3에 대한 자세한 내용은 여기 참조) OpenAI는 의도적으로 GPT4에 대한 교육 데이터 세트를 공개하지 않습니다.

OpenAI는 GPT4의 교육 데이터(여기에서 논의됨)에 대한 정보를 공개하지 않는 것을 정당화하기 위해 많은 주장을 사용하지만, 우리에게 중요한 점은 남아 있습니다. 어떤 콘텐츠가 교육에 사용되었는지 알 수 없으며 OpenAI는 ChatGPT 응답에 이를 표시하지 않습니다.

OpenAI의 데이터 수집은 로봇 배제 프로토콜을 준수합니까? 교과서나 다른 책과 같이 저작권이 있는 텍스트를 포함합니까? 웹사이트나 게시자로부터 허가를 받았습니까? 그들은 말하지 않습니다.

Brave Software의 매우 그늘진 접근 방식

OpenAI의 접근 방식이 문제라면 Brave Software(Brave 브라우저 및 Brave 검색 엔진 제조업체)는 검색 및 AI 교육 데이터와 관련하여 훨씬 더 문제적인 접근 방식과 입장을 취합니다.

Brave 검색 엔진은 Web Discovery Project에 크게 의존합니다. 이 접근 방식은 매우 정교하고 여기에 문서화되어 있지만 한 가지 중요한 사실을 강조하겠습니다. Brave는 운영하는 중앙 집중식 크롤러가 없는 것으로 보이며 크롤링 중 어느 것도 자신을 Brave용 크롤러로 식별하지 않으며 Brave에 대한 크롤러는 없습니다. 브레이브가 AI 교육을 위해 구매자에게 부여한 권리로 스크랩한 콘텐츠를 판매합니다.

그 문장에는 많은 것이 있으므로 그것을 파싱해 봅시다.

Brave 검색은 Brave 브라우저를 분산 크롤러로 사용합니다. 이 도움말 문서에 설명된 대로 다음 FAQ 질문과 답변이 있습니다.

웹 디스커버리 프로젝트는 크롤러입니까?

어떤 면에서는 그렇습니다. 웹 디스커버리 프로젝트 프로세스는 Brave의 웹 크롤러에서 작업을 가져옵니다. 몇 초 또는 몇 분마다 브라우저는 웹 페이지를 가져오고 HTML을 다시 Brave로 보내도록 지시받을 수 있습니다 . 그러나 이 가져오기는 검색 기록이나 쿠키에 영향을 미치지 않으며 비공개 가져오기 API 호출로 수행됩니다. 추가 안전을 위해 가져오기 작업 도메인은 무해하고 평판이 좋은 작은 도메인 집합에서 미리 선택됩니다.

웹 디스커버리 프로젝트란 무엇입니까? – 용감한 검색

Fetch API는 Brave가 사용하는 것을 포함하여 최신 브라우저 엔진에 내장된 웹 표준 기능입니다. 일반적인 용도는 브라우저에서 사용자에게 표시할 콘텐츠를 가져오는 것입니다. 우리의 목적을 위해 우리는 그것이 Brave의 검색 엔진을 대신하여 웹사이트의 콘텐츠를 요청하는 사용자의 브라우저임을 즉시 압니다.

흥미롭게도 2021년 6월의 Reddit 스레드는 더 자세한 내용과 혼란을 추가합니다. Brave 담당자의 한 답변은 매우 흥미롭습니다(내 강조 표시).

자체 크롤러가 있지만 잠재적인 차별을 피하기 위해 사용자 에이전트 문자열이 포함되어 있지 않습니다(브라우저인 Brave에도 고유한 사용자 에이전트 문자열이 포함되어 있지 않음 ). 즉, 크롤러가 자신의 자산에 언제/어디에 있는지 알고 싶어하는 관리자에게 잠재적으로 크롤러를 식별하는 방법에 대해 이야기했습니다. 우리는 또한 robots.txt도 존중하므로 Brave Search가 사이트를 크롤링하는 것을 원하지 않는 경우 크롤링하지 않습니다.

이것은 사실의 금광입니다.

  1. 그들은 자체 크롤러를 가지고 있으며 중앙 집중식 크롤러 또는 분산 브라우저 기반 웹 디스커버리 프로젝트를 참조할 수 있습니다.
  2. 이 크롤러는 자신을 크롤러로 식별하지 않지만 어떻게든 로봇 배제 프로토콜(robots.txt 파일 형식)을 준수합니다. 브라우저가 자신을 식별하지 못하는 경우 웹 사이트 운영자는 어떻게 로봇 제외 지시문을 작성할 수 있습니까? Brave의 크롤러에 특정한 명령을 지정하기 위해 robots.txt 파일에서 사용되는 사용자 에이전트 토큰(이름)은 무엇입니까? Brave에서 문서를 찾을 수 없었습니다.
  3. 그들이 차별이라고 부르는 것은 실제로 게시자가 크롤링을 제어하는 ​​방법입니다. 로봇 배제 프로토콜은 게시자가 액세스가 허용된 사용자와 크롤러를 구분하고 다른 크롤러를 구분할 수 있는 메커니즘입니다(예: Bingbot은 크롤링할 수 있지만 Googlebot은 허용하지 않음). 차별을 피하고 싶다고 주장함으로써 Brave는 실제로 게시자가 아니라 크롤링하고 색인을 생성하는 대상을 결정하게 되었다고 말하고 있습니다.

Fetch API로 돌아가기: 기본적으로 Fetch API는 브라우저의 사용자 에이전트 문자열을 사용합니다. 우리는 Brave 브라우저가 고유한 사용자 에이전트 헤더로 자신을 식별하지 않고 대신 기본 브라우저 엔진에서 생성된 일반 사용자 에이전트 문자열을 사용한다는 것을 이미 알고 있습니다.

사용자 에이전트 문자열은 일반적으로 브라우저와 Fetch API에 대해 사용자 정의할 수 있지만 Brave가 그렇게 한다는 표시를 찾지 못했습니다(실제로 위에 인용된 Reddit 응답은 명시적으로 고유 식별자가 없다고 말합니다).

또한 Brave는 검색 결과(예: 사이트 검색 기능을 강화하기 위해)가 아니라 AI 교육을 위해 특별히 스크랩한 데이터를 계속 판매합니다.

Brave Search API 홈페이지를 방문하면 "Data for AI"를 포함하여 여러 가격대가 표시됩니다. 이러한 데이터 요금제에는 구독자가 "AI 모델 훈련을 위한 데이터 캐시/저장"을 허용하는 "저장 권한이 있는 데이터" 옵션이 포함되며, 데이터에는 "AI용 추가 대체 스니펫" 및 "AI 추론을 위한 데이터 사용 권한이 포함됩니다. ”

요약하면, Brave의 공개 성명과 문서 부족을 기반으로 Brave는 웹을 제어하거나 차단할 명확한 방법 없이 은밀하게 웹을 크롤링하고 계속해서 AI 교육을 위해 크롤링된 콘텐츠를 재판매합니다.

더 직설적으로 표현하자면, Brave는 라이센스 또는 웹사이트 게시자의 허가 없이 저작권이 있는 콘텐츠의 영리 배포자로 스스로를 지정했습니다 .

이것이 허용됩니까? 나는 그것을 서비스로 천박한 스크레이퍼로 본다.

Google의 게시자 제어 이니셔티브

특히 생성 AI를 위한 새로운 유형의 웹 크롤러가 곧 출시될 수 있습니다.

Google은 위에서 논의한 비호환성, 웹 검색을 위해 Googlebot이 가져온 콘텐츠를 사용하는 것이 AI 모델 교육에 적합하지 않을 수 있음을 인식한 것으로 보입니다.

Google은 AI Web Publisher Controls를 만들기 위한 커뮤니티 토론을 시작하겠다고 발표했습니다. 저는 이 대화를 진심으로 지지하며 이 대화의 문을 열어준 Google에 감사를 표합니다.

아직 초기 단계이므로 이러한 컨트롤의 기본값과 기능이 컨트롤의 성공 또는 실패에 매우 중요하다는 점을 표시하는 것이 중요합니다. 저는 많은 출판사와 저자들이 이러한 AI 제어가 어떻게 작동해야 하는지에 대해 들어야 한다는 강력한 의견을 가지고 있을 것이라고 생각합니다.

오픈 소스 LLM은 어떻습니까?

위의 주장의 중요한 측면은 경제적 교환입니다. 그러나 언어 모델 뒤에 있는 조직이 자체적으로 이익이 없이 모델을 자유롭게 릴리스하면 어떻게 될까요?

이러한 오픈 소스 모델이 많이 있으며 상용 독점 모델을 교육하는 데 사용되는 데이터 세트와 실질적으로 겹치는 데이터 세트에서 교육을 받습니다. 많은 오픈 소스 모델은 현재 일부 사용 사례에 적합하며 점점 더 좋아지고 있습니다.

여전히: 오픈 소스 LLM을 교육하기 위해 웹사이트의 콘텐츠를 허가 없이 사용하는 것이 맞습니까?

그것은 아마도 더 까다로운 질문일 것입니다. 제 생각에는 현재 로봇 배제 프로토콜이 허용하는 것에 답이 달려 있다고 생각합니다. Google의 AI Web Publisher Controls 또는 기타 유사한 이니셔티브에서 잘 설계된 접근 방식의 형태로 더 나은 답이 나올 수 있습니다.

이 공간을 지켜보십시오.

이제 게시자는 무엇을 할 수 있습니까?

이러한 현재 상황은 많은 게시자가 원하지도 받아들이지도 않는 상황입니다. 그들은 무얼 할 수 있니?

여기서 우리는 구식 크롤러/봇 차단으로 돌아가야 합니다. 일반적으로 두 가지 유형의 크롤러가 있습니다.

  1. 자신을 식별하는 크롤러. 그들은 로봇 배제 프로토콜을 따를 수도 있고 따르지 않을 수도 있지만 최소한 서버에는 요청을 차단할지 여부를 결정하기 위해 확인할 식별자가 있습니다. 예를 들면 Googlebot 및 Bingbot이 있습니다.
  2. 공손한 검색 엔진에 사용되지 않는 스텔스 크롤러. 그들은 자신을 식별하지 않거나 로봇 배제 프로토콜을 따르지 않습니다. 스크립트 키디의 스팸 스크레이퍼 또는 Brave Search의 크롤러를 예로 들 수 있습니다.

다음 두 가지 상호 보완적인 작업을 수행할 수 있습니다.

  1. 크롤러가 로봇 배제 프로토콜을 준수하는 경우 크롤링하는 콘텐츠가 AI 교육 데이터에 공급된다고 생각되면 차단할 수 있습니다. 여기에는 두 가지 접근 방식이 있습니다.
    • 모든 크롤러를 차단하고 필요에 따라 허용하려는 크롤러(예: Googlebot 및 Bingbot)만 허용합니다. 이것은 자연 검색에서 웹사이트의 성능에 위험합니다. 매우 조심해야 하지만 이러한 크롤러에 효과적입니다.
    • 모든 크롤링을 허용하고 차단하려는 크롤링을 차단합니다. 이 보다 허용적인 접근 방식은 덜 위험하지만, 물론 귀하의 콘텐츠는 AI 또는 귀하가 원하지 않는 다른 크롤러에 의해 스크랩될 수 있습니다.
  2. 서버 측 스텔스 봇 탐지기를 사용하고 이를 사용하여 이러한 크롤러를 차단합니다. 많은 제품이 이를 수행할 수 있습니다. 많은 게시자처럼 콘텐츠 배포 네트워크(CDN)를 사용하는 경우 이러한 종류의 기능을 이를 통해 사용할 수 있습니다(예: Akamai, Cloudflare, Fastly).

내가 운영하는 웹사이트에서 시작하고 고객과 논의하기 시작한 접근 방식은 옵션 (1a)와 (2)의 조합, 즉 CDN 컨트롤과 함께 제한적인 robots.txt 파일을 사용하는 것입니다.

이것이 각 게시자에게 최선의 접근 방식은 아닐 수 있지만 진지하게 고려해 볼 가치가 있다고 생각합니다.

이 모든 것이 무엇을 의미합니까?

우리는 역사상 가장 영향력 있는 시대 중 하나로 기록될 시대를 살고 있습니다. 사람들은 문자 그대로 AI를 통해 인류의 파멸을 예측하고 있습니다. 우리 모두는 미래를 형성하는 데 역할을 합니다.

독창적인 콘텐츠의 창작자로서 우리는 빠르게 변화하는 산업 분야에 대응하고 적응하는 방법에 대해 생각해야 합니다. 우리가 작성하는 콘텐츠가 생성, 배포 및 소비되는 방식을 결정하는 것은 이제 전략, 기술, 재정, 윤리 등이 복잡하게 혼합된 것입니다.

당신은 어떻게 대응하든 역사적인 순간에 입장을 취하고 있습니다. 나는 당신의 부담을 느낍니다.


이 기사에 표현된 의견은 게스트 작성자의 의견이며 반드시 검색 엔진 랜드가 아닙니다. 교직원 저자는 여기에 나열됩니다.