|
Как компьютеры понимают текст? Зачем смысл в тексте, если есть слова?
Главная / Статьи / Аналитика / Как компьютеры понимают текст?
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Как компьютеры понимают текст?
Центр исследований и разработок Bell Integrator подготовил цикл статей, в которых рассказывается, как компьютеры работают с текстом- от простых моделей до современных семантических подходов – и какие задачи это решает в реальных ИТ-системах.
Статья 1. Зачем смысл в тексте, если есть слова?
Алгоритм bag-of-words, проблема синонимов и омонимов
Один из основных способов получения информации человеком — письменность. Тексты окружают нас повсюду: как в повседневной жизни, так и в цифровой среде. Это ключевое средство коммуникации, и, конечно, человечеству хотелось бы, чтобы компьютер умел не просто хранить тексты как набор символов, а как-то интеллектуально с ними работать.
За долгие годы было разработано множество подходов к обработке текстов на ЭВМ: от простых до довольно сложных. Они позволяют получать более-менее осмысленные ответы на основе пользовательских запросов и хранимой информации.
Давайте визуализируем основные методы для работы с текстом в виде небольшой дорожной карты:
- булев поиск / инвертированный индекс;
- bag-of-words (мешок слов);
- TF–IDF;
- BM25;
- LSA/LSI;
- pLSA;
- LDA;
- эмбеддинги (word / sentence embeddings);
- семантический поиск / векторные базы / RAG.
Как известно, лень — двигатель прогресса. С появлением компьютеров у людей сразу возникло желание переложить на них как можно больше задач. Но чтобы ЭВМ могла что-то делать, ее нужно было этому научить. Один из древнейших способов передачи знаний — письменность, поэтому логично было попытаться научить компьютер работать с текстами.
Если просто загрузить документы в компьютер, он их не поймет, ведь для него это всего лишь наборы символов. Потребовались алгоритмы, которые позволили бы выполнять над текстами полезные для человека действия. Одним из первых и самых простых подходов стал bag-of-words — «мешок слов».
Его ключевая идея в том, что текст рассматривается не как связное целое, а как набор уникальных слов и частот их появления. Работает это так:
- берем текст;
- отбрасываем порядок слов;
- отбрасываем грамматику;
- оставляем только, какие слова встретились и сколько раз.
Например, фраза «не понимает смысл» при таком подходе превращается в набор: «не», «понимает», «смысл». Это похоже на игру «Эрудит»: мы высыпаем на стол все костяшки из мешка и смотрим, какие слова у нас вообще есть.
Чтобы закрепить понимание, рассмотрим более объемный пример.
Допустим, у нас есть 3 предложения:
«Компьютер не понимает смысл текстов»
«ЭВМ не понимает смысл предложений»
«Компьютер не понимает смысл жизни»
Переведем все выше написанное в формальный вид. Мы собираем словарь, куда помещаем все, что мы видим в текстах. Первое предложение влетает в словарь без изменений, так как все слова соответствуют требованиям, не надо ничего отбрасывать. Получаем словарь:
- компьютер
- не
- понимает
- смысл
- текстов
Из второго предложения добавляем:
- ЭВМ
- предложений
Добавляем третье предложение и получаем всего 1 новое уникальное слово:
- жизни
Теперь удобно записать каждый наш текст, как вектор 0 и 1: 1 — если слово из словаря есть в тексте, 0 — если слова нет. Например: «Компьютер не понимает смысл жизни» — есть «компьютер», «не», «понимает», «смысл», «жизни»:
xA ≈ [1,1,1,1,0,0,0,1...]
А вот дальше предложения в векторном представлении можно сравнивать, чтобы оценить схожесть текстов. И такой метод успешно используется в решении реальных задач. Но его самый главный недостаток в том, что понимания смысла текста здесь нет совершенно. Ведь смысл — не про набор слов, а про их структуру и взаимосвязь.
Зачем все это нужно
Потому что это дешево, быстро и работает лучше, чем кажется. Bag-of-words — это как каменный топор в Minecraft. Да, не алмазный, но:
- его легко реализовать;
- легко объяснить;
- легко масштабировать на миллионы документов;
- почти всегда дает базовый результат.
Даже сейчас мешок слов широко используется там, где важны скорость и простота реализации:
- классический поиск (в том числе многие внутренние корпоративные поиски);
- детект спама (простые признаки спама часто работают удивительно хорошо);
- текстовая аналитика в духе «какие слова / фразы чаще всего встречаются в жалобах клиентов»;
- фильтрация / маршрутизация на первом слое (до более умных моделей).
Важно понимать, что использование этого алгоритма — не атавизм, а экономическая целесообразность. На практике продвинутые системы выглядят так: быстрый и дешевый слой (bag-of-words / TF–IDF / BM25) плюс «умный» слой (семантика, эмбеддинги) для уточнения. Никто не будет тратить алмазный топор на то, чтобы просто срубить дерево, ведь лучше сделать конкретно эту задачу более дешевым инструментом.
Где не всегда работает алгоритм bag-of-words
(1) Поиск в базе знаний / FAQ
Вот классический пример:
Пользователь пишет: «не пускает в аккаунт», а в базе знаний статья, охватывающая эту проблему, называется: «Проблемы с авторизацией: сброс пароля, 2FA, неверный логин».
Формально — ноль пересечений по словам, хотя смысл один и тот же. В результате пользователь с высокой вероятностью не увидит нужную статью и вместо этого получит ссылку вроде «Как сменить аккаунт». Спасибо, конечно, но не надо.
(2) Техническая поддержка
Одну и ту же проблему можно описать по-разному:
- «не работает вход»;
- «авторизация падает»;
- «логин не проходит»;
- «после ввода пароля белый экран».
При сравнении мешком слов это будут четыре разные проблемы, хотя по смыслу — одна и та же.
(3) Чат-боты: маршрутизация и перевод на оператора
Самый обидный (и дорогой для владельца бота) сценарий: бот не находит статью из-за несовпадения слов и пишет любимую фразу пользователей:
«Я вас не понял, перевожу на оператора».
Пользователь, возможно, и рад, а вот владелец системы — нет. Метрика gross (процент переводов на оператора) в таких случаях просто улетает в космос. Это как раз тот случай, где семантика приносит реальные деньги и экономию, а не просто красоту.
Почему возникают такие ошибки
(1) Есть синонимы
«Вход», «авторизация», «логин» — для мешка слов это разные координаты. Примерно как «кошка» и «гриб»: никакого сходства, это два слова, между которыми нет смысловой связи.
(2) Одна проблема формулируется по-разному
«Не работает вход» vs «не могу зайти».
Если общих слов нет, мешок слов делает вывод: «не похоже».
(3) Есть омонимы (одно слово — разные смыслы)
Например, слово «ключ»:
ключ к двери;
API-ключ;
ключ в базе данных.
Мешок слов видит слово «ключ» и считает, что все понял. В итоге по запросу про API-ключ может показать статью про вытачивание дверных ключей.
(4) Не совпадает порядок слов
Иногда все решает одно слово и его место:
- «врач рекомендовал не пить»;
- «врач не рекомендовал пить».
Для модели это одно и то же, хотя смысл — противоположный.
Что в итоге?
Итак, можно превращать текст в числа. Схематично данный процесс изобразим следующим образом:
- текст = точка;
- похожесть = близость точек.
Возникает идея сделать так, чтобы близкие точки были близки и по смыслу. Отсюда и развиваются следующие подходы, которые будут рассмотрены далее в нашей серии статей:
- TF–IDF / BM25 (умное взвешивание слов);
- LSA / LSI (скрытые оси смысла);
- pLSA / LDA (темы как вероятностные причины);
- эмбеддинги (современный семантический поиск).
В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
_cover.jpg)
_cover.jpg)
_cover_small.jpg)
_cover_small.jpg)
_cover_small.jpg)
_cover_small.jpg)
_cover_.jpg)
_cover_.jpg)
_small.jpg)
