Семантика *

В настоящее время информационные технологии достигли высочайшей степени автоматизации разработки программного обеспечения. Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами. У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.

Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно? Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.

В процессе создания курса английской грамматики для “продвинутых” уровней я не могла избавиться от смутного ощущения, что английская видовременная система (то, что в обиходе называют английскими “временами”) базируется на несложной математике. 

О том, что меня заставило прийти к этому выводу, затем комбинаторика, механика, математика и немного про музыку.

Я рассматриваю английскую видовременную систему как систему, состоящую из четырёх подъязыков в составе одного.

На когнитивном уровне английский язык распознаёт четыре аспекта (грани, феномена) реальности. Для описания каждого аспекта реальности выделен свой подъязык:

Simple (S), 

Progressive (P), 

Perfect Simple (PS), и 

Perfect Progressive (PP). 

Каждый подъязык является полноценным и описывает определённый аспект с помощью базовой формулы:

S = to X

P = to be X_ing

PS = to have X_ed / Х₃

PP = to have been X_ing ,

где X X_ing X_ed Х₃ - известные формы английских глаголов.

На 4 базовые формулы “накручиваются” маркеры настоящего, прошедшего и будущего времени, образуя тем самым полный грамматический набор из 12 видовременных форм.

Каждая из формул несёт в себе определенную смысловую информацию, которая сохраняется неизменной независимо от лексики. По несложному формальному рассчёту смысловая нагрузка на грамматическую формулу может достигать 60% от общего смысла фразы.

Эту информацию, заключённую в грамматической формуле помимо слов, я назвала “метасмысл”. Четыре выделенных мною метасмысла:

Файл и файловая система - фундаментальные сущности, без которых современные компьютеры немыслимы. Мы привыкли к ним настолько, что порой не задумываемся - а могли бы эти сущности быть другими? Достаточно ли они удобны, эффективны, можно ли их улучшить, и если можно - то как? Насколько удобны и развиты средства для работы с различной метаинфорацией? И какое это все имеет отношение к децентрализованному интернету будущего? Об этом и пойдет разговор в данной статье.

В [1, 2, 3] тексты (знаковые последовательности с повторами) с помощью матричных единиц, как образов слов, превращались (координатизировались) в алгебраические системы. Координатизация — необходимое условие алгебраизации любой предметной области...

 - Кто в нашей компании отвечает за согласование доступа в выходные на объект N?
 - Александр Иванов.
 - А какой у него телефон?

С таким диалогом легко справится любой офисный клерк, но для чат-ботов и диалоговых помощников подобные сценарии беседы до сих пор являются проблемой.

В статье мы рассказываем о том, как решили задачу преобразования вопросов пользователей на естественном языке в запросы к корпоративному графу знаний.

Одним из важных шагов, используемых людьми в поиске ответа на вопрос, является понимание того, какой именно тип ответа устроит автора. К примеру, на вопрос: "Который час?", мы ожидаем услышать ответ с типом "время", а на вопрос "Где родился Иван Петров?" -- ответ с типом "населённый пункт". То же самое верно и для вопросно-ответных систем (Question-Answering, QA), целью которых является поиск ответа на фактографические вопросы. В данной статье я представлю модуль определения ожидаемого типа ответа на вопрос (Expected Answer Type, EAT), который способен определять не только один класс, но и строить иерархию классов в качестве прогнозного значения. Модуль предоставляется как в виде веб-интерфейса (UI) так и в виде RESTful API. Данная функциональность позволяет конечным пользователям получать предсказания типа ответа для 104 языков, видеть достоверность прогноза и оставлять обратную связь. Кроме того, API позволяет исследователям и разработчикам интегрировать EAT-классификацию в свои системы.

NLI (natural language inference) – это задача автоматического определения логической связи между текстами. Обычно она формулируется так: для двух утверждений A и B надо выяснить, следует ли B из A. Эта задача сложная, потому что она требует хорошо понимать смысл текстов. Эта задача полезная, потому что "понимательную" способность модели можно эксплуатировать для прикладных задач типа классификации текстов. Иногда такая классификация неплохо работает даже без обучающей выборки!

