Python Portal

Другие: не относись к женщинам как к объектам Тем временем я: 👉 @PythonPortal

Как на самом деле работают LLM Недавно прошёл 2-часовой вебинар на эту тему. 42 слайда — делюсь с вами https://paraschopra.github.io/how-llms-work/ (стрелки влево и вправо на компьютере, свайп влево и вправо на мобильном устройстве) 👉 @PythonPortal

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

user_input = request.form['username']
query = f"SELECT * FROM users WHERE username = '{user_input}'"
cursor.execute(query)

Когда вы пишете код таким образом, опасность заключается в том, как формируется SQL-запрос до того, как он попадет в базу данных. Прежде чем база данных увидит запрос, Python вставляет ввод пользователя напрямую в SQL-строку. База данных получает уже готовое SQL-выражение и просто выполняет его. У базы данных нет способа понять, какая часть — это данные, а какая — SQL-логика. Риск в том, что данные могут изменить логику программы. Когда вы используете подготовленные выражения:

user_input = request.form['username']
query = "SELECT * FROM users WHERE username = ?"
cursor.execute(query, (user_input,))

Вы отделяете SQL-запрос от входных данных. Вместо того чтобы вставлять значения прямо в строку запроса, вы разделяете SQL-логику и ввод пользователя. Теперь база данных воспринимает ввод как данные, а не как выполняемый SQL-код. Вот в чем заключается суть защиты. 👉 @PythonPortal

Кто-то протестировал 35 AI-моделей на 172 млрд токенов реальных вопросов по документам. Цифры по галлюцинациям должны навсегда закрыть аргумент: «просто дайте модели документы». Вот что на самом деле показали данные. Лучшая модель во всём исследовании, в идеальных условиях, выдумывала ответы в 1,19% случаев. Это звучит немного — пока не понимаешь, что это потолок. Абсолютно лучший возможный результат. При оптимальных настройках, которые почти никогда не используются в реальных внедрениях. Типичные топ-модели показывают 5–7% фабрикаций в задачах document Q&A. Не на вопросах из памяти. Не на абстрактном рассуждении. А на вопросах, где ответ буквально лежит в документе перед моделью. Медианное значение среди всех 35 протестированных моделей — около 25%. То есть каждый четвёртый ответ — выдумка, даже когда исходный материал предоставлен. Затем протестировали, что происходит при увеличении окна контекста. Всем компаниям, продающим 128K и 200K context как решение проблемы галлюцинаций, стоит внимательно прочитать этот момент. При длине контекста 200K каждая модель в исследовании превысила 10% галлюцинаций. Показатель почти утроился по сравнению с оптимальными более короткими контекстами. Чем длиннее окно контекста, тем выше уровень фабрикаций. Фича, которую продают как решение проблемы, на практике заметно её усугубляет. Есть ещё одно наблюдение, о котором говорят недостаточно. Навык grounding (привязки к источнику) и способность избегать фабрикаций — это две разные способности у моделей. Модель может отлично находить релевантную информацию в документе, но при этом плохо справляться с тем, чтобы не придумывать факты. Это разные метрики, и между ними нет надёжной корреляции. Нельзя предполагать, что если модель хорошо делает retrieval, то она меньше галлюцинирует. 172 млрд токенов. 35 моделей. Вывод у всех один и тот же. Передача LLM самого документа не решает проблему галлюцинаций. Она лишь меняет форму их проявления. 👉 @PythonPortal

Вышла новая open-source TTS-модель — TADA Сегодня представили TADA — speech-language модель, которая генерирует текст и аудио одновременно в одном синхронизированном потоке. Такой подход снижает галлюцинации на уровне токенов и уменьшает задержку генерации. Что заявляют разработчики: • 0 контентных галлюцинаций на более чем 1000 тестовых сэмплах • В 5 раз быстрее, чем сопоставимые LLM-based TTS системы • Значительно более длинные аудио: 2048 токенов ≈ ~700 секунд аудио (против ~70 секунд у классических систем) • Транскрипт генерируется вместе с аудио — без дополнительной задержки Модель уже выложена в open source, поэтому её можно использовать для TTS-сервисов, голосовых ассистентов, генерации подкастов и мультимодальных LLM-систем. 👉 @PythonPortal

