Теги: Python, Машинное обучение, Искусственный интеллект, Поисковая система, Обработка естественного языка, Наука о данных, Курс AppliedAI, A26, DataTorch
Предварительная обработка и очистка-
Здесь, в этом разделе, мы делаем простые основные операции.
Чистый HTML —
здесь мы будем использовать регулярное выражение для очистки нашего кода, где в строке 3 это означает, что внутри «‹» и «›» очищается этот HTML.
Применение этой функции к каждой строке во фрейме данных в столбце «Тело»
если вы хотите узнать о функции применения? Дайте мне знать в разделе комментариев об этом, я помогу вам.
В приведенном выше коде мы преобразуем текст в нижний регистр, чтобы избежать проблем с сопоставлением!
Удаление лишних пробелов:
Мы разделяем наш текст по пробелу и снова соединяем его вместе по пробелу. и применение лямбда-функции к ряду данных pandas сделает нашу жизнь проще.
Стемминг:
Мы заменим слова их корнями. Процесс называется стемпингом.
enumerate даст вам номер индекса цикла и значение вместе, которые мы будем хранить в «index» и «val». В этом цикле в основном мы будем брать каждое значение и добавлять его в список.
Здесь мы разделим основную строку пробелами, которые преобразуют ее в список. мы вставим его в функцию, которая вернет список, к которому мы снова присоединимся, используя пробел.
Эти вышеперечисленные шаги мы сделали, чтобы уменьшить количество строк кода и полностью использовать библиотеки panda.
То же самое мы должны сделать лемматизацию.
Лемматизация: процесс группировки флективных форм слова, чтобы их можно было проанализировать как единое целое.
то же самое мы будем применять для лемматизации для каждой строки в наборе данных.
Оптимизация —
Ждёте блог? Да, я вернулся с удивительным примером, чтобы накормить мозг такого инженера по машинному обучению, как вы.
В моем последнем блоге (1: Ссылка) с тем же примером, где мы узнали, как преобразовать огромный кусок данных XML в формат CSV, чтобы мы могли его использовать. Я предполагаю, что вы проанализировали Posts.xml как минимум с 1 миллионом записей. Это будет полезно, если вы должны показать некоторые полезные результаты.
Давайте поговорим о первом, касающемся снижения сложности вычислений.
Когда у нас есть огромное количество данных, мы должны оптимизировать наш алгоритм таким образом, чтобы мы могли максимально сократить наши вычисления, и особенно в случае поисковой системы, когда один пользователь должен искать запрос, а мы приходится искать его среди кучи записей!!! Да, мы должны оптимизировать его.
Первый вопрос, который приходит нам в голову:
«Если вы знаете, что ищете, важно знать, где искать». - Мной.
Как? (хм, наверное, нужно искать только в тех документах, которым он принадлежит.)
Если мы внимательно посмотрим, то обнаружим, что в Posts.xml есть несколько столбцов, например:
- Тело
- Заголовок
- Id
- Теги
и т.д. и т.п.
Да, эти столбцы будут играть большую роль по сравнению с другими столбцами.
И снова простой вопрос нашему очаровательному инженеру по машинному обучению! Что такое поле под названием «Теги» и чем оно будет нам полезно?
Я могу предположить, что ваш ответ должен заключаться в том, что теги — это ключевые слова, определяющие границу темы. Точно! Тег — это не что иное, как он используется для целей идентификации таким образом, чтобы вы могли связать его с этим конкретным полем.
Допустим, у пользователя есть вопрос: «В каких местах лучше всего покупать манго?»
Вы будете думать об основных категориях как места, манго; Расширенные теги как фрукты
Таким образом, вы будете искать в поле, относящемся только к этим полям. Если ваша поисковая система ищет в корпусе информацию, связанную с тем, «как кормить кошку» или «какие шаги лучше всего танцевать». Да, ваша поисковая система ищет не в том корпусе, и именно поэтому мы должны убедиться, что нашли правильный тег.
Ниже приведена диаграмма, которая резюмирует нашу поисковую оптимизацию.
Пока можно сказать, что у нас есть алгоритм поиска тегов, и давайте попробуем разобраться в приведенной выше схеме:
у нас есть список тонн записей, в которых есть сообщения, в которых у немногих есть теги, а у некоторых нет. поэтому давайте запустим наш алгоритм поиска тегов, чтобы узнать, к каким тегам принадлежит конкретный документ, и мы будем искать его в нашем полном корпусе. в нашем случае у нас есть тег: «дата» и «время».
Мы обнаружили, что у нескольких документов есть теги «дата» и у нескольких документов есть «время». и у немногих есть и то и другое, и у немногих нет ни одного из них. Мы заполним все строки тегами, используя наш «алгоритм поиска тегов».
Теперь наш следующий шаг — разделить весь корпус на основе тегов, и нам нужно выполнить поиск на основе тегов, которые у нас есть.
Алгоритм поиска тегов.
Давайте попробуем с основным алгоритмом, где мы находим наши теги из уже имеющихся тегов. у нас есть несколько доступных тегов. мы поместим эти теги в словарь.
теперь для каждого корпуса, если мы разделим каждое слово пробелом, у нас будет поиск по нескольким словам, если определенное слово присутствует в словаре? если нет тегов из уже доступных тегов, тогда мы должны поставить «no_tag» для этой строки.
Сначала мы наполним наш словарь уже имеющимися тегами.
tags_dict — это наш словарь, в котором мы храним наши теги.
В строке 6 мы ищем список в нашем словаре. Причина хранения этого кода в кеше попыток заключается в том, что если мы найдем новое слово, мы сохраним этот тег в словаре.
7 добавление «docid» в тот же словарь. добавить обратно этот список в словарь.
строка 10: эта строка выполняется только тогда, когда в словаре нет такого слова. мы сохранили это новое слово в файле tags_dict.
Теперь ниже код объясняет создание словаря для строк, в которых теги недоступны. (по сути, каждый ключ будет представлять тег, в котором есть кластеры.)
в соответствии с приведенным выше кодом! если слово присутствует, то поместите это слово в словарь и верните это слово. если слово отсутствует, вернуть no_tag. этот словарь уже должен быть заполнен доступными тегами в данных. мы сначала однозначно
Мы не помещаем здесь no_tag, потому что нам нужно сначала подтвердить, что во всем корпусе нет уже доступного тега.
Приведенный ниже код является продолжением приведенного выше фрагмента кода.
Здесь, поскольку заданные теги в наших наборах данных имеют форму ‹тег 1› ‹тег № 2›, поэтому мы просто фильтруем поле, удаляя «‹» и «›»; и разбить его по пробелу. Вы все еще можете улучшить эти строки кода, чтобы поддерживать теги с несколькими пробелами, где разделение осуществляется с помощью «», но наша цель — «создать поисковую систему», а не «находить теги», о которых мы должны помнить! давайте сохраним эту задачу как улучшение, и я буду рад услышать от вас, как такой очаровательный человек, как вы, может сделать это простым способом!
Давайте двигаться дальше и попытаться понять код ниже:
вышеуказанная функция вернет true, если значение присутствует в словаре или нет.
Строки 7 и 8: заполним все слова в теле слов и поместим их в словарь, где мы разделим их пробелом и загрузим в словарь.
Строка 10,11,12 выведет no_tag, если «no_tag» не является единственным присутствующим в ней тегом.
Строка 13–17: если в полном теле нет тегов, мы свяжем эту строку с «no_tag» и добавим запись в ключ no_tag в наш исходный tag_dictionary.
Строки 22–25: используются для словарей тегов, где мы будем тестировать наш код. чтобы увидеть ошибки.
Я надеюсь, что эти две важные части будут для вас удобоваримыми. Я надеюсь, что вы будете в курсе моей следующей серии, в которой мы применяем наши методы машинного обучения без применения каких-либо внешних библиотек с нуля. быть в курсе!
Ребята, несколько вопросов для размышления:
- Можем ли мы генерировать теги? Если да, то как мы можем применить к нашей проблеме?
- Как мы все еще оптимизируем наш поиск, чтобы можно было оптимизировать нашу вычислительную мощность?
- Можем ли мы предсказать сами теги? Возможно ли это практически?
Я поделюсь кодом через несколько месяцев, но я хочу, чтобы вы, ребята, попробовали себя в этом путешествии по созданию поисковой системы.
