Можно сказать, что проблема морфологии решается за счёт эвристики min should match. Она позволяет учитывать не все токены запроса при получении ответа из индекса. Таким образом, падежи, времена, множественное число могут просто не учитываться при ответе. Поэтому получается «естественная» лемматизация.
Тут нужно детальнее смотреть на отдельные примеры: сколько токенов запроса сматчились в документе, какое влияние оказали суффиксы и приставки на финальный скор.
Все исправления опечаток применяются при построении запроса в индекс другой командой. То есть на самом деле механизм чуть более сложный, чем я описал. При построении запроса нужно: учесть все фильтры, применить опечаточник, токенизировать запрос, учесть min should match и qp idf эвристику и т.д.
Про детальную работу опечаточника я не подскажу, глядишь, ребята когда-нибудь тоже доберутся написать статью про это!
Привет! У нас по дефолту идёт разбиение по пробелу, да. Вариант с SentencePiece или Byte-Level BPE пока не дотащили до АБ-теста. Такой токенизатор как раз рассматривали как первый подход к N-граммам) Как пример, они выучивали что-то типа: ["ноутбук 15.6", "картины по номерам", "наволочки 70x70", ...].
С точки зрения оптимизации разницы нет, так как производная (по параметрам модели) слагаемого с энтропией целевого распределения равна нулю. Но с точки зрения реализации функции в PyTorch да, мы оптимизируем KLDivLoss.
Привет! Про проблему с hard negatives обычно пишут в куче статей по metric learning. Можно посмотреть какие-нибудь лекции --- там сто процентов будет освещаться этот вопрос)
Если попытаться объяснить на пальцах:
Слишком простой негатив (например, случайный из батча) несёт мало нового сигнала, когда уже есть более-менее обученная модель. Поэтому нужно извиваться и набирать негативы более умно. В том же SPLADE/ColBERT негативы на одном из этапов майнятся за счёт сортировки документов по BM25 и каким-то магическим эвристикам. Следующим этапом подбора негативов может стать предыдущая обученная модель. То есть новая модель учится на примерах старой модели + какие-то магические эвристики. Во всей этой истории главная проблема в том, что ты не можешь адекватно и быстро оценивать полученные негативы и доверяешься уже какой-то существующей, более "простой" модели. Поэтому может получиться как хорошо, так и плохо) А чтобы обучить хорошую ранжирующую модель, которой можно было бы доверять и дистиллировать, нужны хорошие негативы. И тут у нас получается замкнутый круг.
В нашем подходе мы просим как-то приблизить распределение, что сильно проще для модели с точки зрения обучения и не требует сбора таргета негативов. Тебе просто не нужно сравнивать два документа относительно какого-то якоря. Можно, конечно, попробовать понижать вероятность "шумных" токенов, но это какие-то синтетические изменения, которые портят чистый пользовательский сигнал и ведут к непредсказуемым последствиям.
Привет! Пару моментов: 1) У нас никогда не было ANN в проде в поисковой части. Как верно было сказано в одном из замечаний, ANN был только в рекламной части. 2) QP генерирует новые токены. За счёт огромного количества данных обучаются неочевидные паттерны, расширяется лексикон документа.
Возможно, я тут немного не понял твой ход мыслей, поэтому ответ мог получиться не самым понятным)
Привет! Такого нет, и мы в целом даже не задумывались об этом. Можно будет поднять этот вопрос с руководством)
Тут добавлю, что идея с выложенным датасетом мне нравится. Сейчас не хватает поисковых или рекомендательных датасетов, которые состоят из десятков или сотен миллионов документов. Да, Яндекс выкладывал свой рекомендательный датасет по музыки, но он со всем не NLP-й.
Про веса моделей всё сложнее, так как без наших данных они в целом не особо применимы. По нашим наблюдениям, модели очень чувствительны к тому, на чём они обучаются и на чём инферятся. И при публикации весов без наших данных вы, скорее всего, не сможете получить адекватную работу модели, что вызовет очень много вопросов к нам)
У нас были когда-то идеи в эту сторону --- а-ля предоставить пользователю больше управляемости поиском. Но, кажется, этой функцией будут пользоваться, дай бог, 0.1% юзеров (я был бы в их числе, да...). Сейчас мы двигаемся в сторону того, чтобы пользователю нужно было приложить минимум усилий для нахождения нужного товара. Не всегда это получается... Но мы точно на верном пути)
P.S. Насколько мне не изменяет память, предлагаемый тобой функционал раньше был в поиске Авито. Вопрос: пользовались ли юзеры им? Ребята из Авито, если вы тут, то, может, подскажите пару интересных фактов про статистику использования?
Приветствую!
Можно сказать, что проблема морфологии решается за счёт эвристики
min should match. Она позволяет учитывать не все токены запроса при получении ответа из индекса. Таким образом, падежи, времена, множественное число могут просто не учитываться при ответе. Поэтому получается «естественная» лемматизация.Тут нужно детальнее смотреть на отдельные примеры: сколько токенов запроса сматчились в документе, какое влияние оказали суффиксы и приставки на финальный скор.
Привет!
Все исправления опечаток применяются при построении запроса в индекс другой командой. То есть на самом деле механизм чуть более сложный, чем я описал. При построении запроса нужно: учесть все фильтры, применить опечаточник, токенизировать запрос, учесть min should match и qp idf эвристику и т.д.
Про детальную работу опечаточника я не подскажу, глядишь, ребята когда-нибудь тоже доберутся написать статью про это!
Привет! У нас по дефолту идёт разбиение по пробелу, да. Вариант с SentencePiece или Byte-Level BPE пока не дотащили до АБ-теста. Такой токенизатор как раз рассматривали как первый подход к N-граммам) Как пример, они выучивали что-то типа:
["ноутбук 15.6", "картины по номерам", "наволочки 70x70", ...].С точки зрения оптимизации разницы нет, так как производная (по параметрам модели) слагаемого с энтропией целевого распределения равна нулю. Но с точки зрения реализации функции в PyTorch да, мы оптимизируем
KLDivLoss.Привет! Про проблему с hard negatives обычно пишут в куче статей по metric learning. Можно посмотреть какие-нибудь лекции --- там сто процентов будет освещаться этот вопрос)
Если попытаться объяснить на пальцах:
Слишком простой негатив (например, случайный из батча) несёт мало нового сигнала, когда уже есть более-менее обученная модель. Поэтому нужно извиваться и набирать негативы более умно. В том же SPLADE/ColBERT негативы на одном из этапов майнятся за счёт сортировки документов по BM25 и каким-то магическим эвристикам. Следующим этапом подбора негативов может стать предыдущая обученная модель. То есть новая модель учится на примерах старой модели + какие-то магические эвристики. Во всей этой истории главная проблема в том, что ты не можешь адекватно и быстро оценивать полученные негативы и доверяешься уже какой-то существующей, более "простой" модели. Поэтому может получиться как хорошо, так и плохо) А чтобы обучить хорошую ранжирующую модель, которой можно было бы доверять и дистиллировать, нужны хорошие негативы. И тут у нас получается замкнутый круг.
В нашем подходе мы просим как-то приблизить распределение, что сильно проще для модели с точки зрения обучения и не требует сбора таргета негативов. Тебе просто не нужно сравнивать два документа относительно какого-то якоря. Можно, конечно, попробовать понижать вероятность "шумных" токенов, но это какие-то синтетические изменения, которые портят чистый пользовательский сигнал и ведут к непредсказуемым последствиям.
Привет! У нас есть отдельная команда, которая занимается этим направлением. Поэтому держим кулачки и ждём анонсов)
Привет! Пару моментов:
1) У нас никогда не было ANN в проде в поисковой части. Как верно было сказано в одном из замечаний, ANN был только в рекламной части.
2) QP генерирует новые токены. За счёт огромного количества данных обучаются неочевидные паттерны, расширяется лексикон документа.
Возможно, я тут немного не понял твой ход мыслей, поэтому ответ мог получиться не самым понятным)
Привет! Такого нет, и мы в целом даже не задумывались об этом. Можно будет поднять этот вопрос с руководством)
Тут добавлю, что идея с выложенным датасетом мне нравится. Сейчас не хватает поисковых или рекомендательных датасетов, которые состоят из десятков или сотен миллионов документов. Да, Яндекс выкладывал свой рекомендательный датасет по музыки, но он со всем не NLP-й.
Про веса моделей всё сложнее, так как без наших данных они в целом не особо применимы. По нашим наблюдениям, модели очень чувствительны к тому, на чём они обучаются и на чём инферятся. И при публикации весов без наших данных вы, скорее всего, не сможете получить адекватную работу модели, что вызовет очень много вопросов к нам)
Приветствую! Ты имеешь в виду что-то похожее на уточнение запроса в google?
У нас были когда-то идеи в эту сторону --- а-ля предоставить пользователю больше управляемости поиском. Но, кажется, этой функцией будут пользоваться, дай бог, 0.1% юзеров (я был бы в их числе, да...).
Сейчас мы двигаемся в сторону того, чтобы пользователю нужно было приложить минимум усилий для нахождения нужного товара. Не всегда это получается... Но мы точно на верном пути)
P.S. Насколько мне не изменяет память, предлагаемый тобой функционал раньше был в поиске Авито. Вопрос: пользовались ли юзеры им? Ребята из Авито, если вы тут, то, может, подскажите пару интересных фактов про статистику использования?