Yandex 코드베이스의 "Fragments"가 지난 주 온라인에서 유출되었습니다. Google과 마찬가지로 Yandex는 이메일, 지도, 택시 서비스 등과 같은 많은 측면을 가진 플랫폼입니다. 코드 유출은 그 모든 부분을 특징으로 합니다.

그 안에 있는 문서에 따르면 Yandex의 코드베이스는 2013년에 Arcadia라는 하나의 큰 저장소로 접혔습니다. 유출된 코드베이스는 Arcadia에 있는 모든 프로젝트의 하위 집합이며 "커널", "라이브러리"의 검색 엔진과 관련된 여러 구성 요소를 찾을 수 있습니다. ," "로봇", "검색" 및 "ExtSearch" 아카이브.

움직임은 완전히 전례가 없습니다. 2006년 AOL 검색어 데이터가 퍼블릭 도메인에 들어간 이후로 웹 검색 엔진과 관련된 자료가 없습니다.

참조되는 데이터와 많은 파일이 누락되었지만 이것은 최신 검색 엔진이 코드 수준에서 어떻게 작동하는지에 대한 가시적인 보기의 첫 번째 인스턴스입니다.

개인적으로 정보 검색, 현대 검색 엔진이 실제로 작동하는 방식, 그리고 어떻게 간단한 것을 직접 만들 수 있습니다.

어쨌든 나는 지난 목요일부터 코드를 분석해 왔고 어떤 엔지니어라도 모든 것이 어떻게 작동하는지 이해하기에는 시간이 충분하지 않다고 말할 것입니다. 그래서 계속 땜질하면서 몇 개의 게시물이 더있을 것 같습니다.

시작하기 전에 Ontolo의 Ben Wills에게 감사의 인사를 전하고 싶습니다. 저와 코드를 공유하고, 좋은 것이 있는 초기 방향을 알려주고, 우리가 암호를 해독하는 동안 저와 함께 앞뒤로 이동했습니다. 여기에서 순위 요소에 대해 수집한 모든 데이터가 포함된 스프레드시트를 자유롭게 가져오십시오.

또한 IM을 통해 몇 가지 주요 결과를 나와 공유한 Ryan Jones에게 큰 소리로 외쳐주십시오.

좋아, 바쁘게 지내자!

Google의 코드가 아닌데 왜 우리가 신경을 쓰나요?

어떤 사람들은 이 코드베이스를 검토하는 것이 방해가 되며 비즈니스 결정을 내리는 방식에 영향을 미칠 것이 없다고 생각합니다. 2006년 AOL 데이터의 CTR 모델을 이후 수년 동안 모든 검색 엔진에서 모델링을 위한 업계 표준으로 사용한 동일한 SEO 커뮤니티의 사람들이라는 점을 고려하면 궁금합니다.

즉, Yandex는 Google이 아닙니다. 그러나 이 둘은 계속해서 최첨단 기술을 유지해 온 최첨단 웹 검색 엔진입니다.

두 회사의 소프트웨어 엔지니어는 동일한 회의(SIGIR, ECIR 등)에 참석하여 정보 검색, 자연어 처리/이해 및 기계 학습에 대한 연구 결과와 혁신을 공유합니다. Yandex는 또한 Palo Alto에 존재하고 Google은 이전에 모스크바에 존재했습니다.

빠른 LinkedIn 검색을 통해 두 회사에서 근무한 수백 명의 엔지니어를 발견할 수 있지만 실제로 두 회사에서 검색 작업을 수행한 엔지니어는 몇 명인지 알 수 없습니다.

보다 직접적으로 겹치는 부분에서 Yandex는 TensorFlow, BERT, MapReduce 및 훨씬 적은 범위의 프로토콜 버퍼와 같은 검색 혁신에 중요한 Google의 오픈 소스 기술을 사용합니다.

따라서 Yandex는 확실히 Google이 아니지만 여기서 이야기하는 임의의 연구 프로젝트도 아닙니다. 이 코드베이스를 검토하여 최신 검색 엔진이 구축되는 방법에 대해 많은 것을 배울 수 있습니다.

