На этой неделе мы продемонстрируем нашу дорожную карту для реализации моделей машинного обучения для общих целей тестирования.

Если вам интересно узнать об истории внедрения искусственного интеллекта или о том, как это происходит, перейдите по ссылкам ниже:

Проблема

Текущие тесты спецификаций хороши для проверки наличия и типа извлеченных данных. Однако должны быть реализованы специальные тесты для проверки качества извлеченных данных.

Оба титула присутствуют, их появление будет одинаковым, и оба они будут String класса. Таким образом, для проблемной части требуется специальный тест, чтобы проверить, содержит ли она какой-либо код http внутри строки. Не говоря уже о том, что этот процесс будет происходить только в том случае, если кто-то заметит его, а не оригинальную спецификацию, как это должно быть.

Фоновые исследования и полезные методы для использования

Алгоритм KNN (k-ближайших соседей)

Этот алгоритм существует с 1951 года и используется для статистической классификации. Его эффективность заключается в элегантной простоте. Если вы можете выразить характеристики данных математическим способом, вы можете создать n-мерный вектор из этих чисел.

Конец этого вектора представляет собой точку в этом n-мерном пространстве. Близость этих точек будет определять математическое сходство между поведением каждого вектора. Следовательно, каждое похожее поведение дает нам возможность классифицировать их по категориям.

Такой же подход можно использовать для классификации этих точек. То, что мы хотим использовать для нашей проблемы, — это еще один шаг вперед, а именно проверка того, ведут ли себя отдельные извлеченные значения так же, как и прошлые извлеченные данные.

Формулы евклидовых расстояний

Эти формулы тоже были выведены давно, в 18 веке путем установления связи между формулами Евклида и Пифагора. Они необходимы для расчета расстояний между точками в более высоких измерениях. Вот шпаргалка для них:

Прежде чем читатель запутается, позвольте мне объяснить, почему и как важны эти два понятия. Каждый трейт мы рассмотрим для извлеченных данных, будь то его класс, или длина, или просто индекс его букв; все они будут покрыты одним измерением декартовой плоскости.

Вот пример, чтобы разбить его:

Предположим, что ключ title состоит из строк длиной 7-10 для большинства случаев. Если заголовок SerpApi, вектор будет [7]. Давайте представим набор, который мы обучили модели для отдельного ключа title:

[
  {
    "title": "SerpApi",
    "type": "API",
    "place": "Austin"
  },
  ...
  {
    "title": "XCompany",
    "type": "X",
	"place": "XXX",
  }
]

Все эти значения создадут таблицу данных, например:

Представьте записи в столбце Length как отдельные точки в строке. Линия одномерна. Таким образом, мы можем использовать :
d(p,q)=|p-q|.
Если бы мы хотели найти, что такое XCompany, не имея столбца Key, мы использовали бы формулу для каждого из этих значений по сравнению с 8, взяли минимум (1-nn) или мажоритарный случай для n ближайших соседей (k-nn), и классифицировать, что это title.

Теперь давайте переназначим это утверждение и спросим, ​​является ли XCompany заголовком. Но для этого нам нужно переставить нашу таблицу данных с not_title для всех строк с чем-то отличным от title в столбце Key:

Теперь, если мы используем тот же метод для XCompany здесь, точка с минимальным расстоянием будет SerpApi, что предполагает, что ключом является заголовок.

Кластеризация с весами

Читатель может спросить, как это окажется полезным, поскольку во многих случаях длина строки едва ли является классифицирующим фактором. Здесь происходит процесс машинного обучения.

Каждый из этих векторов может быть скорректирован с помощью их векторов весов, каждый вектор весов начинается с вектора 1 и соответственно скорректирован с каждым правильным и неправильным предположением, удаляясь или приближаясь к сравниваемому вектору.

Это создаст разные кластеры векторов, где похожие будут ближе, а непохожие в конце концов будут удалены друг от друга.

Гипотеза

Реализация вышеупомянутого метода может быть использована для проверки качества извлеченных данных и может быть использована для тестирования любых данных JSON. Процесс должен быть в таком порядке:

  • Создание базы данных с ключами внутри (каждый внутренний ключ со своим уникальным идентификатором)
[
  {
    "title": "SerpApi",
    "text": "Scrape Google Organic Results"
    "usecases": {
                  "text": "Scraping SERP Results"
                  ...
                 },
    ...
  }
  ...
]

Ключ text и ключ usecases -> text будут обрабатываться по-разному:

  • Создание базы данных для каждого ключа (исключение одинаковых имен ключей в inner_keys)

Обратите внимание, что usecases__text опущено, чтобы не создавать путаницы при моделировании. Поскольку мы измеряем, содержит ли этот ключ определенное text или нет, это не повлияет на точность всей модели. Оценка, которую мы обязательно проверим.

Создание отдельных моделей для каждого присутствующего ключа в каждом примере. Этот процесс должен быть простой командой Rake.

Интегрируйте эти модели в Rspec. тесты как улучшающая часть для проверки качества, чтобы предупредить разработчика о том, что с результатом что-то не так, когда в false ответах по всем примерам достигнут определенный статистический порог, и указать на проблемные модели с более высокой вероятностью ошибки.

  • Упомянутый здесь статистический порог будет проверен на различных извлеченных данных. Мы увидим, можно ли его обобщить или его следует предлагать для каждой отдельной структуры данных.

Тестирование и анализ структуры

  • Индексация на уровне слов (N-gram) наряду с общими чертами
  • Индексация уровня символов наряду с различными общими признаками, такими как класс извлеченного значения, его длина и т. д.
  • Предложение к индексации на уровне символов
  • Должна ли эта реализация использовать сторонние библиотеки, такие как Torch, или нет (для модульности на разных языках и стеках)
  • Каким должен быть порог статистической ошибки, чтобы возникала ошибка в тестах Rspec?
  • Должен ли порог ошибки быть разным для разных структурированных данных?

Мы начнем с создания создателя JSON to CSV Datatable. После этого важно сделать этот процесс независимым от библиотек. Для этого мы рассмотрим, как мы можем хранить отдельные модели в файле.

Индексирование на уровне слов будет первым выбором для проверки гипотезы, поскольку оно было ценным для нас в ML-Hybrid Parser, упомянутом в предыдущих сообщениях в блоге.

Заключение

Я хотел бы поблагодарить пользователя за внимание и блестящих сотрудников SerpApi за всю их поддержку. На следующей неделе мы рассмотрим, как создавать модели для конкретных ключей, как упоминалось выше.

Прочитайте другие мои сообщения в блоге, если вы нашли это сообщение в блоге полезным.

Присоединяйтесь к нам | Твиттер | Ютуб | Дев.то | Хэшнод | СерпАпи Медиум |

Первоначально опубликовано на https://serpapi.com 23 марта 2022 г.