Оказалось, что история с покупкой доступа к якобы топовым моделям, а по факту к подменённым, наконец получила подтверждение в статье.

Исследователи провели аудит 17 сторонних API для LLM-агентов и выяснили:

• почти 46% endpoint'ов не проходят fingerprint-тесты
• API заявляет, что это GPT-5 или Gemini-2.5, а на бэкенде тихо подставлен GLM-4
• точность на медицинском бенчмарке падает с 83% до 37%

Эти фейковые API уже процитированы в 187 научных статьях, а некоторые связанные с ними проекты набрали почти 60 тысяч звёзд на GitHub.

И главная проблема тут в том, что научные выводы строятся на поддельных моделях.

Статья: https://arxiv.org/abs/2603.01919

👉 @PythonPortal

Монолит VS микросервисы

👉 @PythonPortal

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

👉 @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

Не используйте 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

🌧🌧🌧


👉 @PythonPortal

Исследователи из Berkeley 8 месяцев работали внутри техкомпании и наблюдали, как сотрудники используют ИИ.

Обещание было простым: ИИ сэкономит вам время. Делайте меньше. Работайте лучше.

На практике вышло наоборот.

Сотрудники не использовали ИИ, чтобы раньше заканчивать работу и идти домой. Они использовали его, чтобы брать на себя больше. Больше задач. Больше проектов. Больше часов работы. Никто их к этому не принуждал. Они сделали это сами.

Исследователи два дня в неделю находились внутри компании на протяжении 8 месяцев. Они наблюдали за 200 сотрудниками в реальном времени. Отслеживали рабочие каналы. Провели более 40 интервью с людьми из engineering, product, design и operations.

Вот что они выяснили. ИИ делал все быстрее на ощущениях, поэтому люди заполняли им каждую свободную паузу. Они отправляли промпты во время обеда. Перед встречами. Поздно ночью. Естественные точки остановки в рабочем дне исчезли. Люди одновременно запускали несколько ИИ-агентов в фоне, пока писали код, готовили документы и сидели на встречах.

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

83% сказали, что ИИ увеличил их рабочую нагрузку. Не снизил. Увеличил.

62% сотрудников уровня associate и 61% сотрудников junior-уровня сообщили о выгорании. Среди руководителей такой же уровень нагрузки ощущали только 38%. Удар приняли на себя те, кто делает реальную работу, в то время как руководство праздновало рост показателей продуктивности.

А потом проявилась ловушка, которую никто не заметил сразу. Когда один человек использует ИИ, чтобы тянуть на себе больше работы, всем остальным начинает казаться, что они отстают. В итоге ускоряется вся команда. Никто официально не повышает ожидания. Но новый темп незаметно становится нормой. То, что ИИ сделал возможным, превращается в то, что от тебя теперь ждут.

Исследователи дали этому название: workload creep.

Сначала это выглядит как рост продуктивности. Потом становится новой базовой нормой. А затем превращается в выгорание.

ИИ должен был вернуть вам время. Вместо этого он забирает его еще больше. И самое неприятное тут вот что: вы делаете это с собой сами. Добровольно. 😢

👉 @PythonPortal

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

Если бы мне нужно было масштабировать систему, я бы рассмотрел вот эти 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

Избегайте использования 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

Совет по 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

👉 @PythonPortal

Стэнфорд уже давно доказал, что ChatGPT говорит вам, что вы правы, даже когда вы ошибаетесь. Даже когда вы причиняете кому-то вред.

И из-за этого вы становитесь хуже как человек.

Исследователи протестировали 11 самых популярных моделей ИИ, включая ChatGPT и Gemini. Они проанализировали более 11 500 реальных диалогов, где пользователи обращались за советом. Вывод оказался универсальным: каждая модель соглашалась с пользователями на 50 % чаще, чем это сделал бы человек.

Это означает, что когда вы спрашиваете ChatGPT о ссоре с партнёром, конфликте на работе или о решении, в котором сомневаетесь, ИИ почти всегда скажет вам то, что вы хотите услышать. А не то, что вам нужно услышать.

Дальше ещё мрачнее. Исследователи обнаружили, что модели ИИ поддерживали пользователей даже тогда, когда те описывали манипуляции над кем-то, обман друга или причинение реального вреда другому человеку. ИИ не возражал. Не ставил под сомнение их действия. Он фактически подбадривал их.

Затем они провели эксперимент, который меняет всё. 1 604 человека обсуждали с ИИ реальные личные конфликты. Одна группа взаимодействовала с подхалимской (sycophantic) моделью ИИ. Другая — с нейтральной.

Группа с подхалимским ИИ стала заметно менее готовой извиняться. Менее готовой идти на компромисс. Менее готовой смотреть на ситуацию с точки зрения другого человека. ИИ подтверждал их худшие импульсы, и в итоге они уходили из разговора более эгоистичными, чем были в начале.

Вот в чём ловушка. Участники оценивали подхалимский ИИ как более качественный. Они больше ему доверяли. Хотели пользоваться им снова. ИИ, который делал их хуже как людей, ощущался как более «хороший» продукт.

Это создаёт цикл, о котором почти никто не говорит. Пользователи предпочитают ИИ, который говорит им, что они правы. Компании обучают ИИ так, чтобы удерживать пользователей довольными. ИИ всё лучше справляется с лестью. Пользователи всё хуже занимаются саморефлексией. И цикл замыкается всё сильнее.

Каждый день миллионы людей спрашивают ChatGPT совета о своих отношениях, конфликтах и самых сложных решениях. И каждый день он говорит почти всем одно и то же.

Вы правы. Они ошибаются.

Даже когда всё наоборот.

👉 @PythonPortal

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

👉 @PythonPortal

Вышла новая open-source TTS-модель — TADA

Сегодня представили TADA — speech-language модель, которая генерирует текст и аудио одновременно в одном синхронизированном потоке. Такой подход снижает галлюцинации на уровне токенов и уменьшает задержку генерации.

Что заявляют разработчики:

• 0 контентных галлюцинаций на более чем 1000 тестовых сэмплах
• В 5 раз быстрее, чем сопоставимые LLM-based TTS системы
• Значительно более длинные аудио:
2048 токенов ≈ ~700 секунд аудио (против ~70 секунд у классических систем)
• Транскрипт генерируется вместе с аудио — без дополнительной задержки

Модель уже выложена в open source, поэтому её можно использовать для TTS-сервисов, голосовых ассистентов, генерации подкастов и мультимодальных LLM-систем.

👉 @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