적어도 우리는 텍스트 대 코드 비율 및 W3C 준수와 같은 SEO 도구에 여전히 스며들어 있는 구태의연한 개념이나 Google의 200가지 신호가 단순히 200개의 개별 온페이지 및 오프페이지 기능이라는 일반적인 믿음을 남용하지 않을 수 있습니다. 잠재적으로 수천 개의 개별 측정값을 사용하는 복합 요인.

Yandex 아키텍처에 대한 일부 컨텍스트

컨텍스트 또는 성공적으로 컴파일, 실행 및 단계별 실행하는 기능이 없으면 소스 코드를 이해하기가 매우 어렵습니다.

일반적으로 신입 엔지니어는 문서를 받고 연습을 하고 쌍 프로그래밍에 참여하여 기존 코드베이스에 온보딩합니다. 그리고 문서 아카이브에 빌드 프로세스 설정과 관련된 일부 온보딩 문서가 제한되어 있습니다. 그러나 Yandex의 코드는 전체적으로 내부 위키를 참조하지만 유출되지 않았으며 코드의 주석도 매우 드뭅니다.

운 좋게도 Yandex는 공개 문서에서 아키텍처에 대한 통찰력을 제공합니다. 약간의 빛을 발산하는 데 도움이되는 미국에서 공개 한 몇 가지 특허도 있습니다. 즉:

• 복수의 게시 목록을 갖는 역색인을 검색하는 컴퓨터 구현 방법 및 시스템
• 검색 결과 랭커

내 책을 위해 Google을 조사하면서 다양한 백서, 특허 및 내 SEO 경험에 대한 엔지니어의 대화를 통해 순위 시스템의 구조를 훨씬 더 깊이 이해하게 되었습니다. 또한 웹 검색 엔진에 대한 일반적인 정보 검색 모범 사례를 이해하는 데 많은 시간을 보냈습니다. 실제로 Yandex에서 몇 가지 모범 사례와 유사점이 있다는 것은 놀라운 일이 아닙니다.

Yandex의 문서는 이중 분산 크롤러 시스템에 대해 설명합니다. 하나는 "Orange Crawler"라고 하는 실시간 크롤링용이고 다른 하나는 일반 크롤링용입니다.

역사적으로 Google은 실시간 크롤링용, 정기적인 크롤링용, 거의 크롤링되지 않는 세 가지 버킷으로 인덱스를 계층화했다고 합니다. 이 접근 방식은 IR에서 모범 사례로 간주됩니다.

Yandex와 Google은 이 점에서 다르지만 업데이트 빈도에 대한 이해를 기반으로 하는 세그먼트 크롤링의 일반적인 개념은 유지됩니다.

외울 가치가 있는 한 가지는 Yandex에 JavaScript용 별도의 렌더링 시스템이 없다는 것입니다. 그들은 문서에서 이것을 말하고 Gemini라는 시각적 회귀 테스트를 위한 Webdriver 기반 시스템을 가지고 있지만 텍스트 기반 크롤링으로 제한합니다.

문서는 또한 페이지를 반전된 인덱스와 문서 서버로 나누는 샤딩된 데이터베이스 구조에 대해 설명합니다.

대부분의 다른 웹 검색 엔진과 마찬가지로 인덱싱 프로세스는 사전을 만들고 페이지를 캐시한 다음 바이그램과 트라이감 및 문서에서의 위치가 표시되도록 데이터를 반전된 인덱스에 배치합니다.

이는 구문 기반 인덱싱으로 이동했다는 점에서 Google과 다릅니다. 오래 전에 trigram보다 훨씬 더 길 수 있는 n-gram을 의미합니다.

그러나 Yandex 시스템은 파이프라인에서도 BERT를 사용하므로 일부 시점에서 문서와 쿼리가 임베딩으로 변환되고 최근접 이웃 검색 기술이 순위 지정에 사용됩니다.

랭킹 프로세스는 일이 더 흥미로워지기 시작하는 곳입니다.

Yandex에는 쿼리를 처리한 후 캐시된 인기 검색 결과가 제공되는 Metasearch 라는 레이어가 있습니다. 거기에서 결과를 찾을 수 없으면 검색 쿼리가 기본 검색 계층에 있는 수천 대의 서로 다른 시스템으로 동시에 전송됩니다. 각각은 관련 문서의 게시 목록 을 작성한 다음 순위 재지정을 위한 Yandex의 신경망 애플리케이션인 MatrixNet으로 반환하여 SERP를 구축합니다.

Google 엔지니어가 검색 인프라에 대해 이야기한 동영상에 따르면 순위 지정 프로세스는 Google 검색과 매우 유사합니다. 그들은 Google의 기술이 모든 기계에 다양한 응용 프로그램이 있고 작업이 컴퓨팅 성능의 가용성에 따라 해당 기계에 분산되는 공유 환경에 있다고 말합니다.

사용 사례 중 하나는 바로 관련 인덱스 샤드를 신속하게 처리하기 위해 여러 시스템에 쿼리를 배포하는 것입니다. 게시 목록을 계산하는 것은 순위 요소를 고려해야 하는 첫 번째 장소입니다.

코드베이스에는 17,854개의 순위 요소가 있습니다.

유출 후 금요일, 흉내낼 수 없는 Martin MacDonald는 web_factors_info/factors_gen.in이라는 코드베이스의 파일을 열심히 공유했습니다. 이 파일은 코드베이스 유출의 "Kernel" 아카이브에서 가져온 것으로 1,922개의 순위 요소가 있습니다.

당연히 SEO 커뮤니티는 그 숫자와 그 파일을 가지고 실행하여 그 안의 인사이트에 대한 뉴스를 열심히 전파했습니다. 많은 사람들이 데이터를 이해하기 위해 설명을 번역하고 도구 또는 Google 스프레드시트 및 ChatGPT를 구축했습니다. 모두 커뮤니티의 힘을 보여주는 좋은 예입니다. 그러나 1,922는 코드베이스의 여러 순위 요소 집합 중 하나를 나타냅니다.

코드베이스를 자세히 살펴보면 Yandex의 쿼리 처리 및 순위 시스템의 서로 다른 하위 집합에 대한 수많은 순위 요소 파일이 있음을 알 수 있습니다.

그것들을 샅샅이 살펴보면 실제로 총 17,854개의 순위 요소가 있음을 알 수 있습니다. 이러한 순위 요소에는 다음과 관련된 다양한 메트릭이 포함됩니다.

• 클릭.
• 드웰 시간.
• Yandex의 Google Analytics에 상응하는 Metrika를 활용합니다.

핵심 코드에 있는 요소 외에 추가로 2,000개의 요소가 있는 일련의 Jupyter 노트북도 있습니다. 아마도 이러한 Jupyter 노트북은 엔지니어가 코드베이스에 추가할 추가 요소를 고려하는 테스트를 나타냅니다. 다시 말하지만 이 링크에서 코드베이스 전체에서 수집한 메타데이터를 사용하여 이러한 모든 기능을 검토할 수 있습니다.

Yandex의 문서에는 정적, 동적, 특히 사용자의 검색 및 검색 수행 방식과 관련된 세 가지 순위 요소 클래스가 있음이 명시되어 있습니다. 자신의 말로:

코드베이스에서 이들은 TG_STATIC 및 TG_DYNAMIC 태그가 있는 순위 요소 파일에 표시됩니다. 검색 관련 요소에는 TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH 및 TG_USER_SEARCH_ONLY와 같은 여러 태그가 있습니다.

선택할 수 있는 잠재적인 18k 순위 요소를 발견했지만 MatrixNet과 관련된 문서는 점수가 수만 개의 요소로 구성되고 검색 쿼리를 기반으로 사용자 지정됨을 나타냅니다.

이는 순위 환경이 Google 환경과 유사하게 매우 역동적임을 나타냅니다. Google의 "채점 함수 평가를 위한 프레임워크" 특허에 따르면 오랫동안 여러 함수가 실행되고 최상의 결과 세트가 반환되는 유사한 기능이 있었습니다.

마지막으로 문서에서 수만 가지의 순위 요소를 참조한다는 점을 고려할 때 아카이브에서 누락된 코드에서 참조된 다른 많은 파일이 있음을 염두에 두어야 합니다. 따라서 우리가 볼 수 없는 일이 더 많이 진행되고 있을 가능성이 있습니다. 이는 아카이브에 없는 다른 디렉토리를 보여주는 온보딩 문서의 이미지를 검토하여 자세히 설명합니다.

예를 들어, /semantic-search/ 디렉토리에 DSSM과 관련된 내용이 더 있는 것 같습니다.

