Pull to refresh
40
0
Алексей Сушков @AlexeySushkov

Инженер

Send message

ReRanker CrossEncoder, NLI-модели, zero-shot классификаторы - это разные алгоритмы, но все они используется для более качественного отбора чанков, которые далее передеются в модель для ответа.

Есть ещё вариант использовать NLI-модели (Natural Language Inference), чтобы проверить, следует ли ответ модели из переданного контекста (например, roberta-large-mnli).

Расшифровка фразы “система начала буксовать”:

“Примерно 47 процентов выпускников российских вузов не работают по специальности. Об этом сообщил статс-секретарь - заместитель министра науки и высшего образования РФ Петр Кучеренко, передает ТАСС. https://www.pnp.ru/social/v-minobrnauki-soobshhili-chto-pochti-polovina-vypusknikov-vuzov-rabotaet-ne-po-specialnosti.html

Это значит, что государство тратит впустую половину денег на высшее образование! Явно система не работает. Но как ее изменить не буду советовать, т.к. для этого должны быть люди более осведомленные и знающие как работают системы образования.

Хочу сказать спасибо всему сообществу за активное обсуждение статьи! Честно прочитав 600 комментариев, дополню раздел про ЕГЭ, т.к. он вызвал наиболее активно обсуждение. Не буду явно делить аргументы на "за" и "против", т.к. это деление зависит от мировоззрения человека:

  • С введением ЕГЭ появилась возможность одновременно подавать документы в несколько вузов. Однако такая система создает неопределенность как для абитуриентов, так и для самих учебных заведений, нужна сквозная система приоритетов между вузами.

  • Часто в вузы стали поступать менее мотивированные студенты, для которых не имеет значения, куда идти учиться.

  • С введением ЕГЭ обеспечен равный доступ к поступлению в вузы для жителей как городов, так и удаленных деревень. Для подач и документов и прохождения экзаменов не нужно пересекать всю страну.

  • До ЕГЭ имели место случаи коррупции и блата при поступлении в вузы. ЕГЭ включает механизмы, направленные на снижение коррупционных рисков.

  • До введения ЕГЭ в вузах существовали подготовительные курсы, которые иногда были необходимы для успешного поступления.

  • После введения ЕГЭ в вузы стали поступать студенты, не всегда обладающие достаточными знаниями по предметам, необходимым для конкретных учебных заведений.

  • С введением ЕГЭ у школьных учителей появилась возможность заниматься репетиторством.

  • До ЕГЭ некоторые вузы требовали от абитуриентов знания, которые не входили в школьную программу.

  • Теперь школы часто сосредотачиваются на подготовке к ЕГЭ, вместо того чтобы предоставлять широкий спектр знаний.

  • Несмотря на шаблонность ЕГЭ, истинный талант всегда найдет способ проявиться, невзирая на условия.

  • Умение успешно решать задачи из ЕГЭ является показателем интеллектуальных способностей человека.

  • ЕГЭ заменил выпускные экзамены в школе, которые не имели большой значимости и часто были субъективными.

  • ЕГЭ имеет четкую формализацию. Большинство заданий проверяется автоматически, и формальные критерии оценки понятнее для большинства людей.

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

  • ЕГЭ — это тест, основанный на научных принципах, в идеале не должно быть студентов, набравших 100 баллов, или их количество должно быть крайне низким.

  • В то время как составитель ЕГЭ в стране в основном один, количество авторов вступительных экзаменов в вузы исчисляется тысячами, что делает экзаменационную систему более стабильной.

  • ЕГЭ предоставляет объективную оценку знаний всех школьников в стране. Результаты ЕГЭ используются для анализа качества среднего образования на уровне страны, регионов и отдельных школ.

  • Введение ЕГЭ открыло возможности для манипуляции статистикой, позволяя изменять уровень сложности заданий.

  • ЕГЭ удобно и недорого администрировать, принимать управленческие решения на основе его результатов. ЕГЭ создает иллюзию контроля над ситуацией.

Если будет https, то заголовки будут зашифрованными

При установлении mTLS сервер получает сертификат клиента, в котором указаны все IP и адреса, для которых этот сертификат валидин. Соответственно, сервер должен проверить, что запрос пришел с адреса, который есть в сертификате.

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