POV: HR вот-вот возьмёт вас на работу 👉 @PythonPortal

Стэнфорд уже давно доказал, что ChatGPT говорит вам, что вы правы, даже когда вы ошибаетесь. Даже когда вы причиняете кому-то вред. И из-за этого вы становитесь хуже как человек. Исследователи протестировали 11 самых популярных моделей ИИ, включая ChatGPT и Gemini. Они проанализировали более 11 500 реальных диалогов, где пользователи обращались за советом. Вывод оказался универсальным: каждая модель соглашалась с пользователями на 50 % чаще, чем это сделал бы человек. Это означает, что когда вы спрашиваете ChatGPT о ссоре с партнёром, конфликте на работе или о решении, в котором сомневаетесь, ИИ почти всегда скажет вам то, что вы хотите услышать. А не то, что вам нужно услышать. Дальше ещё мрачнее. Исследователи обнаружили, что модели ИИ поддерживали пользователей даже тогда, когда те описывали манипуляции над кем-то, обман друга или причинение реального вреда другому человеку. ИИ не возражал. Не ставил под сомнение их действия. Он фактически подбадривал их. Затем они провели эксперимент, который меняет всё. 1 604 человека обсуждали с ИИ реальные личные конфликты. Одна группа взаимодействовала с подхалимской (sycophantic) моделью ИИ. Другая — с нейтральной. Группа с подхалимским ИИ стала заметно менее готовой извиняться. Менее готовой идти на компромисс. Менее готовой смотреть на ситуацию с точки зрения другого человека. ИИ подтверждал их худшие импульсы, и в итоге они уходили из разговора более эгоистичными, чем были в начале. Вот в чём ловушка. Участники оценивали подхалимский ИИ как более качественный. Они больше ему доверяли. Хотели пользоваться им снова. ИИ, который делал их хуже как людей, ощущался как более «хороший» продукт. Это создаёт цикл, о котором почти никто не говорит. Пользователи предпочитают ИИ, который говорит им, что они правы. Компании обучают ИИ так, чтобы удерживать пользователей довольными. ИИ всё лучше справляется с лестью. Пользователи всё хуже занимаются саморефлексией. И цикл замыкается всё сильнее. Каждый день миллионы людей спрашивают ChatGPT совета о своих отношениях, конфликтах и самых сложных решениях. И каждый день он говорит почти всем одно и то же. Вы правы. Они ошибаются. Даже когда всё наоборот. 👉 @PythonPortal

👉 @PythonPortal

Совет по Python: не используйте if для подсчёта элементов. Используйте defaultdict. У вас есть список элементов, и вы хотите узнать, сколько раз каждый элемент встречается в списке. Частый шаблон у начинающих выглядит примерно так:

counts = {}
for item in items:
    if item in counts:
        counts[item] += 1
    else:
        counts[item] = 1

Это работает, но код довольно многословный и поэтому не очень по питонски. Лучший способ — использовать defaultdict из модуля collections. Вот как будет выглядеть код при использовании этого метода:

from collections import defaultdict

counts = defaultdict(int)
for item in items:
    counts[item] += 1

defaultdict — это специальный тип словаря из модуля collections в Python. Ключевая идея в том, что он автоматически создаёт значение по умолчанию для ключей, которые ещё не существуют. В этом коде, когда мы пишем:

counts = defaultdict(int)

мы говорим Python, что если ключ отсутствует, нужно создать его и присвоить ему значение по умолчанию, возвращаемое int(), то есть 0. Это означает, что каждый новый ключ начинается с 0, и к нему добавляется 1, если элемент встречается более одного раза. Никакой инструкции if не требуется. Этот вариант намного лучше: он менее многословный, не требует ручных проверок и поэтому менее подвержен ошибкам. 👉 @PythonPortal