순위 요소의 초기 가중치

처음에는 코드베이스에 순위 요소에 대한 가중치가 없다는 가정하에 작업했습니다. 그런 다음 /search/relevance/ 디렉토리의 nav_linear.h 파일에 순위 요소와 관련된 초기 계수(또는 가중치)가 전체 화면에 표시되는 것을 보고 놀랐습니다.

이 코드 섹션은 우리가 식별한 17,000개 이상의 순위 요소 중 257개를 강조 표시합니다. ( 이 항목을 가져와 순위 요소 설명과 일치시킨 Ryan Jones에게 모자 팁.)

명확성을 위해 검색 엔진 알고리즘을 생각할 때 아마도 일련의 요소를 기반으로 모든 페이지의 점수를 매기는 길고 복잡한 수학 방정식을 생각할 것입니다. 이는 지나친 단순화이지만 다음 스크린샷은 그러한 방정식에서 발췌한 것입니다. 계수는 각 요인이 얼마나 중요한지를 나타내며 결과로 계산된 점수는 선택기 페이지의 관련성에 점수를 매기는 데 사용됩니다.

하드 코딩된 이러한 값은 이것이 순위가 발생하는 유일한 장소가 아님을 시사합니다. 대신, 이 기능은 순위를 매기기 위해 고려되는 각 샤드에 대한 일련의 게시 목록을 생성하기 위해 초기 관련성 점수가 수행되는 경우가 가장 많습니다. 위에 나열된 첫 번째 특허에서 그들은 이를 QSR(Query-Specific Relevance)에 대해 검토하기 전에 문서를 제한하는 QIR(Query-Independent Relevance)의 개념으로 이야기합니다.

결과 게시 목록은 비교할 쿼리 기능과 함께 MatrixNet으로 전달됩니다. 따라서 (아직) 다운스트림 작업의 세부 사항을 알지 못하지만 이러한 가중치는 페이지가 고려 사항 세트에 적합하기 위한 요구 사항을 알려주기 때문에 이해하는 데 여전히 중요합니다.

그러나 다음 질문 이 생깁니다. MatrixNet에 대해 무엇을 알고 있습니까?

커널 아카이브에는 신경 순위 코드가 있으며 MatrixNet 및 "mxnet"에 대한 수많은 참조와 코드베이스 전체에 DSSM(Deep Structured Semantic Models)에 대한 많은 참조가 있습니다.

FI_MATRIXNET 순위 요소 중 하나에 대한 설명은 MatrixNet이 모든 요소에 적용됨을 나타냅니다.

요인 {

색인: 160

Cpp이름: "FI_MATRIXNET"

이름: "매트릭스넷"

태그: [TG_DOC, TG_DYNAMIC, TG_TRANS, TG_NOT_01, TG_REARR_USE, TG_L3_MODEL_VALUE, TG_FRESHNESS_FROZEN_POOL]

설명: "MatrixNet은 모든 요소에 적용됩니다 – 공식"

}

사전 훈련된 모델 자체일 수 있는 바이너리 파일도 많이 있지만 코드의 이러한 측면을 밝히는 데 더 많은 시간이 걸릴 것입니다.

즉시 분명한 것은 순위에 여러 수준(L1, L2, L3)이 있고 각 수준에서 선택할 수 있는 다양한 순위 모델이 있다는 것입니다.

selection_rankings_model.cpp 파일은 프로세스 전반에 걸쳐 각 계층에서 서로 다른 순위 모델을 고려할 수 있음을 나타냅니다. 이것은 기본적으로 신경망이 작동하는 방식입니다. 각 수준은 작업을 완료하는 측면이며 결합된 계산은 궁극적으로 SERP로 표시되는 다시 순위가 지정된 문서 목록을 생성합니다. 시간이 더 있을 때 MatrixNet에 대한 심층 분석으로 후속 조치를 취하겠습니다. 살짝 엿볼 필요가 있는 사람들은 검색 결과 랭커 특허를 확인하십시오.

지금은 몇 가지 흥미로운 순위 요소를 살펴보겠습니다.

음의 가중치를 적용한 상위 5개의 초기 순위 요소

다음은 가중치가 있는 가장 높은 음의 가중치가 적용된 초기 순위 요소 목록과 러시아어에서 번역된 설명을 기반으로 한 간략한 설명입니다.

