Несколько недель назад мы обсуждали Java-компонент, запускающий кластер Spark. Его основная задача — координация. Он поднимает всю необходимую инфраструктуру, прокидывает конфигурацию, дожидается нужных сигналов и отходит на второй план.
Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.
Думаю, мы все знаем, как это бывает. Если вы уже варитесь в этом бизнесе какое-то время, то сами так поступали. Пайплайн даёт сбой — увеличиваем память. Сервис начинает тормозить — добавляем процессорных ядер. Роллаут прошёл с натягом — и вот дежурный разработчик уже закладывает огромный буфер, потому что никто не хочет снова подрываться ночью по тревоге. Большие числа работают, система выглядит надёжной, и мы движемся дальше.
В итоге через полгода исходный контекст напрочь забывается, и такая конфигурация становится для сервиса объективным стандартом. Уже никто не рассматривает её как временный фикс. Теперь — это жёсткое требование. Временная заплатка затвердевает и превращается в непреложный факт, и никто не хочет ставить это под сомнение — ведь система работает.
Получается эдакий парадокс. JVM десятилетиями оптимизировалась, сборщики мусора стали намного эффективнее, процессоры — быстрее, а облачные ресурсы выделяются по щелчку мыши. В теории мы должны буквально купаться в плодах этих достижений. Но по факту мы продолжаем их растрачивать, подтверждая закон Никлауса Вирта, сформулированный им ещё в 1995:
«Программное обеспечение замедляется быстрее, чем ускоряется железо».
К чему нас привёл прогресс
Но плоды достижений никуда не исчезли. Просто мы растратили их на раздутые рантаймы, бесконечные графы зависимостей, тяжеловесные контейнеры, тонны телеметрии, расширенные запасы прочности и стандартные шаблоны платформ, из-за которых все сервисы выглядят одинаково. Когда появление очередной высокоуровневой абстракции повышает эффективность программирования, мы не начинаем писать меньше кода или создавать более простые системы. Мы тратим эту эффективность на повышение сложности, дополнительные интеграции и увеличение числа подвижных компонентов.
Когда инженер задирает лимит памяти контейнера «про запас», эргономика JVM воспринимает этот запас как предложение ни в чём себе не отказывать. Как результат, дефолтный размер кучи увеличивается до установленной доли от выделенных ресурсов. Сборщик мусора начинает лениться, так как теперь есть где разгуляться. А среда выполнения с комфортом обживает тот простор, который ей предоставили. Программное обеспечение начинает есть больше не от того, что теперь нужно больше работать. Оно просто расширяется, поглощая тот ресурс, который ему выделили.
Да, отчасти это утяжеление оправдано. Я не хочу угодить в ловушку технической ностальгии. Но нам нужно провести черту между неизбежной сложностью и излишними тратами. Современные программы выполняются во враждебной глобальной среде. Часть их веса вполне оправдана — это и безопасность, и доступность, и распределённые системы, и соответствие стандартам, и наблюдаемость, и глобальное масштабирование. Сегодняшние системы выполняют намного больше всевозможной работы, чем старые. Наша же ошибка в том, что мы используем этот аргумент для защиты любой неудачной базовой конфигурации, возникшей в процессе работы.
Если проанализировать явные излишки, то в глаза бросаются раздутые деревья зависимостей, в которых значительное число подключенных библиотек запускаются в рантайме редко или не запускаются вовсе. У каждого слоя современного программного стека есть свой аппетит. Логирование, трассировка, SDK платформы, и базовый образ контейнера — все хотят свою долю. Причём по отдельности ни один из них вроде и не требует чего-то запредельного, но все вместе они уже способны превратить небольшую утилиту в неповоротливого монстра. Раздутость ПО не возникает на ровном месте, она становится результатом длинной серии вполне разумных ситуативных решений.
Раньше машины умели сказать «Нет»
В прошлом ПО работало быстро не от того, что разработчики отличались высокой сознательностью. Просто машина могла сказать «Нет». В 2000-х годах было нормальным запускать веб-сервис на двухъядерной или даже одноядерной машине с несколькими гигабайтами памяти. Сервер был скромным, поэтому код приходилось затачивать под эти рамки. Нужно было расставлять приоритеты, подстраивать систему и точно понимать, что конкретно делает этот сервис. Ограничения заставляли людей действовать вдумчиво и экономично.
Современная же инфраструктура куда менее строга. Мы с лёгкостью добавляем буферы, повторные попытки и стандартные слои платформы — просто на всякий случай. С одной стороны, эта аппаратная снисходительность позволяет нам создавать более масштабные системы, а с другой, постепенно превращает временные перерасходы в постоянные и уже как будто нормальные. Использование инстанса более высокого уровня может нивелировать запутанную архитектуру. Увеличение кучи — скрыть утечку памяти. А применение стандартного шаблона платформы — скрыть тот факт, что крохотный координатор наследует аппетит более масштабного сервиса — потому что выделение 2 ГБ здесь кажется какой-то шуткой.
Но есть и обратная сторона медали. Сервис, использующий лишь жалкие 10% от выделенных ему 64 ГБ, на графике мониторинга отражается красивым, умиротворяющим зелёным цветом. Для команды эксплуатации этот сигнал означает, что с ним всё в порядке, хотя на деле он маскирует возможные проблемы оптимизации под триумф операционной безопасности. Мы разработали исчерпывающие механизмы тревоги на случаи перегрузки систем, но редко создаём такие механизмы для проверки структурной пустоты.
Образно говоря, дистанция между разработчиком и машиной радикально сократилась. Раньше для увеличения производительности нужно было заказывать железо, устанавливать дополнительные модули RAM, ждать поставки сервера или выбивать бюджет у руководства. В таких условиях нужно было думать дважды. Возникали лишние заминки, которые шли на пользу, заставляя тебя поумерить аппетит и действовать более эффективно. Сегодня же все эти вопросы решаются простым изменением конфигурации.
Мы стали расточительными не потому, что современным разработчикам всё до лампочки. Просто сегодня возникновение лишних трат редко сопровождается острой необходимостью их аргументировать.
Теперь отдувается железо
Заткнуть проблему железом бывает несложно, и зачастую это действительно является экономически оправданным решением. Человеческий труд намного дороже машинного. Если трата нескольких долларов на вычисления способна сэкономить дорогостоящее время разработчика, то ручная оптимизация кода станет неудачным вложением средств.
Но проблема в том, что аппаратное масштабирование становится как будто единственным решением. Когда так происходит, любое узкое место в системе превращается исключительно в проблему выделения ресурсов. Если мы видим, что нода перегружается, то для стабилизации системы переходим на более крупную. Но здесь кроется подвох, потому что стабильность может иметь под собой два совершенно разных фундамента. Иногда стабильная система имеет действительно стройную форму. В других же случаях мы просто заливаем проблему деньгами, чтобы она не вскрылась ночным сбоем.
И второй вид можно легко по ошибке принять за успех, так как прод работает исправно. В итоге возникает чувство «победы», и мы забываем, какой ценой эта победа нам досталась.
Избыточность живёт за чужой счёт
Перерасход ресурсов сохраняется, потому что сопутствующие издержки всегда перекладываются на чужие плечи. Тот, кто вносит зависимость, ускоряет разработку сегодня, а вся сопутствующая боль по обслуживанию переходит будущему мейнтейнеру. Команда платформы добавляет какой-то стандартный сайдкар лишь раз, но все сервисы в итоге расплачиваются за это задержкой бесконечно. Продуктовая команда прикручивает трекер для монетизации внимания пользователей, за что сами пользователи расплачиваются зарядом батареи и когнитивной нагрузкой.
В итоге раздувание продолжается, даже если его никто не одобряет, потому что циклы обратной связи нарушены. Когда сервис падает, фиксируется инцидент, проводится разбор полётов и возникает ощущение неотложности. Если же сильно тупит корпоративный инструмент, то это не порождает ничего, кроме ежедневной волокиты. Любой, кто пользовался кривым корпоративным софтом, знает, что эта медлительность никогда не переходит в разряд инцидентов. Она просто превращается в фоновые издержки при выполнении работы.
Решение: бюджетирование ресурсов
Ответом на эту проблему станет введение бюджетов на ресурсы — простых, занудных и жёстко фиксированных бюджетов. Тогда и лаунчеру будет выделен свой бюджет, и сервис получит стартовый бюджет, и контейнер получит бюджет на размер. Когда же выданный лимит будет превышен, кому-то придётся объяснить, что конкретно изменилось, и чем реально оправдывается этот лишний расход.
Это не означает, что придётся вручную оптимизировать потребление каждого байта. Иногда дополнительное аппаратное обеспечение обходится дешевле, чем координирование человеческого труда. Некоторые абстракции обеспечивают достаточно безопасности, чтобы оправдать свои расходы. Наша цель — не бедность, а осознанность. Давайте делать эти компромиссы прозрачными, прежде чем раздутые догадки закрепятся в виде стандарта.
Если простому лаунчеру Spark действительно нужно тридцать гигабайт, хорошо. Но покажите мне «чеки». Что именно загружается при запуске? Что постоянно висит в памяти? Какая часть этой памяти действительно обеспечивает отказоустойчивость системы, а какая лишь оплачивает проценты на старые, давно забытые решения?
Если никто не сможет ответить на эти вопросы, то такое выделение памяти — это не инженерия, а суеверие. Поэтому в следующий раз, когда какой-то отдельный компонент потребует огромных ресурсов, не нужно оправдывать его, оглядываясь на аппетиты соседних сервисов. Оцените структуру выполняемой им работы. Задайтесь вопросом, что конкретно делает тот или иной механизм, и что нам нужно изменить, чтобы перестать панически бояться скромных цифр.
Комментарии (55)
oldzoomer_ru
28.06.2026 09:29В 2000-х годах было нормальным запускать веб-сервис на двухъядерной или даже одноядерной машине с несколькими гигабайтами памяти.
Скажу со своей колокольни - ваадиновой.
Так вот, Vaadin всегда был про server-side states. Поэтому она и прославилась тем, что требует сервер с большим объёмом ОЗУ.
Поэтому пока на тимлифе делали относительно нежручие UI, ваадинщики юзали server-side states (которые хранятся в ОЗУ сервера) по полной.
GidraVydra
28.06.2026 09:29Раньше ПО работало шустро
Как же быстро в человеческом мозгу объективная картина подменяется на воспоминания о зелёной траве и самом вкусном пломбире...
oldzoomer_ru
28.06.2026 09:29Вспоминаем тот же IE. Или iTunes.
Aggle
28.06.2026 09:29Ещё можно вспомнить:
"А кто будет жрать память, того будем бить по наглой рыжей морде". (ц)
vorphalack
28.06.2026 09:29в вычислительном плане оно может и с той же относительной скоростью работало, а вот отзывчивость UI точно была выше, потому что никто тебе контекстные меню на react native не делал с десятью анимациями для олигофренов и еще 5 для даунов.
AcckiyGerman
28.06.2026 09:29Отлично помню, как отключал все эти анимации в win 98 и win XP чтобы не лагали.
vorphalack
28.06.2026 09:29я их местами тоже отключал, да,но - там у меня был выбор (а если чуть накинуть железа - то и даже пофиг было),потому что условно у всех был win32/mfc и поверх скины к нему, а щас там минимум WPF или "тулкит дня + JS/HTML" или даже целый электрон, всё с визуальными эффектами, тупит, и вдобавок еще глючит на недефолтных dpi, как бы они не проповедовали обратное.
vlivyur
28.06.2026 09:29И тогда, наконец-то, система работала адекватно. Т.е. её можно было штатными средствами заставить работать. А больше такой возможности нет. Сейчас у меня под Win11 task manager умудряется иногда под 20% CPU сжирать
Wesha
28.06.2026 09:29все эти анимации в win 98 и win XP
Тогда‑то и появился оборот «свистелки и перделки».
(Дедушка старый. Дедушка помнит.)
Darkness_Paladin
28.06.2026 09:29Ну это у вас наверное железо было совсем плохое. В ХРюшке я отключал только "новый стиль окон" и исключительно ради экономии места на экране, анимации отключал только в 98й на 486м.
GidraVydra
28.06.2026 09:29Мне, как пользователю нескольких ретрокомпьютеров, очень интересно бывает читать подобные прохладные истории...
Fenzales
28.06.2026 09:29в вычислительном плане оно может и с той же относительной скоростью работало, а вот отзывчивость UI точно была выше
Особенно когда было непонятно: приложение зависло или просто что-то считает :)
vorphalack
28.06.2026 09:29как будто что-то с тех пор изменилось... правда теперь из-за этих новомодных тулкитов сверху третья напасть добавилась - "пропустило хоткей"
AlekseyPraskovin
28.06.2026 09:29А сейчас-то понятно, ага. Особенно ваши любимые бесконечные спиннеры вместо нормального прогресс бара. И ошибки с описанием типа "Извините, что-то пошло не так. Идите нахуй" на фронте.
pavel_str
28.06.2026 09:29Не совсем верно. Возьмите старый ноутбук с ХР и пол гига памяти, поставьте на него Word 2007. И сравните время открытия одного и того же документа на этом ноутбуке и современном компьютере... Мне как то принесли старый ноут и разница была очень заметная и не в пользу моего рабочего на Win10 значительно более современного компьютера.
Hlad
28.06.2026 09:29Ну, тут есть нюанс. Раньше считалось, что пользователь понимает, что делает, соответственно, сказали запустить - значит запустить. А сейчас считается, что пользователь идиот, который не ест говно только потому, что ему цвет не нравится. Поэтому когда вы жмёте "запустить" - происходит куча телодвижений, чтобы убедиться, что это приложение безопасно. Вплоть до запроса через интернет на сервера Микрософта. Попробуйте на роутере зажать канал до 32 килобит в секунду, и запустить что-нибудь.
speshuric
28.06.2026 09:29А тут несколько разнонаправленных трендов.
С одной стороны, многие библиотеки бесконечно улучшают: тут SIMD воткнут, там алгоритм от квадратичного в граничных случаях избавится, где-то от расчётов ненужных избавятся, где-то от false sharing. Если посмотреть на производительность конкретной фичи с точки зрения кода, то обычно она становится лучше (это если она на стеке-долгожителе, а не была переписана с C++ на python, конечно).
С другой стороны, как правильно указано в статье - навешиваются какие-то безумные с точки зрения конечной функции расходы. То предсказание переходов безопасности мешает, то в контейнер (а то и виртуалку) надо запихнуть, перейдя с внутрипроцессного вызова на TCP+TLS RPC. Ну и по мелочи - указатели стали в 2 раза толще, int64 стал чаще типом по умолчанию и т.п. Причём на самом деле 80% этого можно найти и устранить но обычно "оно не стоит того". И это "не стоит того" для одного конкретного фактора приводит к непрерывному росту ПО. Везде. Не все его замечают, потому что он медленный, но это как расширение вселенной - становится главным фактором на больших масштабах. Причем это почти везде. Я помню нытьё, что dotnet увеличивал размер дистрибутива на 30 МБ. Я вижу, что iso-образ archlinux (который вообще-то неизменно умеет минимум: только загрузиться, немного починить что сломалось и загрузить пакеты из интернета) растёт раза в 2 за каждые 5-7 лет. Блин, archlinux - самый минималистичный iso из всех - стал 1,5 ГБ!
Еще отдельный фактор - изменение железа, например, уход с тех пор с HDD. Если я запущу условную WinNT4 в виртуалке, то я ж расплачусь от того как она быстро будет работать. Ну да. Только тогда у меня памяти было 64МБ, а сейчас 128ГБ, тогда latency диска была 10 мс, а сейчас 20 мкс, тогда диск мог отдать 50 МБ/с, а сейчас 3 ГБ/с. Пожалуй, только latency DRAM плюс-минус там же осталась (сначала упав, а теперь уже лет 20 растёт). Так вот: сейчас ВМ с WinXP/NT4/2000/2003 работает неприлично быстро и экономично по сравнению с нынешними ОС и с самой собой 25-летней давности. Причём основные улучшения в отзывчивости от скорости SSD.
Отдельно замечу, что много нетехнических свойств у систем, которые влияют на их использование. Ну вот тот же GDPR - теперь на каждом милипусеньком сайте торчат всплывашки на первом выхове.
И там еще много подобных факторов. И в итоге у нас одновременно есть и эффект "раньше было лучше", и "стало в 100 раз быстрее".
PS: в 2000 году на NT4 я мог запустить на 1 ядре и 64 МБ памяти SQL Server, его Enterprise Manager, Query Analyzer и еще и HoMM3 (но, если честно, то обычно перед запуском HoMM я всё остальное гасил). А сейчас у меня пустой блокнот ест сопоставимо (notepad.exe - 30 МБ, kwrite - 100 МБ). И с другой стороны, я могу (теперь скорее сын может) играть с разрешением 100 fps на экране 3840x1920 с честной 3d-графикой, трассировкой лучей и правдоподобной физикой, а у меня тогда еле хватало на HL в 640x480 (в 24 раза меньше пикселей).
DerTosser
28.06.2026 09:29Блин, archlinux - самый минималистичный iso из всех - стал 1,5 ГБ!
Самый минималистичный из ныне живущих это TinyCoreLinux, который в максимальной своей комплектации CorePlus занимает 248 MB (GUI и дрова для всякого). Ваш Арч, увы, слишком прожорлив для категории минималистичных. Он скорее самый маленький из дистрибутивов общего назначения. Хотя если взять тот же Debian 13 net-install и накатить на него сверху GUI, он тоже будет не слишком большим, да и PCLOS-mini с TDE всего лишь 2,3 ГБ, но там ещё приложений по минимуму воткнуто. Увы, арч не маленький.
P.S. у меня notepad++.exe с 7-ю открытыми вкладками занимает 8 804 КБ, а там и подсветка синтаксиса и автодополнение и плагины... зачем пользовать обычный notepad, когда есть такая прелесть?
speshuric
28.06.2026 09:29Про arch, что он не самый маленький - принимается. Я скорее имел в виду, что его установочный образ заметно меньше обычных GUI live инсталляторов. В любом случае, я его упомянул, потому что мне проще было посмотреть историю размеров, при том что функционально изменения за это время минимальны. У той же ubuntu тенденция похожая. И у debian, и у остальных (общего назначения) то же самое.
Причём я когда-то смотрел, почему там такой рост. Что меня тогда зацепило, что в образе-инсталляторе arch лежали библиотеки рантайма go для компиляции через gcc (это около 50 МБ одна soшка, если мне память не изменяет). При том, что рантайм go в этом образе вообще был не нужен. Мне стало лень писать мейнейнеру предложение о разделении (чтобы этот рантайм тянулся по зависимостям) - я в тот момент просто собирал образ для экспериментов.
PS: notepad посмотрел просто для примера, зайдя по RDP. Да, notepad++ меньше, конечно, при невообразимо более широких возможностях. А notepad, как и kwrite, я использую для одноразовых заметок.
Tuesok
28.06.2026 09:29Смотря какое ПО и на каком железе. Понятно, что в 3D Studio на 486sx я запускал рендеринг сложной сцены и шел не то, что чай попить - а спать до утра. Сейчас этим уже давно не занимаюсь, но подозреваю, что на современном железе задачи того же уровня решаются быстрее.
А вот условный MS Word 6.0 на этой же железке бегал куда быстрее, чем Office 2024 на современном ПК сопоставимого уровня.
Секунда ностальгии, зеленой травы и старых интерфейсов
Причем по используемому функционалу Word 6.0 закроет потребности большинства пользователей (софт 30+ летней давности).
Dreams_and_magic
28.06.2026 09:29Раньше ПО работало шустро в одном случае: когда старое ПО ставили на новое железо.
JBFW
28.06.2026 09:29Да, но сейчас-то железо новое?
Прям очень-очень новое, не какой-нибудь Пентиум-133 с 4 МЕГАбайтами памяти - но тогда он худо-бедно крутил новостной сайт на 100500 страниц. Как бы шустро работало это на современном многоядерном сервере с 64 гигами ...Dreams_and_magic
28.06.2026 09:29Многоядерный сервер в сравнении на 1 поток запросто может быть гораздо слабее многоядерного процессора для ПК:)
randomsimplenumber
28.06.2026 09:29новостной сайт на 100500 страниц
1 страница чистого html по факту.
Gradiens
28.06.2026 09:29Я из тех, кому 640кб под MSDOS казались роскошью.
И сейчас я побуду адвокатом дьявола.
Вы правы, часто проблему заливают даже не физическтм железом, а деньгами. А что в этом плохого? Ну то есть если этот путь эффективный, может так и надо?
Это же не ваши бабки.
Почему бы не дать приложению в 5 раз больше памяти, и не париться об инцидентах с эпизодическим out of memory, когда кто-то, скажем, сгенерит гигантский отчет?
Почему бы не дать эту память, чтобы сборщик мусора мог оптимально работать, а не устраивать постоянные перетряхивание рабочего набора, от которых у клиентов все лагает?
Если вы не пишете реальный high load, то может, ну его нафиг, преждевременную оптимизацию?
Dreams_and_magic
28.06.2026 09:29А потом какие-то умники из какого-то Гугла придумали какие-то нейросети, и теперь ваша память стоит в 3 раза дороже:)
sim31r
28.06.2026 09:29Так и есть. Допустим проект без оптимизации, протестировали, работает и далее оптимизировать его на 99% не будут. Если жалоб у пользователей нет, то задачу такую ни кто отдельно не поставит.
vorphalack
28.06.2026 09:29это хорошо работает для серверсайда, но есть и клиентская сторона. что такого за 10 лет поменялось в андроиде, что у нас теперь 8 ядер и 12+ гигабайт оперативки в телефонах нужны просто чтоб переключение между аппками не тормозило? может всё же иногда стоит останавливаться и давать не в 5 раз больше приложению, а леща продуктовой команде?
alliumnsk
28.06.2026 09:29Продуктовой? Я плохо разбираюсь в андроиде, но кмк там затруднено написание маложрущих приложений, да и зачем заморачиваться, если сама система много жрет?
d3d14
28.06.2026 09:29Да хотя бы отзывчивый интерфейс приложений пусть делают. А не это вот рисование меню через <div> на javascript во встроенном браузере. Или в 11 винде - виндовые (!) меню - через какой то чертов XML island, открываются заметно дольше настоящих. Чем настоящие (CreateMenu/TrackPopupMenu) то их не устроили? Вот что в них было плохого - они все поддерживали.
LeVoN_CCCP
28.06.2026 09:29когда кто-то, скажем, сгенерит гигантский отчет?
Потому что:
этот отчёт генерируется не моментально
“о, теперь можно и такие отчёты делать, а давайте ещё десяток”
хмм, код этого отчёта можно размножить и получить ещё кучу отчётов, тем более ИИшенка генерит абсолютно такой же код.
Много лет назад, когда мощности не поспевали за творческими изысками кодеров (а точнее стоимость покупки с какого-то момента начинала увеличиваться по экспоненте), внезапно появилась необходимость оптимизаторов. Сейчас ситуацию заливают облачками и подписками. Проблема в том, что стоимость будет увеличиваться линейно, как с той самой лягушкой.
Wesha
28.06.2026 09:29— Сколько памяти занимает Windows?
— Сколько находит — столько и занимает!© 1995.
Guestishe
28.06.2026 09:29Все это похоже на эволюцию, экстенсивно развивающиеся организмы оттачивающие метаболизм и другие системы черезвычайно эффективны. Но те кто развиваются экспансивно на заплатках опережают и занимают новые ниши.
maxys146
28.06.2026 09:29Сервис, использующий лишь жалкие 10% от выделенных ему 64 ГБ, на графике мониторинга отражается красивым, умиротворяющим зелёным цветом.
С одной стороны согласен, но с другой... Канализационные трубы делают большого диаметра не потому что люди, простите, постоянно генерируют большой поток "данных", а для того чтобы при пиковых нагрузках систему не переполнило)
akakoychenko
Статья устарела, увы. Описанные там проблемы ничто в сравнении с тем, какие монстры вырастают от возможностей LLM.
Вайтлистить IP для доступа через API надо 3 дня, а фича по поиску юзера по фамилии нужна на вчера? Эй, клодкод, навайбкодь мне скрипт под селениум, который зайдет под сервисной учеткой, пропагинирует 600 страниц в 64 параллельных воркера, поднятых в отдельных докер контейнерах, и выведет ид юзеров, где совпало.
Так... надо выпарсить имейл из текста? Вроде, деды это регуляркой делали. Но, там же ошибка закрастся может... Ну его, просто впишу туда вызов LLM, - пусть ии каждый раз имейл извлекает. Ой, тестировщик говорит, что 1 из 10 раз имейл извлекает с опечаткой? Ничего, буду вызывать LLM в цикле, пока 3 последних извлеченных имейла не совпадут
oldzoomer_ru
Так и есть. Я, например, не доверяю ИИ детермированные операции (вроде парсинга чего-либо).
Просто потому что это, по сути, умный ГСЧ.
iamkisly
скорее китайская комната
Wesha
Darkness_Paladin
Иногда лучше не знать чего-то совсем, чем иметь о предмете искажённое представление. Вот у вас именно такой случай.
Дело в том, что принцип, по которому ЛЛМ строит ответы, с точки зрения кибернетики не очень сильно отличается от принципа, по которому это делает мозг человека.
Да, мы тоже "всегда выдумываем". Вся разница -- у нас, кроме "выдумывалки", есть ещё подсистема критической оценки, которая оценивает достоверность известных нам фактов и сделанных из них выводов, поэтому человек в сомнительной ситуации может сказать "я не знаю", а ЛЛМ отвечает "я не знаю" только в заранее предусмотренных ситуациях. Например, если вы попросите её решить задачу на скорость-путь-время или на закон Ома, дав только один параметр из трёх -- это предусмотрено, она скажет "я не могу посчитать без второго параметра", это для неё типовой ответ на типовой вопрос. А вот если вы влезете туда, где у неё недостаточно знаний -- тут она часто не может отличить глюки от малозначимых фактов.
Это доделают, но потом.
aamonster
Т.е. сказать "ИИ, напиши мне регэксп" могут не только лишь все?
xSVPx
Не только лишь все потом проверить могут результат. В какой-то момент я попросил регэкспы больше не писать вообще. Да - это компактно и производительно, но когда у тебя для валидации этого регэкспа надо день пить валидол и раскусывать его на части, когда диаграмма не влезает по итогу на вайтборд. Ну его нафиг ..
aamonster
Ну ок, не регэксп, а код для разбора (тоже такое предпочитаю, когда регэксп слишком сложный или просто есть время аккуратно расписать парсинг). Суть в том, что иишенка должна работать, как человек – не разгребать всё руками, а писать дешёвую автоматизацию.
xSVPx
Так она так и пытается. Курсор к примеру. Но этож надо отказываться от неудачных решений, а не "х...к. х....к и в продакшн"
Darkness_Paladin
Это ещё 20+ лет назад в учебнике по регэкспам было написано -- "имейте в виду, что сложный регэксп проще написать заново, чем разобрать для проверки или изменения".
Поэтому регэкспы у нейронки надо просить с пошаговым описанием построения, чтоб можно было проверить их корректность.
xSVPx
Чтобы проверить их корректность вы должны их самостоятельно разобрать на части и завалидировать каждую часть и всё вместе.
Просто "пробежать глазами объяснения нейронки" - это немного другое.
Если вы без нейронки затрудняетесь понять "чё это ваще тут такое", то лучше их не использовать.
Я вот, часто затрудняюсь и не использую в этих случаях. Можно, конечно себя натренировать, но лучше не надо, после меня попадется кому-то ненатренированному...
Darkness_Paladin
Не разобрать, а отследить. Когда у вас есть пошаговое описание, из которого очевидно, как итоговая абракадабра собралась из простых и понятных кусочков, это можно сделать довольно легко. Когда у вас есть только несколько строк абракадабры, разобрать её на простые и понятные фрагменты КРАЙНЕ сложно.