До сих пор в открытом доступе не было нейросетей, специализированных на задаче NLI для русского языка, но теперь я обучил целых три: tiny, twoway и threeway. Зачем эти модели нужны, как они обучались, и в чём между ними разница – под катом.

Модель T5 – это нейросеть, которая уже обучена хорошо понимать и генерировать текст, и которую можно дообучить на собственную задачу, будь то перевод, суммаризация текстов, или генерация ответа чат-бота.

В этом посте я рассказываю про первую многозадачную модель T5 для русского языка и показываю, как её можно обучить на новой задаче.

Если задаться вопросом, отчего семантические технологии до сих пор широко не шагнули в массы, ответ окажется на поверхности: из-за сложности существующей реализации. Сложно создать уникальный идентификатор предмета или отыскать в словарях идентификатор класса предмета, сложно и описывать предметные свойства - простому человеку не понятны и чужды эти Schema.org, Dublin Core, etc. Надобен бы простой, примитивный даже инструмент - чтобы занимательная семантика стала массовым явлением. И такой инструмент, конечно же, есть - это обычные вопросы естественного языка: что, зачем, как? - и т.д.

В предыдущей заметкe нами была рассмотрена возможность идентификации сущностей (предметов) посредством устойчивых (immutable) понятий и CID. Выглядит это, вроде бы, не плохо, однако пока не совсем ясно, как сие можно использовать.

Структура данных часто пронизывает насквозь все слои приложения. При ее изменении приходится модифицировать структуру базы данных, логику работы с ними в программном коде, спецификации сервисов, интерфейс приложения. А если данные, описание их структуры и значительную часть логики обработки поместить в виртуализированное хранилище, и работать с ними как с единой онтологической моделью? Это сместит фокус с кода на данные и сделает приложения дата-центричными. Мы считаем, что такая трансформация позволит повысить скорость доставки полезных функций бизнес-пользователям и сэкономить ресурсы, требуемые на внесение изменений в приложения, открыть путь перехода к дата-центричной ИТ-архитектуре всего предприятия.

Всем привет!

В предыдущей статье «Смысл текста или представление знаний в системе, основанной на действиях» я описал способ представления знаний в виде семантической сети, построенной на действиях.

В этой статье, на примерах, посмотрим как могут выглядеть модели представляющие смысл текста (а также вопросы к содержанию текста!) с использованием данного подхода.

На сегодняшний день применяется не менее четырёх способов классификации вариантов SARS-CoV-2 (или hCoV-19). Проще всего с непривычки запутаться в ветвях филогенетического дерева (кладах), по-разному обозначаемых двумя конкурирующими организациями – GISAID (gisaid.org) и Nextstrain (nextstrain.org). Лавинообразное нарастание количества вариантов вируса усложняет восприятие и понимание подобных обозначений, поэтому деление на клады постепенно вытесняется делением на линии, обозначенным как PANGOLIN (Phylogenetic Assignment of Named Global Outbreak LINeages). Для такого деления используется секвенирование вирусных геномов и построение их полного филогенетического дерева.

В 2007 году знаменитый автор слова из трёх букв 'W' опубликовал в своем блоге рассуждения о востребованности слова нового, на сей раз - из трёх букв 'G'. "Гигантский Глобальный Граф" - так предполагалось это произносить в полном, необрезанном виде. О чём шла речь? О том, что слово "граф" больше подходит для обозначения технологии представления взамосвязанных данных, нежели "паутина", пусть даже и "семантическая". Термин не прижился. Отчасти, возможно, из-за некоторой тавтологичности, отчасти же - из-за того, что привычная "паутина" оказалась милее сердцу обывателя, чем какой-то "граф".

