Дело за малым - попытаться объяснить это минусаторам типа "текст похож на сгенерированный".
IMHO это бесполезно .
Впрочем , причины минусов давно уже потеряли всякий смысл и обоснованность , да и вряди были когда то , я например давно перестал переживать , что у кого то обостряются чувства из за использования кавычек, длинных тире и что там еще они используют как маркеры :-)
Я использую нейросеть для анализа результатов, генерации гипотез и подготовки макетов публикаций , потому, что это сильно экономит мое личное время, которое я трачу на новые эксперименты и исследования , и признаюсь - переживания борцунов с ИИ меня не волнуют от слова вообще.
Только есть одна серьезная проблема, которую надо учитывать и не ждать чудес.
EXPLAIN ANALYZE это единичное выполнение единичного запроса.
И иногда бывает, что снижение стоимости запроса в результате анализа плана выполнения приводит к деградации производительности СУБД под высокой параллельной нагрузкой.
1. Юридический и экономический вакуум ответственности
Короткий и честный ответ: сегодня — никто не отвечает, и это одна из главных проблем и одновременно тормозов для внедрения ИИ в критических сферах.
Формально ответственность пытаются переложить на человека, который использует систему. Врач, поставивший диагноз с помощью ИИ, несёт ответственность за окончательное решение. Оператор беспилотного автомобиля (если он есть) — за действия машины. Но это юридическая фикция, потому что:
Человек не может эффективно контролировать «чёрный ящик». Если модель выдаёт рекомендацию, у врача нет инструментов, чтобы проверить её обоснованность в реальном времени. Он либо доверяет, либо нет. Если он доверяет ошибочной рекомендации — виноват он. Если не доверяет правильной — он теряет пользу от системы. Это ставит человека в ложную позицию.
Производитель модели снимает с себя ответственность. В лицензионных соглашениях чётко прописано: «модель предоставляется "как есть", мы не гарантируем безошибочность и не несём ответственности за последствия её использования». Юридически производитель отвечает только за явные дефекты кода (если ошибка в софте, а не в модели), но не за ошибки самой модели, потому что они — не баг, а feature статистического обучения.
2. Почему это принципиальная проблема?
В традиционной инженерии действует принцип: за любое решение отвечает человек или организация. Если мост рухнул — отвечает инженер и строительная компания. Если лекарство убило — отвечает производитель и врач.
В случае с ИИ мы имеем дело с системой, которая:
не программируется явно, а обучается на данных;
не детерминирована (может давать разные ответы на один и тот же запрос);
не объясняет свои решения (проблема интерпретируемости).
Как привлечь к ответственности алгоритм? Его нельзя посадить в тюрьму, оштрафовать или лишить лицензии. А если привлекать разработчиков, то за что? За то, что модель ошиблась на примере, которого не было в обучающей выборке? Но это неизбежно для любой статистической системы.
Главная проблема промышленного ИИ — отсутствие данных для обучения.
В области использования ИИ для оптимизации производительности СУБД - точно такая же проблема . В сети практически , нет данных о экспериментах. Поэтому в области performance engineering - пользы от нейросетей пока не очень, только для анализа данных, советы просто гадание и угадывание. Иногда попадают. Чаще - нет. Но процесс конечно интересный .
Вывод: на синтетических данных без каузальной структуры модель обучается распознавать рецепт генератора, а не физику процесса. На реальном заводе такая модель будет бесполезна.
C СУБД - тоже самое. Дословно.
Инженерам проще работать по старинке, доверяя своему опыту и манометру, чем чёрному ящику, который обучен программистами, ни разу не инженерами. Побеждают в этой борьбе обычно инженеры, а дорогой пилотный проект ложится на полку.
Я как раз сейчас присутствую при восторженном эксперименте -"а давайте сделаем на продуктиве как тут вот в интернете написано и ИИ подсказал". Может быть будет по итогам статья, хотя врядли, DBA от экспериментаторов удалось отмазаться.
По итогам статьи - мое личное мнение - главное - не пускать восторженных энтузиастов в продуктивный контур.
Впрочем так всегда было и до моды на нейросети.
И уж тем более никогда не допускать даже возможности автоматизированного принятия решений нейросетями в критической инфраструктуре.
Потому, что полная безответственность за действия и решения при практически полном отсутствии научного и инженерного подхода . И очень молодая отрасль на уровне магии и алхимии. В древности все профессии которые сейчас работают по строгим и научно обоснованным методам обладали , искусственно или обьективно, ореолом магии и скрытного знания - врачи, строители, инженеры .
А IT даже сто лет нет. В принципе сейчас даже не зрелость - детство босоногое ;-)
Помните, как в университетах до недавнего учили Delphi и Pascal
Pascal учили не для того, что бы программировать , а для того, что бы понять что писали Вирт и Кнут.
Я не знаю, просто не в курсе, кто сейчас изучается в качестве патриархов программирования в ВУЗах.
За год самостоятельной работы можно получить объём знаний, сопоставимый с университетским курсом.
Всё, дальше перестал читать. Информация это не знания. Чем раньше это понимаешь, тем лучше по жизни потом идти.
И если бы можно было бы вернуть и начать опять , опять пошел тем же путем : Basic -> C(Assembler) -> Fortran -> C++ ->SQL (Delphi не считаю за этап). Т.е. от простого к сложному , от частного случая абстракции к общему.
Смысл в том, что для DBA опыт разработки дает существенный плюс и другое отношение к задачам по сравнению с чистыми DBA.
Со временем становится очевидно, что развитие не является линейным процессом и не происходит мгновенно. Оно требует времени, практики и системного подхода.
Именно так ! Я только совсем недавно понял , почему кафедра на которой я учился называется "Прикладная математика" и специальность по диплому "инженер-математик".
В целом по статье , как говорится - респект и уважение !
Удачи по жизни !
Главное идти по жизни твердо своим путем , в общем то не обращая внимание на реплики встречных прохожих.
Спасибо. Я всегда знал и знаю, что не все разработчики криворукие ламеры, которые встречаются и запоминаются чаще, конечно же есть нормальные !!!! Они просто тихо и спокойно делают свое дело , незаметно, скромно и эффективно.
C учетом качества , полезности и полноты ответов неожиданно, что Яндекс на первом месте. Хотя учитывая стандартную рыночную тактику опробованную еще Микрософтом во времена войны браузеров - вполне объяснимо.
Есть одна область в которой нейросети практически бесполезны - "прогнозирование влияния изменения конфигурационных параметров СУБД на производительность СУБД."
Причина проста и фундаментальна - в сети очень мало, практически нет, данных о экспериментах по анализу производительности СУБД. И поэтому не имея математической модели СУБД все прогнозы это банальная линейная аппроксимация. А если нет материалов для обучения модели , как же нейросеть даст приемлемый для практического применения прогноз ?
Так, что в отличии от разработчиков у специалистов performance engineering перспективы вполне приемлемые , а учитывая использование нейросетей для анализа данных даже очень перспективные - данные то нужно подготовить , а для этого нужен инструмент. И нейросеть тут не поможет , потому , что ранее таких инструментов просто не было . это инженерная задача для человека - создать новый продукт используя интуицию , жизненный опыт и здравый смысл.
Так, что хорошо, что в далёком 2001 году , я ушел из разработчиков в сисадмины, а потом в DBA 😎
P.S.
Подпишитесь на платную версию Claude или ChatGPT. Это стоит 20 долларов в месяц.
После того, как меня удастся убедить, что бесплатный DeepSeek для моих задач менее полезен.
Вариантов возврата в офис не рассматриваю. В принципе.
Ну разве , что увеличение ежемесячного оклада до 1М 😉
Классика - а кто автор :
Анастасия Томе работает в Испании, преподаватель и менеджер по подбору персонала.
Мартин Ворнер работает в Великобритании, соучредитель компании, занимающейся разработкой блокчейн-платформы.
Смысла дальше читать и тратить время - никакого(комменты посмотреть разве, что, хотя бы просто в очередной раз убедился - удалёнка это навсегда и никакое окно Овертона пока не помогает). Не читал, время не тратил.
Как регулярно минусуемый и в комментариях и в карму и в статьи(мои самые любимые причины 😁- личная неприязнь, ничего не понял, придерживаюсь другого мнения), IMHO, позволю себе потратить имеющийся 1 комментарий в сутки:
1) тема кармы и минусов идёт на Хабре , на моей памяти с 2019 года. Ничего не меняется , администрацию текущая ситуация цензуры толпы - устраивает.
2) Какой смысл администрации в том, что авторы публикуются на других ресурсах и трафик просмотров проходит мимо Хабра? Риторический вопрос .
3) минусы влияют только на ограничение свободы слова минусуемому. Никто и никогда не меняет своей точки зрения только потому, что кому-то вообще не известному в интернете , что то не нравится .
5) минусы под статьями вообще никак не влияют на индексирование статей поисковиками и нейросетями - проверено лично 😉
В августе 2023 года , после 2х лет на позиции руководителя направления(направление выстроено с нуля, процессы сформированы и отлажены), после хронического выгорания(раньше я смеялся над этим термином , пока на себе не почувствовал) - я вернулся на позицию эксперта направления .
За прошедшее время - ни разу не пожалел. Столько нового интересного сделано, сколько еще предстоит. Даже, можно сказать больше - уходить надо было раньше , при первых звоночках , не дожидаясь выгорания.
Какие покупатели ? О чем вы вообще ?
Всё лежит в GitHub свободно для всех желающих . Кому интересно - скачивает и использует.
19 звезд, 2 форка - наверное кому-то все таки интересно.
Анонс:
На следующей неделе будет публикация о тестировании конфигураторов Тантор Лабс(на дзене выложено уже)и pgpro_tune(в процессе).
Дело за малым - попытаться объяснить это минусаторам типа "текст похож на сгенерированный".
IMHO это бесполезно .
Впрочем , причины минусов давно уже потеряли всякий смысл и обоснованность , да и вряди были когда то , я например давно перестал переживать , что у кого то обостряются чувства из за использования кавычек, длинных тире и что там еще они используют как маркеры :-)
Я использую нейросеть для анализа результатов, генерации гипотез и подготовки макетов публикаций , потому, что это сильно экономит мое личное время, которое я трачу на новые эксперименты и исследования , и признаюсь - переживания борцунов с ИИ меня не волнуют от слова вообще.
Этот недостаток очень легко устраняется , если слой хранения и слой обработки данных разделены.
Хотя , конечно, это сейчас не модно и против тренда .
Только есть одна серьезная проблема, которую надо учитывать и не ждать чудес.
EXPLAIN ANALYZE это единичное выполнение единичного запроса.
И иногда бывает, что снижение стоимости запроса в результате анализа плана выполнения приводит к деградации производительности СУБД под высокой параллельной нагрузкой.
И слава богу.
Причина очень проста и давно и всем известна :
1. Юридический и экономический вакуум ответственности
Короткий и честный ответ: сегодня — никто не отвечает, и это одна из главных проблем и одновременно тормозов для внедрения ИИ в критических сферах.
Формально ответственность пытаются переложить на человека, который использует систему. Врач, поставивший диагноз с помощью ИИ, несёт ответственность за окончательное решение. Оператор беспилотного автомобиля (если он есть) — за действия машины. Но это юридическая фикция, потому что:
Человек не может эффективно контролировать «чёрный ящик». Если модель выдаёт рекомендацию, у врача нет инструментов, чтобы проверить её обоснованность в реальном времени. Он либо доверяет, либо нет. Если он доверяет ошибочной рекомендации — виноват он. Если не доверяет правильной — он теряет пользу от системы. Это ставит человека в ложную позицию.
Производитель модели снимает с себя ответственность. В лицензионных соглашениях чётко прописано: «модель предоставляется "как есть", мы не гарантируем безошибочность и не несём ответственности за последствия её использования». Юридически производитель отвечает только за явные дефекты кода (если ошибка в софте, а не в модели), но не за ошибки самой модели, потому что они — не баг, а feature статистического обучения.
2. Почему это принципиальная проблема?
В традиционной инженерии действует принцип: за любое решение отвечает человек или организация. Если мост рухнул — отвечает инженер и строительная компания. Если лекарство убило — отвечает производитель и врач.
В случае с ИИ мы имеем дело с системой, которая:
не программируется явно, а обучается на данных;
не детерминирована (может давать разные ответы на один и тот же запрос);
не объясняет свои решения (проблема интерпретируемости).
Как привлечь к ответственности алгоритм? Его нельзя посадить в тюрьму, оштрафовать или лишить лицензии. А если привлекать разработчиков, то за что? За то, что модель ошиблась на примере, которого не было в обучающей выборке? Но это неизбежно для любой статистической системы.
В области использования ИИ для оптимизации производительности СУБД - точно такая же проблема . В сети практически , нет данных о экспериментах. Поэтому в области performance engineering - пользы от нейросетей пока не очень, только для анализа данных, советы просто гадание и угадывание. Иногда попадают. Чаще - нет. Но процесс конечно интересный .
C СУБД - тоже самое. Дословно.
Я как раз сейчас присутствую при восторженном эксперименте -"а давайте сделаем на продуктиве как тут вот в интернете написано и ИИ подсказал". Может быть будет по итогам статья, хотя врядли, DBA от экспериментаторов удалось отмазаться.
По итогам статьи - мое личное мнение - главное - не пускать восторженных энтузиастов в продуктивный контур.
Впрочем так всегда было и до моды на нейросети.
И уж тем более никогда не допускать даже возможности автоматизированного принятия решений нейросетями в критической инфраструктуре.
Потому, что полная безответственность за действия и решения при практически полном отсутствии научного и инженерного подхода . И очень молодая отрасль на уровне магии и алхимии. В древности все профессии которые сейчас работают по строгим и научно обоснованным методам обладали , искусственно или обьективно, ореолом магии и скрытного знания - врачи, строители, инженеры .
А IT даже сто лет нет. В принципе сейчас даже не зрелость - детство босоногое ;-)
Pascal учили не для того, что бы программировать , а для того, что бы понять что писали Вирт и Кнут.
Я не знаю, просто не в курсе, кто сейчас изучается в качестве патриархов программирования в ВУЗах.
Всё, дальше перестал читать. Информация это не знания. Чем раньше это понимаешь, тем лучше по жизни потом идти.
Лишь один вопрос - а зачем ?
Неужели кто-нибудь занимается 剣道の武道 ради очков в соревнованиях?
失礼します。
Я начинал в 1987 году будучи в 10-м классе.
И если бы можно было бы вернуть и начать опять , опять пошел тем же путем : Basic -> C(Assembler) -> Fortran -> C++ ->SQL (Delphi не считаю за этап). Т.е. от простого к сложному , от частного случая абстракции к общему.
Смысл в том, что для DBA опыт разработки дает существенный плюс и другое отношение к задачам по сравнению с чистыми DBA.
Именно так ! Я только совсем недавно понял , почему кафедра на которой я учился называется "Прикладная математика" и специальность по диплому "инженер-математик".
В целом по статье , как говорится - респект и уважение !
Удачи по жизни !
Главное идти по жизни твердо своим путем , в общем то не обращая внимание на реплики встречных прохожих.
Спасибо. Я всегда знал и знаю, что не все разработчики криворукие ламеры, которые встречаются и запоминаются чаще, конечно же есть нормальные !!!! Они просто тихо и спокойно делают свое дело , незаметно, скромно и эффективно.
Удачи !
Сразу вспоминается классический анекдот - "вам шашечки или ехать?"
Этот тезис давно не является общеизвестным и проверен экспериментально:
https://habr.com/p/958320/
Да, все верно - LWLock:LockManager
Итог экспериментов
Операционная скорость в ходе Эксперимента-2 снизилась в среднем ~14%.
Характерные события ожидания в ходе Эксперимента-2, существенно изменились. Наибольший рост(более 50%) отмечен по событиям ожидания типа LWLock:
LockManager : 100%
BufferContent: > 60%
Самый главный вопрос :
А как устанавливается причинно-следственная связь ?
Интуитивно ? Эмпирически ? На основе экспертного мнения типа - "как известно всем ... "?
Или есть математически строгие критерии ?
Что тут неожиданного ?
C учетом качества , полезности и полноты ответов неожиданно, что Яндекс на первом месте. Хотя учитывая стандартную рыночную тактику опробованную еще Микрософтом во времена войны браузеров - вполне объяснимо.
К какой категории относятся те , кто использует нейросеть как очередной рабочий инструмент ?
Есть одна область в которой нейросети практически бесполезны - "прогнозирование влияния изменения конфигурационных параметров СУБД на производительность СУБД."
Причина проста и фундаментальна - в сети очень мало, практически нет, данных о экспериментах по анализу производительности СУБД. И поэтому не имея математической модели СУБД все прогнозы это банальная линейная аппроксимация. А если нет материалов для обучения модели , как же нейросеть даст приемлемый для практического применения прогноз ?
Так, что в отличии от разработчиков у специалистов performance engineering перспективы вполне приемлемые , а учитывая использование нейросетей для анализа данных даже очень перспективные - данные то нужно подготовить , а для этого нужен инструмент. И нейросеть тут не поможет , потому , что ранее таких инструментов просто не было . это инженерная задача для человека - создать новый продукт используя интуицию , жизненный опыт и здравый смысл.
Так, что хорошо, что в далёком 2001 году , я ушел из разработчиков в сисадмины, а потом в DBA 😎
P.S.
После того, как меня удастся убедить, что бесплатный DeepSeek для моих задач менее полезен.
А теперь самое интересное - как оценить оптимальность выбранной конфигурации ?
P.S. Ничего не сказано о нагрузке инфраструктуры.
На удалёнке с апреля 2020 года.
Вариантов возврата в офис не рассматриваю. В принципе.
Ну разве , что увеличение ежемесячного оклада до 1М 😉
Классика - а кто автор :
Смысла дальше читать и тратить время - никакого(комменты посмотреть разве, что, хотя бы просто в очередной раз убедился - удалёнка это навсегда и никакое окно Овертона пока не помогает). Не читал, время не тратил.
Это ведь прошлогодний доклад на PgConf.2025 :"Статистический анализ результатов бенчмарков 31.03.2025"
Молодые авторы - в Postgres Professional сейчас занимаются темой статистического анализа производительности СУБД ?
Неужели за год новых исследований и публикаций не было ?
Я использую нейросеть для следующих задач :
1)анализ результатов экспериментов, проведённых с использованием разработанного мной инструмента
2)генерация короткого предисловия и послесловия
3)генерация иллюстрации(КДПВ) и подписи к иллюстрации
Считается ли такая статья - написанная нейросетью ?
Это риторический вопрос , конечно.
Можно ли, описанные выше задачи выполнить без использования нейросети ? Конечно можно , если есть в запасе достаточно свободного времени .
P.S.
Это да , ЖЖ в этом плане - отличная вещь !
Как регулярно минусуемый и в комментариях и в карму и в статьи(мои самые любимые причины 😁- личная неприязнь, ничего не понял, придерживаюсь другого мнения), IMHO, позволю себе потратить имеющийся 1 комментарий в сутки:
1) тема кармы и минусов идёт на Хабре , на моей памяти с 2019 года. Ничего не меняется , администрацию текущая ситуация цензуры толпы - устраивает.
2) Какой смысл администрации в том, что авторы публикуются на других ресурсах и трафик просмотров проходит мимо Хабра? Риторический вопрос .
3) минусы влияют только на ограничение свободы слова минусуемому. Никто и никогда не меняет своей точки зрения только потому, что кому-то вообще не известному в интернете , что то не нравится .
5) минусы под статьями вообще никак не влияют на индексирование статей поисковиками и нейросетями - проверено лично 😉
Так, что - привет минусаторам 😉
В августе 2023 года , после 2х лет на позиции руководителя направления(направление выстроено с нуля, процессы сформированы и отлажены), после хронического выгорания(раньше я смеялся над этим термином , пока на себе не почувствовал) - я вернулся на позицию эксперта направления .
За прошедшее время - ни разу не пожалел. Столько нового интересного сделано, сколько еще предстоит. Даже, можно сказать больше - уходить надо было раньше , при первых звоночках , не дожидаясь выгорания.