идея заключалась в том, что нужно вытащить запросы, близкие по контексту , например, к "Не подтвердить адрес проживания".
Предполагалось, что по контекстной близости близкими будут примерно такие
"Не получается подтвердить адрес"
"Не могу подтвердить адрес"
"Подскажите, как подтвердить адрес",
то есть упор на "подтвердить адрес"
Так оно и получилось
НО (!):
"Не могу подтвердить электронный адрес",
"Не могу подтвердить ... "(еще что-то там
также оказались близкими, так как в них есть "не могу подтвердить",
но это совершенно другой тип запроса.
Кто сталкивался с подобной ситуацией?
Как выделять контекстную близость именно про "подтвердить адрес",
а не про "не могу подтвердить"?
Сталкиваюсь постоянно. Пробовал два пути решения, оба работали (в том числе и в комбинации): 1) Дообучение энкодера предложений на собственном датасете на задачу metric learning: сближать эмбеддинги пар предложений из одного класса, и отталкивать эмбеддинги пар из разных. Работает хорошо, но можно нечаянно сломать энкодер, особенно если есть классы, состоящие из очень разнородных по смыслу примеров. 2) Не менять энкодер, но изменить формулу для расчета близости: например, из близости пары предложений вычитать (или делить на) среднюю близость k ближайших соседей каждого из них (как в статье Artexte и Schwenk ), чтобы оштрафовать примеры, которые хоть и похожи на ваш, но есть и другие, ещё более похожие.
увидел, спасибо )
А вы не пробовали так подойти: 1. рассматривать полученные по запросу результаты, как кандидатов 2. применить к кандидатам NLI. Причем тут вариантов появляется множество
так еще не пробовали )
Обсуждают сегодня