Но сначала, лучше самому пройти все по шагам, чтобы понимать как работает и где может косячить готовое решение.
Вот это точно лучшая практика: если не знаешь как сделать, сделай по стандарту!
If Issuer discovery is supported

В этом случае, согласен, адрес issuer должен совпадать с iss в токене. Но discovery процедура входит в список требований из раздела: «15.2. Mandatory to Implement Features for Dynamic OpenID Providers», а Google заявлеяет поддержку только общих требований" «Mandatory to Implement Features for All OpenID Providers», поэтому может не выполнять обязательные требования для discovery.
issuer должен начинаться с https://

В спорных моментах я обычно обращаюсь к стандартам. Смотрим документ OpenID Connect Core 1.0

С одной стороны, вы правы и https обязателен:
2. ID Token
iss — Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

Но с другой стороны, для Google сделано исключение:
15.6.2. Google «iss» Value
Implementers may want to be aware that, as of the time of this writing, Google's deployed OpenID Connect implementation issues ID Tokens that omit the required https:// scheme prefix from the iss (issuer) Claim Value.
Брать готовое решение хорошо, когда понимаешь что происходит под капотом. Должен:
iss — The Issuer Identifier for the Issuer of the response. Always accounts.google.com or accounts.google.com for Google ID tokens.

Не совсем все равно
Спасибо за замечания, согласен, что алгоритм валидации токена важен, поэтому добавил его в статью:
• Проверяем, что id_token подписан Google. Для этого нужен открытый ключ от Google. Google хранит актуальную аутентификационную информацию по стандартному адресу: accounts.google.com/.well-known/openid-configuration. Адрес сертификатов находится в параметре «jwks_uri».
• В токене параметр iss должен содержать адрес Google: accounts.google.com
• Параметр aud должен быть равен Client ID нашего приложения, который получен раннее на сайте Google.
• Параметр exp содержит время окончания действия токена, оно должно быть не просрочено.
В статье описан и в заготовке используется именно OpenID Connect от Google. В результате работы алгоритма возвращается id_token, с помощью которого происходит аутентификация. Другое дело, что функциональность discovery в заготовке, действительно, не реализована, но сделать ее при необходимости несложно, ведь Google поддерживает стандартный endpoint с информацией об остальных endpoints:
accounts.google.com/.well-known/openid-configuration
Сама заготовка сделана на конкретном стеке технологий: SQLite + Express.js + Vue.js + Node.js. Но статья больше не про технологии, а лучшие практики. Ведь не важно, какой стек технологий используются, в любом случае, нужно обеспечивать безопасность API, реализовывать аутентификацию пользователей, делать структуру базы данных, защищаться от DoS, логировать, мониторить и т.д.
Согласен, что из введения не очень понятны ответы на ваши вопросы. Описанное в статье техническое решение, конечно, не PoC, а стандартное веб-приложение. И я предлагаю не PoC, а стандартную основу или заготовку для реализации любых PoC, которые планируется реализовать в клиент-серверной архитектуре с использованием веб-технологий. Чтобы эта заготовка стала настоящим PoC в какой-нибудь области (IoT, телеком, финансы, медицина) к ней, надо прикрутить функциональность взаимодействия с внешними системами.
Спасибо за комментарий, в статье я, действительно, не уделяю внимание вопросу запуска приложений в промышленную эксплуатацию. Это тема для отдельного раздела или статьи.

«Рекомендации не использовать ORM-ки» не встречал. Могу предположить, что возможная причина таких рекомендаций может быть в неоптимальной работе ORM. Но оптимизация — тоже относится к промышленной эксплуатации системам, к которым предьявляются требования по производительности и времени отклика.
В статье рассматривается PoC, построенный на веб технологиях в архитектуре клиент-сервер. Перечисленный набор компонентов является стандартным для данного класса PoC.
Согласен и OWASP об этом явно говорит в разделе: Sensitive information in HTTP requests
Добавил пункт в список: «API7:2019 Security Misconfiguration»
OWASP рекомендует (Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:

  • Role-Based Access Control (RBAC)
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Permission Based Access Control

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity