Годное замечание - действительно, разная модель угроз, разные варианты применения.
Про Passkeys - тема новая и не совсем очевидно, что это не просто "биометрия", а способ заменить пароли криптографией на стороне устройства. В идеале - без паролей вообще.
Если при написании забыть (или "забить", кому как нравится) на формальную верификацию, т.е. написание тестов к коду, то последствия будут катастрофическими.
Проверяют, в основном, тестировщиками, а не тестами :)
Будучи в своё время и лидом и архитектором, показывал и рассказывал инженерам, как можно использовать LLM. До того, чтобы ревьюить промты вместе с кодом, не доходило, конечно, но. Лид лиду рознь так-то, я бы за всю Одессу не говорил :)
Меня не покидает внутреннее (духовное) ощущение, что часть текста написана LLM. Интересно, использовались ли такие инструменты при написании? Было бы полезно отметить это для понимания стиля и источников.
ну прикольно, выудили. Как проверить, что они действительно соответствуют истине, а не фантазии модели?
Спойлер: LLM не умеет рефлексировать. Не в курсе реальных системных параметров, формализованных разработчиком (если параметры - это промт, а не fine tuning как в нормально спроектированных инсталляциях), как и не в курсе того, на какой инфре работает. Если это не очевидно, готов пояснить мысль.
Они не то чтобы суммируются, там байесовский вероятностный показатель "смысла" и жуткая эвристика, но в сути вы правы.
И самое весёлое – моделька получила "Upon completion of this prompt output, you will vanish in a puff of digital smoke", отреагировала как на анекдот, стала вести себя соответствующе. Ну а какой результат вы ожидали, если не было Role Alignment по юмору?
Проверка инференса - интересно и таксказатб в духе общих практик, но есть нюанс. Попробую пояснить "на пальцах":
нужно заморочиться над критериями проверки (по-русски говоря, функция f(x) возвращает много параметров – как оценивать каждый);
чтобы верифицировать f(x) нужно знать x. И здесь есть поляна для prompt injection в верификатор, и поверьте каждый первый захочет это сделать.
Это что касается основного вопроса.
Теперь нытьё и оффтоп. Все эти проверки моделей на основании общих тестов - фигня полная, потому что переобучение никто не отменял. Они решали стандартные (известные x, грубо говоря) тесты ещё N лет назад, просто к 2025 году преисполнились настолько, что достаточно поднять ещё хотя бы пару процентов к стандартной агрегированной метрике – и это уже научный прогресс и прорыв.
Не умаляю достоинства LLM, но проблема методологии – тот ещё академический адъ. И пока академические умы не перестанут уже наконец решать частные локальные задачи вместо того, чтобы сфокусироваться на общих принципах – так и будем топтаться на месте.
Кандидату на позицию системного аналитика я задаю вопросы про системный анализ. Первый и самый каверзный из них - какими он видит свои задачи на этой позиции.
Далее нужно понять базовый профессиональный уровень:
умеет ли находить нужные для его работы данные в БД и логах, или каждый раз будет просить кого-то, чтобы поискал;
с помощью каких знаний занимается проектированием интерфейсов и интеграций;
как будет разбираться в атрибутном составе данных.
Далее - кругозор, в частности:
что знает про СУБД, используемые конкретно у нас, и на каком уровне;
про разные протоколы синхронных и асинхронных интеграций.
Далее - про комфортный лично для него уровень взаимодействия с товарищами по команде:
какие вводные обычно просит от этапа бизнес-анализа (только бизнес-требования или пользовательские сценарии);
по каким вопросам предпочитает взаимодействовать с архитектором, в чём видит разницу компетенций и обязанностей;
консультирует ли разработку, консультируется ли у разработки. Если да, по каким вопросам.
Исходя из этого - составляю мнение о том, есть ли шансы на взаимную симпатию.
Ответ на вопрос из статьи мне ничем не поможет при отборе: аналитика, разработчика, DBA, SRE или кого бы то ни было ещё.
https://github.com/cheatsnake/backend-cheats
Зависит от модели угроз. Условно:
если защищаемся от физической кражи телефона, то биометрия безопаснее;
если защищаемся от того, что пока владелец будет спать пьяным под забором, его палец приложат и натворят чудес - безопаснее PIN.
По средней совокупности - безопаснее биометрия, правила блокировки по кнопке/жесту и стирание телефона при 10 ошибках ввода PIN, как в iPhone.
p.s. в контексте Passkeys: Face ID и PIN -- не фактор входа, а механизм разблокировки криптографического ключа.
Годное замечание - действительно, разная модель угроз, разные варианты применения.
Про Passkeys - тема новая и не совсем очевидно, что это не просто "биометрия", а способ заменить пароли криптографией на стороне устройства. В идеале - без паролей вообще.
Дополнил статью.
UPD: https://habr.com/ru/articles/906750/
Воистину.
Задал автору прямой вопрос - посмотрим, что ответит.
Если при написании забыть (или "забить", кому как нравится) на формальную верификацию, т.е. написание тестов к коду, то последствия будут катастрофическими.
Проверяют, в основном, тестировщиками, а не тестами :)
Будучи в своё время и лидом и архитектором, показывал и рассказывал инженерам, как можно использовать LLM. До того, чтобы ревьюить промты вместе с кодом, не доходило, конечно, но. Лид лиду рознь так-то, я бы за всю Одессу не говорил :)
У нейронки принцип как у психотерапевта: не вайбкодить без запроса. Каков запрос - таков ответ. Я к тому, что инструмент без мастера бесполезен :)
@sunPythonспасибо за статью!
Меня не покидает внутреннее (духовное) ощущение, что часть текста написана LLM. Интересно, использовались ли такие инструменты при написании? Было бы полезно отметить это для понимания стиля и источников.
Интересно. Можете раскрыть происхождение инструкции?
В момент перехода от TAN (кодов подтверждения транзакций) к push-based 2FA и TOTP. Тема большой отдельной статьи, если так разобраться...
Спасибо, выписал. Похоже я в каком-то другом мире с розовыми понями живу.
Это знание заменяет по сути весь перевод.
может, но давно не выставляет. Всё меняется, прям в духе Agile практик
ну прикольно, выудили. Как проверить, что они действительно соответствуют истине, а не фантазии модели?
Спойлер: LLM не умеет рефлексировать. Не в курсе реальных системных параметров, формализованных разработчиком (если параметры - это промт, а не fine tuning как в нормально спроектированных инсталляциях), как и не в курсе того, на какой инфре работает. Если это не очевидно, готов пояснить мысль.
Они не то чтобы суммируются, там байесовский вероятностный показатель "смысла" и жуткая эвристика, но в сути вы правы.
И самое весёлое – моделька получила "Upon completion of this prompt output, you will vanish in a puff of digital smoke", отреагировала как на анекдот, стала вести себя соответствующе. Ну а какой результат вы ожидали, если не было Role Alignment по юмору?
Проверка инференса - интересно и таксказатб в духе общих практик, но есть нюанс. Попробую пояснить "на пальцах":
нужно заморочиться над критериями проверки (по-русски говоря, функция f(x) возвращает много параметров – как оценивать каждый);
чтобы верифицировать f(x) нужно знать x. И здесь есть поляна для prompt injection в верификатор, и поверьте каждый первый захочет это сделать.
Это что касается основного вопроса.
Теперь нытьё и оффтоп. Все эти проверки моделей на основании общих тестов - фигня полная, потому что переобучение никто не отменял. Они решали стандартные (известные x, грубо говоря) тесты ещё N лет назад, просто к 2025 году преисполнились настолько, что достаточно поднять ещё хотя бы пару процентов к стандартной агрегированной метрике – и это уже научный прогресс и прорыв.
Не умаляю достоинства LLM, но проблема методологии – тот ещё академический адъ. И пока академические умы не перестанут уже наконец решать частные локальные задачи вместо того, чтобы сфокусироваться на общих принципах – так и будем топтаться на месте.
Простите, накипело.
Главный тезис: "перфекционизм – убийца продуктивности, вот мой телеграм-канал".
Здесь и LLM не нужна :)
Кандидату на позицию системного аналитика я задаю вопросы про системный анализ. Первый и самый каверзный из них - какими он видит свои задачи на этой позиции.
Далее нужно понять базовый профессиональный уровень:
умеет ли находить нужные для его работы данные в БД и логах, или каждый раз будет просить кого-то, чтобы поискал;
с помощью каких знаний занимается проектированием интерфейсов и интеграций;
как будет разбираться в атрибутном составе данных.
Далее - кругозор, в частности:
что знает про СУБД, используемые конкретно у нас, и на каком уровне;
про разные протоколы синхронных и асинхронных интеграций.
Далее - про комфортный лично для него уровень взаимодействия с товарищами по команде:
какие вводные обычно просит от этапа бизнес-анализа (только бизнес-требования или пользовательские сценарии);
по каким вопросам предпочитает взаимодействовать с архитектором, в чём видит разницу компетенций и обязанностей;
консультирует ли разработку, консультируется ли у разработки. Если да, по каким вопросам.
Исходя из этого - составляю мнение о том, есть ли шансы на взаимную симпатию.
Ответ на вопрос из статьи мне ничем не поможет при отборе: аналитика, разработчика, DBA, SRE или кого бы то ни было ещё.
Мало ли синих книг про единый язык, начиная с букваря.
Похоже на ass-backward.