Насколько я понял, адвокаты сами сознаются, так как это несёт меньше проблем чем "я целенаправленно соврал". Но вообще там типичные признаки: сгалюцинированные кейсы которых никогда не было и несуществующие
То есть в случае для входа используется именно пара email/пароль?
Логика говорит, что наверное стоит спрашивать email как он был введён пользователем изначально. Пользователь знал, что он делал. Наверное. Кроме, может быть, таки регистра, потому что многие считают и ожидают что email регистронезависим. А если нужно отправить email - использовать адрес в точности как его ввёл пользователь. Если вы при регистрации отправляли письмо и пользователь подтвердил получение - то вы уже знаете, что письмо дойдёт.
Аналогично. Я не говорю что вы должны делать case sensitive на почтовом сервере. В rfc написано сервер может делать с ними что ему вздумается, пока он следует корректному синтаксису адресов. Хоть всю почту в один ящик скинуть.
Вопрос именно в том, как сторонние сервисы воспринимают адрес получателя. Для максимальной совместимости "нормализовать" (к чему?) и менять регистр нельзя.
"Не приветствуется" и "никогда не случится" - это разные вещи. Лично я исхожу из принципа, что нужно следовать пессимистичному сценарию: - С точки зрения сервиса отправляющего почту - что адреса должны быть именно в той форме, в которой адрес дал ему пользователь, иначе почтовый сервис не доставит письмо. - С точки зрения почтового сервера - что сервис отправляющий почту будет творить всякую ересь вроде попытки "канонизировать" адрес только по одному сервису известному принципу.
Я не говорю что такого не существует или не должно существовать, но я ни разу не видел сервиса который мы давал имя пользователя на основе email. Это всегда заполняемое вручную поле. И если я ввёл адрес с суффиксом - это значит я хочу получать корреспонденцию от сервиса именно на имя с суффиксом.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением.
Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith".
Мой коммент скорее про то, что у email нет канонического вида. У каждого сервера свои правила - тот же гугл - наверное единственный, кто точку в адресе игнорирует. А по поводу нормализации для ДБ - я, как пользаватель, ожидаю что user+test1@gmail.com и user+test2@gmail.comкак раз два разных адреса с точки зрения сервиса. Ну и как бы email-адреса авторизации скрывать принято. А если сервис боится, что пользователь зарегистрирует два аккаунта, то ему придётся с этим смериться. Пользователь может создать второй ящик.
Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Я не пробовал конкретно ChatGPT, но все модели что я пробовал (локальные и нет) теряют когерентность после ~8к токенов контекста. Они либо начинают зацикливаться на одной фразе и повторять его из сообщения в сообщение, либо откапывают инструкцию из истории и следуют ей (несмотря на указания больше не следовать), либо просто несут отборную чушь.
При этом до 8к контекста они работают... приемлемо (не хорошо, а именно приемемо). И вот к слову, именно на тот тип вопросов, что вы задаёте, лично я мне быстрее найти самому, чем спрашивать ИИ и потом разбираться в его галлюцинациях (если я ищу чем угодно кроме Гугла, их поиск последнее время неописуемо ужасен)
Только у границы, да и не стоит оно того. Симку в том числе оплачивать надо, что не тривиально в нынешних условиях.
У нас возможность подключения к мобильной сети Польши или Литвы скорее как проблема рассматривается, когда телефон в международный роуминг сам уходит. в 2010х обычной практикой было отключать автоматический поиск и выбор сети.
В Калининградской области всё, что заблокировано - действительно заблокировано. У нас тут всего 4 линка с внешним миром, если я не ошибаюсь, и все они управляются Ростелекомом.
Всё равно когерентного диалога не получается. Модель обычно слишком зацикливается на том, что вытащено из базы автоматом, даже если информация не релевантна.
Ну кстати Vedal упомянул, что Neuro зачастую работает бес присмотра потому что ему влом присматривать, но по условиям платформы он должен сказать, что присматривает. Но крышу ей периодичести рвёт всё так же. Она в принципе делает то, что и все остальные сети: "Выглядит реалистично"
Это точно проблема моделей. Разные ломаются по разному, но если вы хотите "кошкожену" с постоянной памятью - не получится. (я тут шучу, но там у них дефолтный персонаж пользователя - "Romanian catgirl")
В "агентах" что я пытался построить сам - крыша у AI едет так же быстро, если не быстрее.
У них инсталлер есть, по крайней мере для самого SillyTavern. Но не ожидайте многого, персонаж действует реалистично пока внезапно AI на ровном месте не ломается и не начинает пороть чушь или просто повторять по кругу уже сказанное. Обычно на 10-11 реплике в чате.
Ок, а как должен тогда выглядить пайплайн по вашему мнению?
В моих тестах AI не смог даже нормально DTO на основе примера json'а составить, следуя указанному стилю. То, что он писал не распарсило бы json-пример, а в ответ на указание ошибки он меня уверял, что всё в порядке и должно работать. Конкретно он автоматом snake_сase в camelCase конвертил. Чтобы это работало нужно было либо прописать имена полей вручную, либо передать параметр в парсер. О втором варианте я на тот момент не знал, AI мне о нём не рассказал, и более того, в коде-примере использования не передавал его сам.
И того, на DTO с AI убито 30 минут времени, вручную писать - 5-10.
Насколько я понял, адвокаты сами сознаются, так как это несёт меньше проблем чем "я целенаправленно соврал".
Но вообще там типичные признаки: сгалюцинированные кейсы которых никогда не было и несуществующие
Вот как пример:
https://www.youtube.com/watch?v=6RBQrcp0Lrg
Это случайно не одна и та же "юридическая фирма"?
https://habr.com/ru/news/917128/
То есть в случае для входа используется именно пара email/пароль?
Логика говорит, что наверное стоит спрашивать email как он был введён пользователем изначально. Пользователь знал, что он делал. Наверное.
Кроме, может быть, таки регистра, потому что многие считают и ожидают что email регистронезависим. А если нужно отправить email - использовать адрес в точности как его ввёл пользователь. Если вы при регистрации отправляли письмо и пользователь подтвердил получение - то вы уже знаете, что письмо дойдёт.
Захожу на Google (по привычке)
Ввожу запрос
Вижу бред в ИИ сводке и бред в первых результатах
Ухожу на Duckduckgo
Но да, я увидел ИИ-сводку и не нажал ни одной ссылки
Аналогично. Я не говорю что вы должны делать case sensitive на почтовом сервере. В rfc написано сервер может делать с ними что ему вздумается, пока он следует корректному синтаксису адресов. Хоть всю почту в один ящик скинуть.
Вопрос именно в том, как сторонние сервисы воспринимают адрес получателя. Для максимальной совместимости "нормализовать" (к чему?) и менять регистр нельзя.
"Не приветствуется" и "никогда не случится" - это разные вещи.
Лично я исхожу из принципа, что нужно следовать пессимистичному сценарию:
- С точки зрения сервиса отправляющего почту - что адреса должны быть именно в той форме, в которой адрес дал ему пользователь, иначе почтовый сервис не доставит письмо.
- С точки зрения почтового сервера - что сервис отправляющий почту будет творить всякую ересь вроде попытки "канонизировать" адрес только по одному сервису известному принципу.
Нельзя lowercase. email case sensitive в общем случае.
Я не говорю что такого не существует или не должно существовать, но я ни разу не видел сервиса который мы давал имя пользователя на основе email. Это всегда заполняемое вручную поле. И если я ввёл адрес с суффиксом - это значит я хочу получать корреспонденцию от сервиса именно на имя с суффиксом.
Сохраните email как его ввёл пользователь и не пытайтесь его обработать:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.11
Не надо. И таки да, по RFC это два разных email:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.4
А зачем их вообще проверять? Я, как пользователь, ожидаю, что сервис их будет обрабатывать именно как два разных ящика.
Мой коммент скорее про то, что у email нет канонического вида. У каждого сервера свои правила - тот же гугл - наверное единственный, кто точку в адресе игнорирует.
А по поводу нормализации для ДБ - я, как пользаватель, ожидаю что
user+test1@gmail.comиuser+test2@gmail.comкак раз два разных адреса с точки зрения сервиса. Ну и как бы email-адреса авторизации скрывать принято.А если сервис боится, что пользователь зарегистрирует два аккаунта, то ему придётся с этим смериться. Пользователь может создать второй ящик.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Просто пошлите письмо
Я не пробовал конкретно ChatGPT, но все модели что я пробовал (локальные и нет) теряют когерентность после ~8к токенов контекста. Они либо начинают зацикливаться на одной фразе и повторять его из сообщения в сообщение, либо откапывают инструкцию из истории и следуют ей (несмотря на указания больше не следовать), либо просто несут отборную чушь.
При этом до 8к контекста они работают... приемлемо (не хорошо, а именно приемемо).
И вот к слову, именно на тот тип вопросов, что вы задаёте, лично я мне быстрее найти самому, чем спрашивать ИИ и потом разбираться в его галлюцинациях (если я ищу чем угодно кроме Гугла, их поиск последнее время неописуемо ужасен)
Только у границы, да и не стоит оно того. Симку в том числе оплачивать надо, что не тривиально в нынешних условиях.
У нас возможность подключения к мобильной сети Польши или Литвы скорее как проблема рассматривается, когда телефон в международный роуминг сам уходит. в 2010х обычной практикой было отключать автоматический поиск и выбор сети.
В Калининградской области всё, что заблокировано - действительно заблокировано. У нас тут всего 4 линка с внешним миром, если я не ошибаюсь, и все они управляются Ростелекомом.
Всё равно когерентного диалога не получается. Модель обычно слишком зацикливается на том, что вытащено из базы автоматом, даже если информация не релевантна.
Ну кстати Vedal упомянул, что Neuro зачастую работает бес присмотра потому что ему влом присматривать, но по условиям платформы он должен сказать, что присматривает. Но крышу ей периодичести рвёт всё так же. Она в принципе делает то, что и все остальные сети: "Выглядит реалистично"
Это точно проблема моделей. Разные ломаются по разному, но если вы хотите "кошкожену" с постоянной памятью - не получится. (я тут шучу, но там у них дефолтный персонаж пользователя - "Romanian catgirl")
В "агентах" что я пытался построить сам - крыша у AI едет так же быстро, если не быстрее.
У них инсталлер есть, по крайней мере для самого SillyTavern. Но не ожидайте многого, персонаж действует реалистично пока внезапно AI на ровном месте не ломается и не начинает пороть чушь или просто повторять по кругу уже сказанное. Обычно на 10-11 реплике в чате.
Ок, а как должен тогда выглядить пайплайн по вашему мнению?
В моих тестах AI не смог даже нормально DTO на основе примера json'а составить, следуя указанному стилю. То, что он писал не распарсило бы json-пример, а в ответ на указание ошибки он меня уверял, что всё в порядке и должно работать. Конкретно он автоматом snake_сase в camelCase конвертил. Чтобы это работало нужно было либо прописать имена полей вручную, либо передать параметр в парсер. О втором варианте я на тот момент не знал, AI мне о нём не рассказал, и более того, в коде-примере использования не передавал его сам.
И того, на DTO с AI убито 30 минут времени, вручную писать - 5-10.