Ночной пост, для тех кто потерялся в череде новых обновлений ИИ инструментов.

Ответ на вопрос кто такие Cursor, VS Code, Claude Code, AntiGravity и как они работают в интерактивном формате.

К слову, это новый формат ответа от Gemini Pro.
Теперь так, по одному запросу, можно получить сгенерированный лично под вас интерфейс - хоть инструкцию к использованию чего-то, хоть дашборд вашей эксельки.

https://gemini.google.com/share/5eb1ef25134b

#llm #petproject

Ребята, всем привет!

Мы с командой решили вернуться к истокам и разобрать базовые настройки ChatGPT.

Почему это важно, даже если вы профи?

Потому что ИИ — это не про штамповку одинаковых ответов, а про поток, некую сонастройку.
Чтобы нейросеть стала продолжением ваших мыслей, её нужно правильно забрифовать на уровне настроек.

Разобрали со Светой неочевидные фишки, которые мы сами используем каждый день, чтобы улучшить качество отклика.

Заходите посмотреть👇

#llm #petproject

Куда на самом деле движется индустрия LLM (спойлер: вы выбираете не модель - вы выбираете стек).

Пост навеян свежим релизом Opus 4.5, а именно ее доп фичами как Context Editing - нам показывают действительно впечатляющие демки… Но постойте - это же (очередная) не-фича foundation модели. Это не что-то в весах. Это инфраструктурный middleware, который живет между вами и моделью. И если вы проанализируете (особенно глазами разработчика) релизы последнего года, то вы увидите что мы все дальше от бога от LLM как модели, и тем ближе к LLM как infrastructure-as-a-service. Давайте поговорим, куда нас ведет индустрия и что из этого следует, но начнем с начала.

Большинство людей (в том числе многие разработчики) когда говорят про условный ChatGPT не видят весь спектр между "моделью" и "продуктом" - ведь это одновременно и foundation model, и старый добрый completions API, и вполне себе агентный Responses API c Code Interpreter, File Search (RAG прямо в "модельке", ага) и т.д.

Что на самом деле продают вендоры

OpenAI Responses API - это целая инфра, включая NoSQL БД для истории, хранилище файлов и тд. Вы отдали им state management.

Code Interpreter и Code Execution - это PaaS: managed sandbox - $0.03 за сессию платите за инфру, не за "умную модель".

Claude Context Editing - middleware с настраиваемой стратегией pruning (keep last 3 tool uses, clear 5000+ tokens). Оркестрация, а не интеллект.

Google Grounding и Maps tool - dynamic retrieval: модель решает нужен ли поиск, генерит queries, получает доступ к индексу (глубже публичного API), делает reranking, отдает с citations. Вы покупаете gateway к индексу, не модель.

Даже Structured Outputs - это частично заслуга инфры, а не весов - constrained decoding через CFG (конвертит JSON Schema в грамматику, маскирует невалидные токены). Компилятор поверх модели.

Большинство не осознают, как растет пропасть между проприетарными infrastructure-as-a-service от OpenAI/Google/Anthropic и голыми весами open-source моделей. Проприетарные LLM превращаются из inference провайдеров в операционки для intelligence.

Что из этого следует и что следует иметь в виду

1. Понимать уровни зависимости, я выделяю три:
- State (Threads, File API, memory) - критический lock-in, вы не владеете памятью системы
- Execution (Code Interpreter, sandboxes) - средний lock-in, нужна своя инфра для рантайма
- Behavior (Grounding, Computer Use) - средне-высокий, модель часто обучена под "свои" инструменты

Перед использованием любой фичи спрашивайте: "Где живут данные? Кто контролирует логику? Смогу ли я воспроизвести это сам?"

2. Integration Tax vs Migration Tax - ключевая асимметрия. Проприетарные фичи дают быстрый старт, но стоимость выхода растет экспоненциально. Это не обязательно плохо - это trade-off, который нужно делать осознанно.

3. Разделять Core и периферию
Core (ваша уникальная ценность, основа продукта) - инвестируйте в независимость: свой state management, своя оркестрация и тд.
Пример: AI-агент для support как продукт - владение историей диалогов критично, а вот Code Interpreter для внутренней аналитики - это ок.

4. Есть обратная сторона. Чем глубже расходятся продуктовые слои провайдеров, тем сложнее делать model-agnostic продукты, которые работают так же хорошо. Manus поняли это рано - выжали максимум из Anthropic, не пытаясь быть совместимыми со всеми, и сделали продукт-звезду. Возможно, по той же причине Claude Code так хорош?

5. Учитывайте свою стадию. 0→1 (поиск PMF) - максимально используйте проприетарные фичи, скорость важнее. Когда растете - можно строить абстракции: gateway, свой state для core функций. На стадии масштабирования - еще больше контроля и взаимозаменяемости компонентов (interoperability это дорого).

Главное

Проприетарные AI-платформы - это managed infrastructure, как AWS. Вы платите не только деньгами, но и зависимостью. И этот тренд будет расти. Часто это правильный trade-off, особенно на старте. Но это решение нужно принимать с открытыми глазами - понимать, какую часть системы отдаете "в управление", и делать это осознанно для каждого компонента продукта.

