В чем отличие обработанного обученного объекта с ограничением объекта списка от использования самого объекта списка при использовании объектов LUIS NLU?

Question

В v3 api для создания приложений LUIS я заметил упор на машинные обучаемые объекты. Работая с ними, я замечаю что-то, что меня беспокоит, и я надеялся получить более глубокое понимание этого вопроса.

Идея состоит в том, что при использовании обработанного обученного объекта вы можете привязать его к дескрипторам списков фраз или других объектов или объектов списков в качестве ограничения для этого обработанного обученного объекта. Почему бы просто не попытаться извлечь объект списка самостоятельно? Какова цель его обертывания в обработанном обученном объекте?

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

Теперь обучение исправит это, но на самом деле, если я знаю, что у меня есть намерение, которое я хочу, и мне просто нужны сущности из этого, что на самом деле предоставляет сущность с машинным обучением?

Похоже, с этим нужно быть осторожнее.

Теперь я говорю это с этим подозрением. Будет ли ответ l ie в том, что машинно обученная сущность повысит обнаружение намерений, тогда как сущность списка будет служить только для увеличения обнаружения сущностей. Если это наиболее подходящий ответ, я думаю, что могу найти решение того, что я ищу.

Answer 1

EDITED: Я не следил за LUIS с тех пор, как ушел в декретный отпуск, и вот, он переходит с V2 на V3! документация группы LUIS.

---

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

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

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

Теперь (до // конференции по сборке MS) любая функция, не являющаяся списком фраз, может быть ограничением (обязательно), поэтому дочерняя сущность с ограниченной сущностью регулярного выражения не будет срабатывать, пока регулярное выражение не совпадет.

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

...

Речь идет о понимании целостной концепции, состоящей из частей, поэтому адрес является типичным примером. адрес содержит номер улицы , название улицы , тип улицы (улица / двор / бульвар), город, штат / провинция , страна , почтовый индекс .

Каждая из частей - это признак (сильный индикатор) того, что адрес находится в высказывании.

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

Однако, если вы действительно хотите сопоставить список, go head. Но когда заказчик говорит, что приложение не предсказывает так хорошо, как они думали, команда вернется к концепции родительского объекта ML и его частей и предложит изменения в объектах.