1. FI_ADV: -0.2509284637 - 이 요소는 페이지에 모든 종류의 광고가 있는지 확인하고 단일 순위 요소에 대해 가장 무거운 페널티를 부과합니다.
2. FI_DATER_AGE: -0.2074373667 – 이 요소는 dater 함수에 의해 결정된 현재 날짜와 문서 날짜 간의 차이입니다. 문서 날짜가 오늘과 같으면 값은 1, 문서가 10년 이상이거나 날짜가 정의되지 않은 경우 0입니다. 이는 Yandex가 이전 콘텐츠를 선호함을 나타냅니다.
3. FI_QURL_STAT_POWER: -0.1943768768 – 이 요소는 쿼리와 관련된 URL 노출 수입니다. 검색 결과의 다양성을 높이기 위해 많은 검색에 나타나는 URL을 강등시키려는 것 같습니다.
4. FI_COMM_LINKS_SEO_HOSTS: -0.1809636391 – 이 요소는 "상업용" 앵커 텍스트가 있는 인바운드 링크의 비율입니다. 해당 링크의 비율이 50% 이상이면 계수가 0.1로 돌아가고, 그렇지 않으면 0으로 설정됩니다.
5. FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 – 이 요소는 문서와 사용자가 검색한 국가의 지리적 일치입니다. 1이 문서와 국가가 일치함을 의미하는 경우 이는 의미가 없습니다.

요약하면 이러한 요소는 최고의 점수를 얻으려면 다음을 수행해야 함을 나타냅니다.

• 광고를 피하십시오.
• 새 페이지를 만드는 대신 이전 콘텐츠를 업데이트합니다.
• 대부분의 링크에 브랜드 앵커 텍스트가 있는지 확인하세요.

이 목록의 다른 모든 항목은 사용자가 제어할 수 없습니다.

상위 5개의 양의 가중 초기 순위 요소

후속 조치로 가장 높은 가중 긍정적 순위 요소 목록이 있습니다.

1. FI_URL_DOMAIN_FRACTION: +0.5640952971 – 이 요소는 쿼리와 URL 도메인의 이상한 마스킹 오버랩입니다. 주어진 예는 chelloto로 축약된 Chelyabinsk 복권입니다. 이 값을 계산하기 위해 Yandex는 적용되는 3글자(che, hel, lot, olo)를 찾아 도메인 이름에 있는 모든 3글자 조합의 비율을 확인합니다.
2. FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 – 이 요소에 대한 설명은 "FRC와 의사 CTR을 영리하게 결합한 것"입니다. FRC가 무엇인지에 대한 즉각적인 표시는 없습니다.
3. FI_MAX_WORD_HOST_CLICKS: +0.3451158835 – 이 요소는 도메인에서 가장 중요한 단어의 클릭 가능성입니다. 예를 들어 "wikipedia"라는 단어가 포함된 모든 쿼리의 경우 wikipedia 페이지를 클릭합니다.
4. FI_MAX_WORD_HOST_YABAR: +0.3154394573 – 요소 설명은 "바에 따라 사이트에 해당하는 가장 특징적인 쿼리 단어"라고 말합니다. 나는 이것이 사이트와 관련된 Yandex 툴바에서 가장 많이 검색된 키워드를 의미한다고 가정합니다.
5. FI_IS_COM: +0.2762504972 – 요인은 도메인이 .COM이라는 것입니다.

다시 말해:

• 귀하의 도메인으로 단어 게임을 하십시오.
• 닷컴인지 확인하세요.
• 사람들이 Yandex Bar에서 타겟 키워드를 검색하도록 장려하세요.
• 클릭수를 유지하십시오.

예상치 못한 초기 순위 요소가 많이 있습니다.

초기 가중 순위 요인에서 더 흥미로운 점은 예상치 못한 요인입니다. 다음은 눈에 띄는 17가지 요소 목록입니다.