#ml #interview

Асессорская разметка: как оценивать согласованность?

Обычно разметка проходит строго по этапам: сбор данных → создание гайда → запуск разметки обычно с перекрытием → агрегация меток → обучение модели → оценка качества.

Допустим, мы хотим получить разметку данных для классификатора сентимента обращений в поддержку. Мы получили метки от трех асессоров для некоторого количества реальных диалогов. Как же понять, насколько качественный результат разметки?

В такой ситуации можно посчитать коэффициент согласованности — agreement. Он показывает долю совпадающих меток между асессорами.

В нашем случае средний попарный agreement — 83,9%, что достаточно неплохо. Но есть подвох: этот коэффициент, так же как и accuracy в случае бинарной классификации, может вводить в заблуждение при дисбалансе классов. В нашем датасете больше 70% меток приходятся на два класса — «Нейтральный» и «Замешательство». Давайте воспользуемся другими статистическими коэффициентами, чтобы удостовериться в высокой согласованности:

📌 Cohen‘s Kappa (Каппа Коэна) — попарный коэффициент. Оценивает нормализованное согласие между двумя асессорами.

Как интерпретировать результаты:

<0,6 — плохая согласованность.
0,6…0,8 — хорошая согласованность, можно использовать в прикладных задачах.
>0,8 — очень высокая согласованность.

📌 Fleiss’s Kappa (Каппа Фляйна) — подходит для оценки согласованности между несколькими (более двух) асессорами.

В нашем случае Каппа Коэна варьируется от 0,7 до 0,84, что указывает на высокую согласованность. Для дополнительной проверки мы взяли несколько сотен случайных примеров из датасета и вручную расставили метки. Оказалось, что в 44% наши и асессорские метки расходились — то есть, асессоры в среднем согласованно ставят неправильные метки. Вот поэтому даже высокие показатели согласованности не гарантируют качественной разметки данных.

Что делать в такой ситуации — расскажем в следующем посте.

Что делать, если асессорская разметка не совпала с экспертной?

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

📝 Проверить формулировку задачи и прописать подробный гайд с корнер-кейсами. Можно взять выборку, разметить её по гайду и посмотреть, где возникают споры — эти места нужно уточнить.

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

📝 Разбить работу на чанки и добавить в каждый golden set для валидации. Это позволит оценивать качество разметки итеративно и следить, насколько асессоры попадают в золотой набор.

После внедрения этих шагов в нашей модели эмоций взвешенный F1 вырос с 0,61 до 0,7, а расхождение экспертной и асессорской разметки упало с 44% до 18%. Также хорошо подтянулись небольшие проблемные классы:

Благодарность — 0,8 → 0,76
Нейтральный — 0,7 → 0,75
Удовлетворительно — 0,68 → 0,74
Нетерпение — 0,57 → 0,53
Разочарование — 0,57 → 0,55
Замешательство — 0,46 → 0,7

Важно: низкая согласованность не всегда означает плохую работу асессоров. Причинами могут быть:

📎 Неоднозначность задачи: она может подразумевать некоторую неопределенность. Например, такое часто встречается при подготовке диалоговых данных для LLM.

📎 Разный бэкграунд асессоров: внутренние AI-тренеры и внешние подрядчики могут понимать задачу по-разному. Это приводит к значительным различиям в оценках.

Поэтому ML-инженерам и датасаентистам важно самим вчитываться в данные и понимать, как они размечены.

Что делать с ошибочными разметками — расскажем в следующем посте.

#ml #courses

Переход c Selenium на Playwright

У меня имеется мой парсер для особых сервисов, который имеет в себе классический зоопарк с selenium (xvfb, конкретная версия ChromeDriver), а также постоянные проблемы с таймаутами и нестабильностью. В общем, всё как обычно.... а Xvfb было решением, которое... позволяет компилировать wasm скрипты

Я очень давно хотел его выкинуть. и наконец-то я близко у цели. Один playwright install chromium — и всё работает. Нативный async/await вместо костылей с WebDriverWait. Dockerfile сократился. Были улучшены воркеры, взамен самописных скриптов

Playwright действительно быстрее. Не на 10%, а ощутимо. Особенно заметно на больших объемах данных. Код стал чище — вместо
WebDriverWait(driver, 20).until(expected_conditions.presence_of_element_located((By.ID, "element")))
теперь просто await page.wait_for_selector("#element")

Не нужно гадать, почему браузер упал — Playwright просто говорит, что не так. Docker образ стал легче — я убрал xvfb, кучу системных пакетов и прочую ерунду. Теперь базовый образ python slim + Playwright.

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

Да, можно было написать код на Selenium лучше, делать больше оберток и покупать лучше сервера, но он мне очень сильно надоел...

Ребят, в комментариях к предыдущему посту про частичные индексы написали, что проблема с NULL значениями в индексах уникальности решена с PostgreSQL 15.
Моя история ещё из 2021 года 👨‍🦳

Сейчас можно добавить такую формулировку при создании индекса в конце:

NULLS NOT DISTINCT

И null values для целей индекса будут считаться одинаковыми, не нужно будет создавать два индекса.