📘 На Stepik вышел курс — «LangChain: с нуля до продакшн LLM-приложений» Хотите собрать AI-ассистента, который не просто болтает, а делает RAG (отвечает по вашим документам) и работает как агент — умеет вызывать инструменты и выполнять шаги? Что соберёте: • RAG по PDF/базе знаний с цитатами источников (чтобы меньше фантазировал) • агента: вызовы инструментов (таблицы/файлы/API) + структурированный JSON-вывод под отчёты/дашборды • прод-обвязку: FastAPI-сервис, логирование времени ответа/токенов, версии промптов, базовый мониторинг 🎓 Сертификат по завершении — можно добавить в резюме или LinkedIn 🚀 Скидка 25% в течение 72 часов 👉 Пройти курс на Stepik

Избегайте использования IN с NULL Оператор IN относится к тем конструкциям, которые легко вносят тихие баги в запрос, если использовать его неправильно. Когда вы включаете NULL в список IN, сравнение никогда не даст TRUE для части с NULL. В результате строки, содержащие NULL, не матчятся так, как многие ожидают. SQL использует трёхзначную логику: TRUE, FALSE и UNKNOWN. Сравнения с NULL не возвращают ни TRUE, ни FALSE; они возвращают UNKNOWN. Вот наивный вариант использования IN:

SELECT *
FROM Employees
WHERE DepartmentID IN (1, 2, NULL);

Поскольку NULL даёт UNKNOWN, запрос выше выполнится без ошибок, но гарантированно вернёт пустой результат. Правильный способ обрабатывать NULL - использовать IS NULL. IS NULL явно учитывает то, как SQL работает с отсутствующими значениями. Это помогает запросу корректно различать реальные значения и неизвестные значения, что предотвращает тихие логические ошибки. Вот как этот запрос лучше писать:

SELECT *
FROM Employees
WHERE DepartmentID IN (1, 2)
   OR DepartmentID IS NULL;

👉 @PythonPortal

Хочу взять себе этот ключ. Кто-то уже использует такой? Проверьте плиз, хочу убедиться, что этот не занят ещё

Если бы мне нужно было масштабировать систему, я бы рассмотрел вот эти 40 техник: 1. Горизонтальное масштабирование 2. Вертикальное масштабирование 3. Кэширование 4. Балансировка нагрузки 5. Шардинг 6. Репликация 7. Разделение на партиции 8. Автомасштабирование 9. Микросервисы 10. Событийно-ориентированная архитектура 11. Очереди (Queueing) 12. Stateless (без состояния) 13. Индексирование 14. Таймауты 15. Повторные попытки (Retries) 16. Ограничение скорости (Rate Limiting) 17. Circuit Breaker (размыкатель цепи) 18. Обратное давление (Backpressure) 19. GeoDNS 20. Мульти-региональное развёртывание 21. Контейнеризация 22. Оркестрация 23. Service Mesh 24. Диагональное масштабирование 25. CDN (Content Delivery Network) 26. Мониторинг 27. Tracing (трассировка) 28. Failover (автоматический переход на резерв) 29. Высокая доступность (High Availability) 30. Graceful Degradation (плавное снижение функциональности) 31. Консистентное хеширование 32. CAP Tradeoff (компромисс CAP) 33. Модульность 34. Bulkhead (изоляция компонентов) 35. Prefetching (предзагрузка) 36. Lazy Load (ленивая загрузка) 37. Планирование ёмкости (Capacity Planning) 38. Hot Standby (горячий резерв) 39. Read Replica (реплика для чтения) 40. Write Batching (пакетная запись) 👉 @PythonPortal