1. FI_PAGE_RANK: +0.1828678331 – PageRank는 Yandex에서 17번째로 높은 가중치 요소입니다. 그들은 이전에 순위 시스템에서 링크를 완전히 제거했기 때문에 목록에서 얼마나 낮은지 너무 충격적이지 않습니다.
2. FI_SPAM_KARMA: +0.00842682963 – 스팸 카르마는 "안티스패머"의 이름을 따서 명명되었으며 호스트가 스팸일 가능성이 있습니다. Whois 정보를 기반으로
3. FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 – 쿼리와 문서가 주제별로 얼마나 일치하는지. 이는 19번째로 높은 가중 요인입니다.
4. FI_REG_HOST_RANK: +0.1567124399 – Yandex에는 호스트(또는 도메인) 순위 요소가 있습니다.
5. FI_URL_LINK_PERCENT: +0.08940421124 – 총 링크 수에 대한 앵커 텍스트가 URL(텍스트가 아님)인 링크의 비율입니다.
6. FI_PAGE_RANK_UKR: +0.08712279101 – 특정 우크라이나 PageRank가 있습니다.
7. FI_IS_NOT_RU: +0.08128946612 – 도메인이 .RU가 아닌 경우 긍정적입니다. 분명히 러시아 검색 엔진은 러시아 사이트를 신뢰하지 않습니다.
8. FI_YABAR_HOST_AVG_TIME2: +0.07417219313 – YandexBar에서 보고한 평균 체류 시간입니다.
9. FI_LERF_LR_LOG_RELEV: +0.06059448504 – 각 링크의 품질에 기반한 링크 관련성입니다.
10. FI_NUM_SLASHES: +0.05057609417 – URL의 슬래시 수가 순위 요소입니다.
11. FI_ADV_PRONOUNS_PORTION: -0.001250755075 – 페이지에서 대명사의 비율입니다.
12. FI_TEXT_HEAD_SYN: -0.01291908335 – 동의어를 고려하여 헤더에 [쿼리] 단어가 있음
13. FI_PERCENT_FREQ_WORDS: -0.02021022114 – 텍스트의 모든 단어 수에서 언어의 가장 빈번한 200 단어인 단어 수의 백분율입니다.
14. FI_YANDEX_ADV: -0.09426121965 – Yandex는 광고에 대한 혐오감을 더욱 구체적으로 표현하면서 Yandex 광고가 있는 페이지에 페널티를 부과합니다.
15. FI_AURA_DOC_LOG_SHARED: -0.09768630485 – 문서에서 고유하지 않은 대상 포진(텍스트 영역) 수의 로그입니다.
16. FI_AURA_DOC_LOG_AUTHOR: -0.09727752961 – 문서의 이 소유자가 작성자로 인식되는 대상 포진 수의 로그입니다.
17. FI_CLASSIF_IS_SHOP: -0.1339319854 – 분명히 Yandex는 귀하의 페이지가 상점인 경우 덜 사랑할 것입니다.

이러한 이상한 순위 요소와 Yandex 코드베이스에서 사용할 수 있는 요소의 배열을 검토하여 얻을 수 있는 주요 내용은 순위 요소가 될 수 있는 것이 많다는 것입니다.

Google에서 보고한 "200개의 신호"는 실제로 각 신호가 다른 많은 구성 요소로 구성된 합성물인 200개의 신호 클래스라고 생각합니다. Google 애널리틱스에 연결된 많은 측정항목이 있는 측정기준이 있는 것과 거의 같은 방식으로 Google 검색에는 많은 기능으로 구성된 순위 신호 클래스가 있을 수 있습니다.

Yandex는 Google, Bing, YouTube 및 TikTok을 스크랩합니다.

코드베이스는 또한 Yandex에 다른 웹사이트 및 해당 서비스에 대한 많은 파서가 있음을 보여줍니다. 서양인에게 가장 주목할만한 것은 위의 제목에 나열한 것입니다. 또한 Yandex에는 자체 서비스뿐만 아니라 내가 익숙하지 않은 다양한 서비스에 대한 파서가 있습니다.

즉시 분명한 것은 파서가 기능이 완전하다는 것입니다. Google SERP의 모든 의미 있는 구성 요소가 추출됩니다. 사실, 이러한 서비스를 스크랩하는 것을 고려하고 있는 사람은 누구나 이 코드를 검토하는 것이 좋을 것입니다.

Yandex가 DSSM 계산의 일부로 일부 Google 데이터를 사용하고 있음을 나타내는 다른 코드가 있지만 83개의 Google 명명 순위 요소 자체는 Yandex가 Google의 결과에 상당히 의존했음을 분명히 합니다.

분명히 Google은 다른 검색 엔진의 결과를 복사하는 Bing 움직임을 가져오지 않을 것이며 핵심 순위 계산을 위해 하나에 의존하지 않을 것입니다.

Yandex는 일부 순위 요소에 대한 안티 SEO 상한선을 가지고 있습니다.

315개의 순위 요소에는 페이지의 해당 기능이 과도하게 최적화되었음을 시스템에 나타내는 그 이상의 계산된 값에 대한 임계값이 있습니다. 이러한 순위 요소 중 39개는 페이지가 초기 게시물 목록에 포함되지 않도록 하는 초기 가중치 요소의 일부입니다. Rank Coefficient 및 Anti-SEO 열을 필터링하여 위에서 링크한 스프레드시트에서 찾을 수 있습니다.

모든 최신 검색 엔진이 앵커 텍스트, CTR 또는 키워드 스터핑과 같이 SEO가 역사적으로 남용한 특정 요소에 대한 임계값을 설정한다고 기대하는 것은 개념적으로 무리가 아닙니다. 예를 들어 Bing은 메타 키워드의 남용을 부정적인 요소로 활용한다고 합니다.

Yandex는 "Vital Hosts"를 강화합니다.

Yandex는 코드베이스 전체에 일련의 부스팅 메커니즘을 가지고 있습니다. 이는 순위를 매길 때 더 높은 점수를 받을 수 있도록 특정 문서를 인위적으로 개선한 것입니다.

아래는 작은 파일이 부스팅 알고리즘의 이점을 가장 잘 활용한다고 제안하는 "부스팅 마법사"의 설명입니다.

부스트에는 여러 가지 유형이 있습니다. 나는 링크와 관련된 하나의 부스트를 보았고 또한 "수동" 변경의 이상한 번역이라고 생각할 수 있는 일련의 "HandJobBoosts"도 보았습니다.

특히 흥미로운 부스트 중 하나는 "Vital Hosts"와 관련이 있습니다. 중요한 호스트는 지정된 모든 사이트가 될 수 있습니다. 변수에 구체적으로 언급된 NEWS_AGENCY_RATING은 Yandex가 결과를 특정 뉴스 조직에 편향시키는 부스트를 제공한다고 믿게 합니다.

지정학에 빠지지 않고 순위 시스템에 이와 같은 편견을 도입하지 않는 것에 대해 단호하다는 점에서 Google과 매우 다릅니다.

문서 서버의 구조

코드베이스는 문서가 Yandex의 문서 서버에 저장되는 방식을 보여줍니다. 이것은 검색 엔진이 단순히 페이지의 복사본을 만들어 캐시에 저장하는 것이 아니라 다양한 기능을 메타데이터로 캡처하여 다운스트림 순위 지정 프로세스에서 사용한다는 것을 이해하는 데 도움이 됩니다.

아래 스크린샷은 특히 흥미로운 기능의 하위 집합을 강조 표시합니다. SQL 쿼리가 포함된 다른 파일은 문서 서버에 DOM 트리, 문장 길이, 가져오기 시간, 일련의 날짜, 스팸 방지 점수, 리디렉션 체인 및 문서 번역 여부를 포함하여 200개에 가까운 열이 있음을 나타냅니다. 내가 본 가장 완벽한 목록은 /robot/rthub/yql/protos/web_page_item.proto에 있습니다.

여기서 하위 집합에서 가장 흥미로운 점은 사용된 시뮬레이션의 수입니다. Simhash는 콘텐츠의 숫자 표현이며 검색 엔진은 중복 콘텐츠를 결정하기 위해 번개처럼 빠른 비교에 사용합니다. 로봇 아카이브에는 중복 콘텐츠가 명시적으로 강등되었음을 나타내는 다양한 인스턴스가 있습니다.

또한 인덱싱 프로세스의 일부로 코드베이스는 텍스트 처리 파이프라인에서 TF-IDF, BM25 및 BERT를 제공합니다. 이러한 메커니즘을 모두 사용하는 데 약간의 중복이 있기 때문에 이러한 모든 메커니즘이 코드에 존재하는 이유는 명확하지 않습니다.

링크 요소 및 우선 순위 지정

Yandex가 링크 요인을 처리하는 방법은 이전에 영향을 완전히 비활성화했기 때문에 특히 흥미 롭습니다. 또한 코드베이스는 링크 요인과 링크의 우선 순위에 대한 많은 정보를 보여줍니다.

Yandex의 링크 스팸 계산기에는 89개의 요소가 있습니다. SF_RESERVED로 표시된 항목은 더 이상 사용되지 않습니다. 제공된 경우 위에 링크된 Google 시트에서 이러한 요소에 대한 설명을 찾을 수 있습니다.

특히 Yandex에는 사이트나 페이지가 스팸에 대한 평판을 얻은 후에도 장기적으로 지속되는 것으로 보이는 호스트 순위와 일부 점수가 있습니다.

Yandex가 하는 또 다른 일은 도메인 전체의 사본을 검토하고 해당 링크에 중복 콘텐츠가 있는지 확인하는 것입니다. 이것은 사이트 전체 링크 배치, 중복 페이지의 링크 또는 동일한 사이트에서 오는 동일한 앵커 텍스트가 있는 링크일 수 있습니다.

이것은 동일한 소스의 여러 링크를 할인하는 것이 얼마나 사소한 일인지를 보여주고 더 다양한 소스의 더 고유한 링크를 대상으로 지정하는 것이 얼마나 중요한지 명확히 합니다.

우리가 Google에 대해 알고 있는 것에 Yandex에서 무엇을 적용할 수 있습니까?

당연히 이것은 여전히 ​​모든 사람의 마음에 있는 질문입니다. Yandex와 Google 사이에는 분명히 많은 유사점이 있지만 사실 검색 분야에서 일하는 Google 소프트웨어 엔지니어만이 이 질문에 확실하게 답할 수 있습니다.

그러나 그것은 잘못된 질문입니다.

실제로 이 코드는 최신 검색에 대한 생각을 확장하는 데 도움이 됩니다. 검색에 대한 집단적 이해의 대부분은 2000년대 초 SEO 커뮤니티가 테스트를 통해 배운 것과 검색이 훨씬 덜 불투명했던 검색 엔지니어의 입에서 나온 것입니다. 안타깝게도 빠른 혁신 속도를 따라가지 못했습니다.

Yandex 유출의 많은 기능과 요인에 대한 통찰력은 Google에서 순위를 매기기 위해 테스트하고 고려해야 할 사항에 대한 더 많은 가설을 제시해야 합니다. 또한 SEO 크롤링, 링크 분석 및 순위 도구로 분석하고 측정할 수 있는 더 많은 것을 도입해야 합니다.

예를 들어, BERT 임베딩을 사용하는 쿼리와 문서 간의 코사인 유사성 측정은 최신 검색 엔진 자체에서 수행하는 작업이므로 경쟁사 페이지를 이해하는 데 유용할 수 있습니다.

AOL 검색 로그가 SERP에 대한 클릭 분포를 추측하는 것에서 우리를 이동시킨 것과 마찬가지로 Yandex 코드베이스는 우리를 추상적에서 구체적인 것으로 이동시키고 우리의 "의존적" 진술이 더 잘 검증될 수 있습니다.

이를 위해 이 코드베이스는 계속해서 줄 선물입니다. 겨우 주말이었고 우리는 이미 이 코드에서 몇 가지 매우 강력한 통찰력을 얻었습니다.

나는 훨씬 더 많은 시간을 할애할 수 있는 일부 야심 찬 SEO 엔지니어가 계속해서 파고들고 아마도 이 것을 컴파일하고 작동시키기 위해 누락된 것을 충분히 채울 것이라고 예상합니다. 또한 다양한 검색 엔진의 엔지니어들도 시스템에서 배우고 추가할 수 있는 혁신을 분석하고 분석하고 있다고 생각합니다.

동시에 Google 변호사는 모든 스크래핑과 관련된 공격적인 정지 및 단념 서한을 작성하고 있을 것입니다.

이 기회를 극대화할 호기심 많은 사람들이 주도하는 공간의 진화가 기대됩니다.

그러나 실제 코드에서 통찰력을 얻는 것이 가치가 없다면 하위 도메인 대 하위 디렉토리에 대한 논쟁과 같은 더 중요한 일로 돌아가도 좋습니다.