Ну, да ладно, "ГГГ" не всплыло взлетело - не беда, ведь в конце концов - это лишь один из возможных псевдонимов планетарной семантической сети. Но что представлялось сиру Тиму в качестве цели для достижения (с помощью новых-то технологий связывания данных)?.. "Важны не документы, а то, что в них содержится. Очевидная истина." - писал он, - "...когда я бронирую билет на авиарейс, меня интересует именно этот рейс. Не страница рейса на сайте путешествий или страница рейса на сайте авиакомпании, но URI самого авиарейса. Вот что я поставлю в закладки. И каким бы устройством я ни воспользовался для открытия закладки, оно будет иметь доступ к ситуационно зависимому обзору всего, что я знаю об этом рейсе из разных источников. Задача заказа и совершения рейса потребует множества взаимодействий. И на их протяжении, эти задача и рейс будут на первом месте в моём осознании, веб-сайты – на втором, а сети и устройства – на третьем."

Сайты вроде Хабра, Пикабу, Реддита, и Hacker News имеют древовидные системы комментариев к постам. Зарегистрированные пользователи могут голосовать за комментарии. Сайты используют рейтинги комментариев двумя способами:

- Управляют вниманием читателей комментариев. "Лучшие" комментарии отображаются сразу под постом, "худшие" - в подвале. Хабр почти не управляет вниманием читателей: он лишь блюрит "плохие" комментарии, но не переупорядочивает их. Впрочем, я (как наверное и многие другие читатели) часто листаю комментарии только цепляясь взглядом за двузначное значение рейтинга.

- Дают какие-то плюшки авторам "хороших" комментариев. Например, в некоторых сабреддитах нужно иметь определенный рейтинг комментариев в данном сабреддите чтобы опубликовать пост.

Кроме того, рейтинг комментариев, естественно, влияет на их авторов: положительный рейтинг поощряет авторов писать больше таких комментариев, а отрицательный - меньше. Таким образом, рейтинги комментариев еще неявно влияют на дискуссию на сайте.

Автоматическое перефразирование текстов может быть полезно в куче задач, от рерайтинга текстов до аугментации данных. В этой статье я собрал русскоязычные корпуса и модели парафраз, а также попробовал создать собственный корпус, обучить свою модель для перефразирования, и собрать набор автоматических метрик для оценки их качества.

В итоге оказалось, что модель для перевода перефразирует лучше, чем специализированные модели. Но, по крайней мере, стало более понятно, чего вообще от автоматического перефразирования можно хотеть и ожидать.

Рекомендуемый минимум

Ниже приведены основные элементы для любого веб-документа (веб-сайта/приложения):

meta charset — определяет кодировку веб-сайта, стандартом является utf-8.

meta name="viewport" — настройки viewport, связанные с мобильной отзывчивостью

width=device-width — физическая ширина устройства (отлично подходит для мобильных устройств!)

initial-scale=1 — начальный масштаб, 1 означает отсутствие масштабирования

Элементы

Допустимые элементы <head> включают meta, link, title, style, script, noscript и base.

Эти элементы предоставляют информацию о том, как документ должен восприниматься и отображаться веб-технологиями, например, браузерами, поисковыми системами, ботами и так далее.

Каждая организация использует множество приложений, каждое приложение имеет свою базу данных. В этих базах хранится описание одних и тех же объектов бизнес-процессов с разных точек зрения. Это порождает необходимость в сложных, дорогих и не всегда эффективных интеграционных решениях.

Мы расскажем о дата-центрической архитектуре — «волшебной пуле», позволяющей забыть об интеграции и открыть новые возможности для создания гибких и управляемых бизнес-приложений, аналитики и монетизации данных за счет их использования при принятии решений.

BERT – нейросеть, способная неплохо понимать смысл текстов на человеческом языке. Впервые появившись в 2018 году, эта модель совершила переворот в компьютерной лингвистике. Базовая версия модели долго предобучается, читая миллионы текстов и постепенно осваивая язык, а потом её можно дообучить на собственной прикладной задаче, например, классификации комментариев или выделении в тексте имён, названий и адресов. Стандартная версия BERT довольно толстая: весит больше 600 мегабайт, обрабатывает предложение около 120 миллисекунд (на CPU). В этом посте я предлагаю уменьшенную версию BERT для русского языка – 45 мегабайт, 6 миллисекунд на предложение. Она была получена в результате дистилляции нескольких больших моделей. Уже есть tinybert для английского от Хуавея, есть моя уменьшалка FastText'а, а вот маленький (англо-)русский BERT, кажется, появился впервые. Но насколько он хорош?