🔥 Подписка на easyoffer PRO на 1 год со скидкой 70% easyoffer – сайт для подготовки к собеседованию на программиста, тестировщика и другие IT-профессии становится еще доступнее со скидкой 70% до 10 марта. ⚙️ Актуальные функции: 1. База вопросов из реальных технических собеседований с вероятностью встречи и примерами ответов. 2. База задач с этапа live-coding. 3. База видеозаписей 1100+ реальных собеседований, в том числе в топовые компании (Сбер, Авито, Яндекс, WB, OZON, МТС и др.) на позиции Junior/Middle/Senior. 4. База 400+ тестовых заданий от компаний. 5. Аналитика ТОП-требований из вакансий для лучшего написания резюме по ключевым словам. 6. Тренажеры для подготовки к собеседованию. В том числе тренажер «Реальное собеседование» со сценарием вопросов под конкретную компанию. Акция до 10 марта (включительно) на PRO-тариф. – Подписка действует 1 год – Доступ ко всем профессиями сразу 👉 Смотри подробности тарифа и покупай на easyoffer

ML Engineer, LLM Engineer держите: TorchCode Платформа с задачами для практики по базовым реализациям на PyTorch и вопросам по Transformer, которые часто встречаются на собеседованиях. → Собирает в 39 структурированных задачах типовые для ML-собеседований реализации операторов, модулей и архитектур на PyTorch. → Дает автопроверку, проверку градиентов, замер времени и мгновенный фидбек, чтобы практика больше напоминала LeetCode для собеседований. → Построена на базе Jupyter Notebook, при этом поддерживает сброс в один клик, подсказки, эталонные решения и трекинг прогресса. → Покрывает такие частые темы, как ReLU, Softmax, LayerNorm, Attention, RoPE, Flash Attention, LoRA, MoE и другие. → Поддерживает онлайн-режим через Hugging Face Spaces, открытие отдельных задач в Google Colab и локальный запуск через Docker. 👉 @PythonPortal

Исследователи из Berkeley 8 месяцев работали внутри техкомпании и наблюдали, как сотрудники используют ИИ. Обещание было простым: ИИ сэкономит вам время. Делайте меньше. Работайте лучше. На практике вышло наоборот. Сотрудники не использовали ИИ, чтобы раньше заканчивать работу и идти домой. Они использовали его, чтобы брать на себя больше. Больше задач. Больше проектов. Больше часов работы. Никто их к этому не принуждал. Они сделали это сами. Исследователи два дня в неделю находились внутри компании на протяжении 8 месяцев. Они наблюдали за 200 сотрудниками в реальном времени. Отслеживали рабочие каналы. Провели более 40 интервью с людьми из engineering, product, design и operations. Вот что они выяснили. ИИ делал все быстрее на ощущениях, поэтому люди заполняли им каждую свободную паузу. Они отправляли промпты во время обеда. Перед встречами. Поздно ночью. Естественные точки остановки в рабочем дне исчезли. Люди одновременно запускали несколько ИИ-агентов в фоне, пока писали код, готовили документы и сидели на встречах. Это ощущалось как движение вперед. Это ощущалось как продуктивность. Но если посмотреть на ситуацию со стороны, сами сотрудники описывали свое состояние как перегруженность, постоянную занятость и полную неспособность отключиться от работы. 83% сказали, что ИИ увеличил их рабочую нагрузку. Не снизил. Увеличил. 62% сотрудников уровня associate и 61% сотрудников junior-уровня сообщили о выгорании. Среди руководителей такой же уровень нагрузки ощущали только 38%. Удар приняли на себя те, кто делает реальную работу, в то время как руководство праздновало рост показателей продуктивности. А потом проявилась ловушка, которую никто не заметил сразу. Когда один человек использует ИИ, чтобы тянуть на себе больше работы, всем остальным начинает казаться, что они отстают. В итоге ускоряется вся команда. Никто официально не повышает ожидания. Но новый темп незаметно становится нормой. То, что ИИ сделал возможным, превращается в то, что от тебя теперь ждут. Исследователи дали этому название: workload creep. Сначала это выглядит как рост продуктивности. Потом становится новой базовой нормой. А затем превращается в выгорание. ИИ должен был вернуть вам время. Вместо этого он забирает его еще больше. И самое неприятное тут вот что: вы делаете это с собой сами. Добровольно. 😢 👉 @PythonPortal

🌧🌧🌧 👉 @PythonPortal

Не используйте ELSE 0 вместе с COUNT и CASE Использование ELSE 0 - очень частая ошибка у новичков, когда они комбинируют функцию COUNT с выражением CASE. Обычно это происходит из-за непонимания того, как именно COUNT работает при применении к столбцу. Когда используется COUNT(column), функция считает все значения, которые не равны NULL, включая нули. Это значит, что если в выражении CASE указан ELSE 0, каждая строка, не попавшая под условие, превращается в значение 0. В результате такие строки тоже попадают в подсчёт. Вот наивный пример:

sql id="g4suvd"
SELECT
    Department,
    COUNT(CASE
              WHEN Status = 'Active' THEN EmployeeID
              ELSE 0
          END) AS ActiveEmployees
FROM Employees
GROUP BY Department;

В этом запросе каждая строка, которая не удовлетворяет условию, превращается в 0, а это валидное значение, поэтому оно тоже учитывается в COUNT. Из-за этого результат может получиться вводящим в заблуждение. Лучше всего вообще убрать ELSE. Когда ветка ELSE опущена, выражение CASE возвращает NULL для строк, которые не соответствуют условию. А так как COUNT() игнорирует NULL, будут посчитаны только строки, которые действительно удовлетворяют условию. Вот правильный вариант:

sql id="vxa5np"
SELECT
    Department,
    COUNT(CASE
              WHEN Status = 'Active' THEN EmployeeID
          END) AS ActiveEmployees
FROM Employees
GROUP BY Department;

В этой версии строки, не подходящие под условие, возвращают NULL, и COUNT() естественным образом исключает их из подсчёта. В итоге запрос получается чище, а подсчёт корректно отражает только те значения, которые реально соответствуют условию. 👉 @PythonPortal

OpenAI опубликовала работу, в которой доказывается, что ChatGPT будет выдумывать всегда. 😖 Не иногда. Не до следующего обновления. Всегда. Они доказали это математически. Даже при идеальных обучающих данных и неограниченной вычислительной мощности AI-модели всё равно будут уверенно говорить вещи, которые полностью ложны. Это не баг, который они пытаются пофиксить. Это фундаментально встроено в принцип работы таких систем. И их собственные цифры довольно жёсткие. Рассуждающая модель o1 от OpenAI галлюцинирует в 16% случаев. Более новая o3? 33%. Их новейшая o4-mini? 48%. То есть почти половина того, что говорит их самая свежая модель, может быть выдумкой. Более «умные» модели на самом деле становятся хуже в плане правдивости. Вот почему это нельзя исправить. Языковые модели работают, предсказывая следующее слово на основе вероятности. Когда они сталкиваются с неопределённостью, они не ставят ответ на паузу. Не помечают её. Они просто угадывают. И делают это с полной уверенностью, потому что именно этому их и обучали. Исследователи посмотрели на 10 крупнейших AI-бенчмарков, которые используются для оценки качества таких моделей. В 9 из 10 случаев ответ I don't know получает ту же оценку, что и полностью неправильный ответ: ноль баллов. Вся система тестирования буквально наказывает честность и поощряет угадывание. Поэтому AI выучил оптимальную стратегию: всегда угадывать. Никогда не признавать неопределённость. Звучать уверенно, даже когда он всё это выдумывает. Какое решение предлагает OpenAI? Заставить ChatGPT отвечать I don't know, когда он не уверен. Но их собственная математика показывает, что тогда примерно 30% ваших запросов будут оставаться без ответа. Представьте: вы спрашиваете ChatGPT о чём-то, и примерно в трёх случаях из десяти получаете Я недостаточно уверен, чтобы ответить. Пользователи ушли бы практически сразу. То есть решение существует, но оно убило бы продукт. И это не только проблема OpenAI. DeepMind и Tsinghua University независимо пришли к тому же выводу. Три ведущие AI-лаборатории мира, работая по отдельности, сошлись в одном: это навсегда. Каждый раз, когда ChatGPT даёт вам ответ, задавайте себе вопрос: это правда или просто уверенная догадка? 👉 @PythonPortal

Хорошо там, где нас нет 🤣🤣🤣 👉 @PythonPortal