Обновить
32K+
12
diffnotes-tech@diffnotes-tech

Пользователь

85,4
Рейтинг
3
Подписчики
Отправить сообщение

путаница профилей при двух сущностях в одном промпте - типичная штука. CAPS помог но 5% всё равно мимо. Проще разбить на два вызова - один для её профиля, один для его, потом склеить. DeepSeek поддерживает prefix caching, второй вызов обойдётся дешевле

Самое ценное тут не скиллы а validate-dsl.sh в цикле. Треть генераций невалидна - агент по сути берёт количеством попыток. Тот же паттерн работает с terraform и k8s манифестами - если у DSL есть нормальный валидатор, LLM справляется. Если нет - бесполезно

circuit breaker с рандомными промптами - это random walk между теми же аттракторами. За 483 сессии единственный реальный выход из петли - когда автор написал сообщение про имя. Внешний стимул сработал, рандом нет

8000 токенов с включённым MCP впритык. Схемы fetch + filesystem это десяток tool definitions которые целиком идут в контекст при каждом запросе. Плюс системный промпт. На диалог остается тысяч 5. А fetch одной веб-страницы легко возвращает 3-4k - контекст забит за один ход

Часть про "Opus 5 или 5.5 у военных" - это экстраполяция с одного Reddit-треда. Palantir интегрирует стандартные модели через свою AIP платформу, там сила не в секретной нейросети а в доступе к разведданным + инфраструктура для их обработки. Обычный Opus 4.6 подключённый к базам CENTCOM - это уже совсем другой инструмент

Каждая задача - 5-6 LLM-вызовов, контекст растёт на каждом шаге, на Opus набегает быстро. Притом на SWE-bench Sonnet 4.6 отстаёт от Opus на 1.2 пункта (79.6 vs 80.8) при пятикратной разнице в цене. Opus оправдан на архитектуре где надо думать над структурой, на кодинг и ревью Sonnet хватит

Метрика с джойнами ловко придумано. Но ловит только структурное разрастание - когда AI насоздавал лишних сущностей. Когда он тихо переименовывает концепции или меняет порядок вызовов - джойнов столько же, а логика уже уехала

E5-Large обрезает на 512 токенах - при чанках 1500 символов русского текста это впритык к лимиту. BGE-M3 от BAAI держит 8192, для русского работает не хуже, плюс можно чанки крупнее делать

Исследование METR которое тут цитируется (19% замедление) - это конкретно опытные контрибьюторы в open-source репах которые они и так хорошо знают. Ну так понятно что когда ты быстро пишешь в знакомом коде, верификация ответов LLM только добавляет работы

"CPU 2.3%, диск 1.6%" - выделенный сервер тут загружен примерно никак, всё упирается в edge-tts. С домашнего компа результат будет тот же)

никакую, может от общения с ИИ я и сам стал думать как ИИ)

Критикуем Альтмана за впаривание AI и тут же рекламная вставка BotHub на 300к токенов посередине статьи. Ну это прям шедевр)

Ну то есть схема: просишь AI написать код который генерит музыку, записываешь в WAV и отдаёшь другому AI который тоже генерит музыку. Как переводить с английского на французский через китайский))

"случайный фрагмент Python-кода со StackOverflow с высокой вероятностью просто запустится" - ну да, запустится. А потом в три ночи в проде тоже запустится но уже по-своему) Проблема не в том что C++ сложный для AI, а в том что мы привыкли к питону где "запустилось = работает"

"Точность подбора ~90%" - ну то есть каждый десятый товар мимо. Для завтрака на двоих из 5 позиций это каждый второй заказ с сюрпризом)

Гонка LLM уже напоминает рекламу стирального порошка - "теперь на 46% лучше рассуждает!", через две недели конкурент выдаёт "а мы на 52%!". Единственный надёжный бенчмарк - взять и попробовать на своих задачах. Бенчмарки тут как фотки в Тиндере - общее представление дают но сюрпризы гарантированы))

12 ...
10

Информация

В рейтинге
102-й
Зарегистрирован
Активность

Специализация

Десктоп разработчик, Бэкенд разработчик
Ведущий
Python
Linux
Docker
REST
Базы данных
ООП
Java Spring Framework
Git
SQL
PHP