Вот у вас во views возникло какое-то действие пользователя, которое должно отправить сообщение в чат-бот. Что делать будете? Приложите код или псевдокод. То, что запуск бота можно положить в команду django для запуска через manage.py -- не решает никаких архитектурных проблем само по себе.
Так, что-то вы не ответили на вопросы, давайте по-порядку. Бот нужен, чтобы: 1) передавать данные в телеграм. Как вы это будете делать из вьюшек django, если у вас бот -- в команде, работающей отдельным потоком? Никак, значит, вы облажались. Есть один обходной путь: вам придётся создавать на каждую отправку сообщения пользователю по записи в БД, и читать её из процесса с ботом. Тогда 5000 сообщений в секунду -- ваш предел, БД целиком забьётся. Но и 1000 сообщений в секунду уже будет много. И ещё будет поллинг сообщений из БД, а это задержки отправки и постоянная небольшая нагрузка на БД. 2) получать данные из телеграма. Тут ок, работает. Ну сделаем мы django.setup() из питон файла вместо того, чтобы сложить его в django management commands. Что же поменялось? А ничего не поменялось, спокойно можно использовать его, только надо помнить, что вызовы Django ORM -- синхронные, и надо ставить асинхронный драйвер БД и поменьше вызывать бизнес-логику из models.py / managers.py / где там она у вас лежит. А иначе больше 100 одновременных пользователей не вывезете в этом одном процессе. Ну, наверное, на ваших проектах больше и не нужно никогда, и все счастливы.
Я не юрист, но тут, мне кажется, все уже знают основные нюансы, ваш оппонент тоже уже их проговорил выше:
По закону РФ в случае неоказания услуг по договору платить не надо, ведь не любая подписанная двумя сторонами бумажка -- это легальная сделка (сделка может состояться лишь в момент оказания услуги), да и не по каждой даже легальной сделке можно понести ответственность в случае неуплаты. По законам России оплата услуг регулируется законодательством. По законам Франции -- тоже нужно изучать легальность такой сделки. (Ну и французу, чтобы получить деньги от гражданина РФ, придётся идти в российский суд, если в сделке не указано другое, а в российском суде ему откажут, ссылаясь на закон о защите прав потребителей... И даже если указано другое, гражданин РФ не обязан идти во французский суд, не находясь на территории Франции...)
Но и следствие тут в том, что если человек сознательно указывает неправильные данные о проживании, то это сознательная попытка обмана визового центра, и если бы визовый центр имел время и возможность это проверять, то мог бы отказать в повторной визе.
P.S. интересно, как авиакомпании оформляют невозвратные билеты на самолёт, там же та же логика закона о защите прав потребителя --может, отправляют в черный список, если человек попросить вернуть деньги? Риэлторы оформляют свое участие как "информационную услугу" чтобы обойти данное ограничение, но авиакомпания так сделать вряд ли сможет.
А сравнивали ли вы ваш подход с генерацией эмбеддингов для индекса из строк перемену длины: когда берутся предложения, абзацы, страницы, и индекс строится для каждого из них, а не просто для каждого предложения/абзаца? Основную заявленную вами проблему это должно решать, при этом вычислительно брать намного проще.
А учитывая, что эмбеддинг, порожденный моделью, и так есть для каждого токена, построить усредненный эмбеддинг по каждому 1, 2, 3, 4, 6, 8, 12, 16, ... токенов и поместить их все в единый индекс должно быть крайне просто.
И вообще, не хватает каких-то численных оценок вашего изобретения. Скажем, взять сберквад или любой другой QA датасет и прогнать по нему базовый метод (обычный индекс по абзацам), метод, предложенный мной, и ваш -- должно быть делом несложным.
Ну, может они и воспроизводимы, например, можно собрать топик, в котором будет слово "её". Однозначно воспроизводимо. Но полезен ли кому-то такой топик? Основная проблема рандомных топиков -- их неинтерпретируемость.
Я конечно не настоящий сварщик (сборкой компьютеров занимаюсь совершенно любительски), но меня тоже смущает низкая эффективность всего в 5х относительно собственного потребления, хотя и радует поток воздуха. Обычный кулер 100-120мм для отвода около 100-150 Вт тепла потребляет 2 Ватта вроде бы, 160мА*12В=2Вт, то есть получается эффективность в 50х. (Кулеры на подшипниках скольжения на 120мм кстати тоже бывают 24 дБ на полной скорости). Ноутбучный кулер -- всё делим на 5, пропорция по мощности остаётся. А пыль -- можно на боковой стенке ноутбука сделать очень мелкую решётку от пыли, она даст сопротивление воздуха, но т.к. кулер очень мощный в плане давления воздуха, то он справится.
PMI увы тоже работает не идеально, потому что в идеале для выделения фраз нужно считать статистику с учётом синонимов. Поэтому скомбинировать и будут неплохие рекомендации.
1) Видимо, всё же фразу, а не предложение. Потому что какой родительный падеж у предложения "Я вчера мыл кота"? 2) Никак, потому что вам нужно знать, как слова во фразе друг от друга зависят и какие у них модели подчинения. А для этого нужно понимать предложение. Есть синтаксические парсеры, которые строят такую модель, хотя и не очень точно. Берёте такой парсер, понимаете, падеж каких слов нужно поменять, а pymorphy уже этим занимается. 3) Или ещё есть современный вариант: натравливаете GPT-3 / ChatGPT, и (часто) получаете правильный ответ.
Вообще, это стандартная задача NLP, и должна решаться в 5-10 строк. Проверим:
Чтобы перебрать все биграммы, нужно просто написать
for a, b in zip(words, words[1:]):
p = a + '_' + b
Аналогично, если хотите все биграммы с пропуском в одно слово, то
for a, b in zip(words, words[2:]):
p = a + '^' + b
А дальше используем Counter из стандартной библиотеки
from collections import Counter
import re
c = Counter()
words = re.findall('\w+', text.lower())
for a, b in zip(words, words[1:]):
c[a+' '+b] += 1
for a, b in zip(words, words[2:]):
c[a+' ... '+b] += 1
import pprint
pprint.pprint(c.most_common(20)) # выведем красиво
Эх, немного не уложился в 5 строк, но в 10 строк уложился ;)
А вообще, есть такое понятие Wiki: PMI , которое гораздо лучше выделит подобные выражения. Просто нужно будет посчитать ещё униграммы и сделать рескоринг для биграмм.
Вот потом после таких опросов и получается непонятно что. Требования к железке, чтобы работать с неё в путешествии, в офисе и дома -- разные! В офис нужен нормальный мощный стационарный компьютер с 3 мониторами и отдельной беспроводной клавиатурой, которую можно двигать, а в дорогу -- лёгкий мощный но долгоживущий ноутбук с небольшим ярким дисплеем, в основном, для офисного и мультимедийного применения, потому что компилировать, запускать и отлаживать код, как-либо работающий с пользовательскими интерфейсами на ноутбуке (и фронтенд, и бэкенд) -- ну так себе удовольствие.
А какой у вас доверительный интервал, чтобы понять, что 0.629 лучше, чем 0.613 ? Может, у вас оценки ±5%? Тогда вы не отличите одно от другого, как вам и показывает MAE.
В общем, вы просто не знаете мат статистику, и с умным видом сравниваете случайные величины как обычные числа.
Кроме того (и вот тут вы должны испытывать особый стыд), ROC AUC определяет кривую для всех значений precision и recall, а на практике, вы будете использовать только одно конкретное значение на этой кривой, выбрав threshold. Правильно сравнить две кривые по одному числу нельзя, поэтому вы берёте какую-то функцию от этих кривых, которая даёт число для каждой кривой. И естественно, можно найти одну функцию, по которой одна меньше другой, и функцию, по которой всё наоборот. Например, если зафиксировать TPR = 0.5 и TPR=0.8 здесь, то получим разные ответы о том, какая кривая лучше (считаем, что линии разного цвета -- это скоры разных моделей).
Алексей, кажется, вас спрашивают другое:
А если обобщить утверждение Сёрла с «перечисления правил», как в 192х-195х понимали компьютерный интеллект (через онтологии), до просто «современной компьютерной программы, с памятью и графическими ускорителями», тогда всё равно будет комбинаторный взрыв и те же проблемы?
Так контекст и есть прототип и границы вокруг прототипа. Только записанные не в виде текста, чтобы можно было 1000 границ сразу написать или даже миллион. Правда передать их кому-то так не получится. Ведь у определения есть ещё одна функция — быстрой передачи данных, именно поэтому мы стремимся к его компактности.
Что-то вижу какой-то ответ в стиле чатгпт.
Вот у вас во views возникло какое-то действие пользователя, которое должно отправить сообщение в чат-бот. Что делать будете? Приложите код или псевдокод. То, что запуск бота можно положить в команду django для запуска через manage.py -- не решает никаких архитектурных проблем само по себе.
Так, что-то вы не ответили на вопросы, давайте по-порядку.
Бот нужен, чтобы:
1) передавать данные в телеграм.
Как вы это будете делать из вьюшек django, если у вас бот -- в команде, работающей отдельным потоком? Никак, значит, вы облажались.
Есть один обходной путь: вам придётся создавать на каждую отправку сообщения пользователю по записи в БД, и читать её из процесса с ботом. Тогда 5000 сообщений в секунду -- ваш предел, БД целиком забьётся. Но и 1000 сообщений в секунду уже будет много. И ещё будет поллинг сообщений из БД, а это задержки отправки и постоянная небольшая нагрузка на БД.
2) получать данные из телеграма.
Тут ок, работает.
Ну сделаем мы django.setup() из питон файла вместо того, чтобы сложить его в django management commands. Что же поменялось? А ничего не поменялось, спокойно можно использовать его, только надо помнить, что вызовы Django ORM -- синхронные, и надо ставить асинхронный драйвер БД и поменьше вызывать бизнес-логику из models.py / managers.py / где там она у вас лежит. А иначе больше 100 одновременных пользователей не вывезете в этом одном процессе. Ну, наверное, на ваших проектах больше и не нужно никогда, и все счастливы.
Так и что с этим дальше делать? Как отправлять данные через бот? Как принимать данные и куда они попадут? Как асинхронщину включать?
Так MIT или Apache? в вашем репозитории написано Apache, в соседнем комменте написано MIT.
Библиотека крута!
Просьба сделать лицензию попроще, пока вы единственный разработчик, по возможности: MIT, BSD2, BSD3 или Apache
Это поможет увеличению использования вашего проекта.
нет, устранили через 1 или 2 дня, посмотрите на даты прочитайте внимательно даты к действиям. Последние действия -- это про disclose.
Я не юрист, но тут, мне кажется, все уже знают основные нюансы, ваш оппонент тоже уже их проговорил выше:
По закону РФ в случае неоказания услуг по договору платить не надо, ведь не любая подписанная двумя сторонами бумажка -- это легальная сделка (сделка может состояться лишь в момент оказания услуги), да и не по каждой даже легальной сделке можно понести ответственность в случае неуплаты. По законам России оплата услуг регулируется законодательством. По законам Франции -- тоже нужно изучать легальность такой сделки. (Ну и французу, чтобы получить деньги от гражданина РФ, придётся идти в российский суд, если в сделке не указано другое, а в российском суде ему откажут, ссылаясь на закон о защите прав потребителей... И даже если указано другое, гражданин РФ не обязан идти во французский суд, не находясь на территории Франции...)
Но и следствие тут в том, что если человек сознательно указывает неправильные данные о проживании, то это сознательная попытка обмана визового центра, и если бы визовый центр имел время и возможность это проверять, то мог бы отказать в повторной визе.
P.S. интересно, как авиакомпании оформляют невозвратные билеты на самолёт, там же та же логика закона о защите прав потребителя --может, отправляют в черный список, если человек попросить вернуть деньги? Риэлторы оформляют свое участие как "информационную услугу" чтобы обойти данное ограничение, но авиакомпания так сделать вряд ли сможет.
Не понял, какую именно сеть надо учить. Вашу? А что вообще тогда у вас есть готового? Только идея?
А сравнивали ли вы ваш подход с генерацией эмбеддингов для индекса из строк перемену длины: когда берутся предложения, абзацы, страницы, и индекс строится для каждого из них, а не просто для каждого предложения/абзаца? Основную заявленную вами проблему это должно решать, при этом вычислительно брать намного проще.
А учитывая, что эмбеддинг, порожденный моделью, и так есть для каждого токена, построить усредненный эмбеддинг по каждому 1, 2, 3, 4, 6, 8, 12, 16, ... токенов и поместить их все в единый индекс должно быть крайне просто.
И вообще, не хватает каких-то численных оценок вашего изобретения. Скажем, взять сберквад или любой другой QA датасет и прогнать по нему базовый метод (обычный индекс по абзацам), метод, предложенный мной, и ваш -- должно быть делом несложным.
Ну, может они и воспроизводимы, например, можно собрать топик, в котором будет слово "её". Однозначно воспроизводимо. Но полезен ли кому-то такой топик?
Основная проблема рандомных топиков -- их неинтерпретируемость.
Ну, давайте думать вместе. А какая польза может быть с рандомных топиков?
То есть, ставьте гипотезы, а потом их уже доказывайте или опровергайте.
Какая-то статистика собрана, с чем-то поигрались, но выводы (нормальные/полезные) не сделаны... Без обид, но похоже на некачественно сделанный анализ!
Я конечно не настоящий сварщик (сборкой компьютеров занимаюсь совершенно любительски), но меня тоже смущает низкая эффективность всего в 5х относительно собственного потребления, хотя и радует поток воздуха. Обычный кулер 100-120мм для отвода около 100-150 Вт тепла потребляет 2 Ватта вроде бы, 160мА*12В=2Вт, то есть получается эффективность в 50х. (Кулеры на подшипниках скольжения на 120мм кстати тоже бывают 24 дБ на полной скорости). Ноутбучный кулер -- всё делим на 5, пропорция по мощности остаётся.
А пыль -- можно на боковой стенке ноутбука сделать очень мелкую решётку от пыли, она даст сопротивление воздуха, но т.к. кулер очень мощный в плане давления воздуха, то он справится.
PMI увы тоже работает не идеально, потому что в идеале для выделения фраз нужно считать статистику с учётом синонимов.
Поэтому скомбинировать и будут неплохие рекомендации.
1) Видимо, всё же фразу, а не предложение. Потому что какой родительный падеж у предложения "Я вчера мыл кота"?
2) Никак, потому что вам нужно знать, как слова во фразе друг от друга зависят и какие у них модели подчинения. А для этого нужно понимать предложение. Есть синтаксические парсеры, которые строят такую модель, хотя и не очень точно. Берёте такой парсер, понимаете, падеж каких слов нужно поменять, а pymorphy уже этим занимается.
3) Или ещё есть современный вариант: натравливаете GPT-3 / ChatGPT, и (часто) получаете правильный ответ.
Вообще, это стандартная задача NLP, и должна решаться в 5-10 строк. Проверим:
Чтобы перебрать все биграммы, нужно просто написать
Аналогично, если хотите все биграммы с пропуском в одно слово, то
А дальше используем Counter из стандартной библиотеки
Эх, немного не уложился в 5 строк, но в 10 строк уложился ;)
А вообще, есть такое понятие Wiki: PMI , которое гораздо лучше выделит подобные выражения. Просто нужно будет посчитать ещё униграммы и сделать рескоринг для биграмм.
Вот потом после таких опросов и получается непонятно что.
Требования к железке, чтобы работать с неё в путешествии, в офисе и дома -- разные!
В офис нужен нормальный мощный стационарный компьютер с 3 мониторами и отдельной беспроводной клавиатурой, которую можно двигать, а в дорогу -- лёгкий мощный но долгоживущий ноутбук с небольшим ярким дисплеем, в основном, для офисного и мультимедийного применения, потому что компилировать, запускать и отлаживать код, как-либо работающий с пользовательскими интерфейсами на ноутбуке (и фронтенд, и бэкенд) -- ну так себе удовольствие.
А какой у вас доверительный интервал, чтобы понять, что 0.629 лучше, чем 0.613 ? Может, у вас оценки ±5%? Тогда вы не отличите одно от другого, как вам и показывает MAE.
В общем, вы просто не знаете мат статистику, и с умным видом сравниваете случайные величины как обычные числа.
Кроме того (и вот тут вы должны испытывать особый стыд), ROC AUC определяет кривую для всех значений precision и recall, а на практике, вы будете использовать только одно конкретное значение на этой кривой, выбрав threshold. Правильно сравнить две кривые по одному числу нельзя, поэтому вы берёте какую-то функцию от этих кривых, которая даёт число для каждой кривой. И естественно, можно найти одну функцию, по которой одна меньше другой, и функцию, по которой всё наоборот.
Например, если зафиксировать TPR = 0.5 и TPR=0.8 здесь, то получим разные ответы о том, какая кривая лучше (считаем, что линии разного цвета -- это скоры разных моделей).
А если обобщить утверждение Сёрла с «перечисления правил», как в 192х-195х понимали компьютерный интеллект (через онтологии), до просто «современной компьютерной программы, с памятью и графическими ускорителями», тогда всё равно будет комбинаторный взрыв и те же проблемы?