MLSearchEngine

Поисковая система на основе ML

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

Работающий :

Набор данных:

У нас есть набор данных переполнения стека из Kaggle Link: https://www.kaggle.com/c/facebook-reecruiting-iii-keyword-extraction/data

Итак, теперь у нас есть задача:

1. Пользователь введет запрос, связанный с кодом.
2. Мы должны обработать запрос.
3. Возврат результаты, соответствующие нашему запросу.

Ограничение:

1. У меня есть 8 ГБ оперативной памяти, и набор данных составляет 7 ГБ, таким образом, использование ее будет сложно. Итак, мы используем SQLite для обработки информации.
2. Мы должны сократить данные, поэтому я отвечаю только на вопросы, связанные с C#, C ++, C, Java и iOS

Рабочий процесс:

1. Searchengine_data.ipynb: В этой ноутбуке мы получаем наши данные и удаляем дубликаты. Затем мы переходим, чтобы выбрать теги, которые мы хотим. Мы использовали многопроцессорную работу для этого, так как использование 4 ядра вместе увеличивало скорость и работала 2,5 часа за 1 час. Мы сохранили новый обработанный DataFrame в базе данных SQLite.

2. Preprocessing.ipynb: В этой записной книжке мы предварительно обрабатываем данные в заголовке, то есть наши вопросы. Мы удаляем любые HTML -теги и пространства и другие мусорные или остановки.

3. Searchengine_data.ipynb: В этой записной книжке мы создаем систему для доступа к запросам, то есть начальный этап создания нашей системы прогнозирования. Сначала мы векторилизировали все данные и использовали парное расстояние между запросом и базой данных, но результаты не были в соответствии с оценками. TFIDF работал лучше, чем лук.

4. Classificationmachinelearning.ipynb: Как и на 3 -м шаге, мы не смогли получить хорошие результаты, поэтому мы собираемся использовать какое -то классическое машинное обучение. Итак, я использовал эти данные для создания модели машинного обучения. Название представляет собой строковые значения, поэтому мы использовали TFIDFVectorizer ASS TFIDF, выполненную лучше, чем лук на 3 -м шаге. Следующий шаг мы разделили модель на поезд, резюме, тест. Поскольку у нас был такой редкий вектор, у нас было 2 варианта LR или SVM. Мы выступили как на Unigram, так и на Bigram, но на Биграме это было пережитовано. Затем мы наконец использовали LR с Unigram, поскольку его производительность была лучше.

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

Затем мы повторили шаги, которые мы сделали на 3 -м шаге, и наши результаты были намного лучше.

Будущее :

1. Мы можем использовать W2V и TFIDF, взвешенный W2V. Как я был ограничен ресурсами и, следовательно, не мог этого сделать.
2. Сделать API Flask, чтобы сделать его презентабельным. Поскольку у нас также есть много вопросов, и мы возвращаем индексы из поиска, мы можем использовать этот индекс, чтобы продемонстрировать их презентабельным способом.