От осторожных гипотез к верифицированным выводам: тест инструкций на реальных метриках нагрузки.
⚠️Официальное предупреждение (дисклеймер)⚠️
Настоящая статья подготовлена с использованием технологий искусственного интеллекта.
В частности:
— экспериментальные данные обработаны и проанализированы нейросетью;
— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;
— макет статьи редактировался и корректировался нейросетью.
Лицам, придерживающимся позиции «ИИ-веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.
GitFlic — pg_expecto — статистический анализ производительности и ожиданий СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Предыдущая статья цикла
PG_EXPECTO + Philosophical_instruction_v3.5_beta: двойной анализ инцидента PostgreSQL / Хабр
Содержание
1. Исходные данные по инциденту производительности СУБД
Статистические данные по инциденту производительности СУБД
-
_1.settings.txt — НАСТРОЙКИ СУБД и VM
-
2.1.test.postgresqlvmstat.txt — ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД: КОМПЛЕКСНЫЙ КОРРЕЛЯЦИОННЫЙ АНАЛИЗ СУБД и VMSTAT
-
2.postgresqlvmstat.txt — ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД: КОМПЛЕКСНЫЙ КОРРЕЛЯЦИОННЫЙ АНАЛИЗ СУБД и VMSTAT
-
3.1.test.vmstatiostat.txt — ТЕСТОВЫЙ ОТРЕЗОК: КОМПЛЕКСНЫЙ КОРРЕЛЯЦИОННЫЙ АНАЛИЗ МЕТРИК VMSTAT-IOSTAT
-
3.vmstatiostat.txt — ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД: КОМПЛЕКСНЫЙ КОРРЕЛЯЦИОННЫЙ АНАЛИЗ МЕТРИК Vmstat iostat
TEST-Philosophical_instructions — Яндекс Диск
Анализ инцидента по базовой методике pg_expecto
2. Инструкции Philosophical_instruction для нейросети
Philosophical Instruction vX/X Beta Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой.
Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection.
3. Формирование отчета по инциденту производительности СУБД PostgreSQL c помощью инструкции и промпта PG_EXPECTO
Инструкция PG_EXPECTO
инструкция_pg_expecto.txt — Яндекс Диск
Промпт для подготовки сводного отчета по инциденту производительности СУБД
incident-prompt.txt — Яндекс Диск
Результат: Отчет по инциденту производительности СУБД
4. Анализ отчета по инциденту производительности СУБД с помощью инструкции «Philosophical_instruction_v3_5_beta»
Входные данные
-
incident.txt — Отчет по инциденту производительности СУБД
-
Philosophical_instruction_v3_5_beta.md
Результат: Анализ отчета по инциденту производительности СУБД с использованием инструкции Philosophical_instruction_v3_5_beta
1.Philosophical_instruction_v3_5.txt — Яндекс Диск
5. Анализ отчета по инциденту производительности СУБД с помощью инструкции «Philosophical_instruction_v4»
Входные данные
-
incident.txt — Отчет по инциденту производительности СУБД
-
Philosophical_instruction_v4.md
Результат: Анализ отчета по инциденту производительности СУБД с использованием инструкции Philosophical_instruction_v4
2.Philosophical_instruction_BETA_v4.txt — Яндекс Диск
6. Анализ отчета по инциденту производительности СУБД с помощью инструкции «Philosophical_instruction_v5»
Входные данные
-
incident.txt — Отчет по инциденту производительности СУБД
-
Philosophical_instruction_v5.md
Результат: Анализ отчета по инциденту производительности СУБД с использованием инструкции Philosophical_instruction_v5
3.Philosophical_instruction_BETA_v5.txt — Яндекс Диск
7. Анализ отчета по инциденту производительности СУБД с помощью инструкции «Philosophical_instruction_v5.1»
Входные данные
-
incident.txt — Отчет по инциденту производительности СУБД
-
Philosophical_instruction_v5.1.md
Результат: Анализ отчета по инциденту производительности СУБД с использованием инструкции Philosophical_instruction_v5.1
4.Philosophical_instruction_BETA_v5.1.txt — Яндекс Диск
8. Анализ влияния инструкций «Philosophical_instruction_*» на качество и полноту отчета
Входные данные для анализа
Отчет по инциденту:
-
incident.txt
Инструкция pg_expecto:
-
инструкция_pg_expecto.txt
Инструкции Philosophical_instruction:
-
Philosophical_instruction_v3_5_beta.md
-
Philosophical_instruction_BETA_v4.md
-
Philosophical_instruction_BETA_v5.md
-
Philosophical_instruction_BETA_v5.1.md
Анализ отчета по инциденту с использованием инструкций Philosophical_instruction:
-
1.Philosophical_instruction_v3_5.txt
-
2.Philosophical_instruction_BETA_v4.txt
-
3.Philosophical_instruction_BETA_v5.txt
-
4.Philosophical_instruction_BETA_v5.1.txt
Общий анализ инструкций «Philosophical_instruction_v3_5_beta.md», «Philosophical_instruction_BETA_v4.md», «Philosophical_instruction_BETA_v5.md», «Philosophical_instruction_BETA_v5.1.md»
Проанализированы четыре версии инструкций, использованные для генерации отчётов по файлу incident.txt. Анализ выполнен с учётом требований инструкция_pg_expecto.txt и фокусируется на применимости инструкций к задаче диагностики производительности PostgreSQL.
Сравнительная характеристика инструкций
v3.5_beta
-
Структурированность протоколов: Средняя (явные чек-листы по тирам).
-
Эпистемическая строгость: Светофоры, но без жёсткой привязки к источнику.
-
Специализированные доменные протоколы: Отсутствуют.
-
Применимость к анализу метрик БД: Ограничена (нет встроенных знаний о PostgreSQL).
-
Учёт ограничений данных: Присутствует (статус 🟡 для вторичной агрегации).
-
Склонность к ложным корреляциям: Не выражена, но нет явного Contrastive Check.
-
Качество отчёта по incident.txt (субъективно): Хорошее, но много 🟡; выводы осторожны.
v4
-
Структурированность протоколов: Высокая (чёткие алгоритмы по типам задач).
-
Эпистемическая строгость: Унифицированная система статусов (Source × Freshness).
-
Специализированные доменные протоколы: Domain Detection (запрос критериев).
-
Применимость к анализу метрик БД: Требует явного предоставления доменных критериев.
-
Учёт ограничений данных: Более явное разделение 🟢/🟡/🔴.
-
Склонность к ложным корреляциям: Contrastive Check только для Architecture/High-Stakes.
-
Качество отчёта по incident.txt (субъективно): Более структурирован, лучше выделены приоритеты.
v5
-
Структурированность протоколов: Очень высокая (добавлено философское ядро).
-
Эпистемическая строгость: Расширенная система статусов + Calibrated Uncertainty.
-
Специализированные доменные протоколы: Domain Detection (уточнение до 3 вопросов).
-
Применимость к анализу метрик БД: То же, но более строго требует критерии.
-
Учёт ограничений данных: Добавлен протокол Partial Knowledge.
-
Склонность к ложным корреляциям: Contrastive Check для Architecture/Analysis/High-Stakes.
-
Качество отчёта по incident.txt (субъективно): Наиболее полный анализ, явно указаны ограничения.
v5.1
-
Структурированность протоколов: Максимальная (добавлены Self-Correction, Requirement Conflict).
-
Эпистемическая строгость: Усилена самокоррекция и конфликт требований.
-
Специализированные доменные протоколы: Domain Detection + ограничение в 2 раунда уточнений.
-
Применимость к анализу метрик БД: То же, плюс автоматическая проверка на противоречия в выводах.
-
Учёт ограничений данных: Partial Knowledge + Contrastive Check.
-
Склонность к ложным корреляциям: То же, что в v5.
-
Качество отчёта по incident.txt (субъективно): Аналогичен v5, добавлен самоанализ предыдущих ответов.
Ключевые различия, влияющие на анализ производительности СУБД:
-
v3.5_beta — базовый уровень. Отчёт содержит необходимые разделы, но многие выводы имеют статус 🟡 из-за отсутствия явного механизма запроса доменных критериев. Применение светофоров последовательное.
-
v4 — введён Domain Detection, но в сгенерированном отчёте (2.Philosophical_instruction_BETA_v4.txt) он не активирован, так как пользователь не предоставил критерии. Отчёт содержит явное указание на нехватку данных.
-
v5 — философское ядро усиливает скептицизм в отношении корреляций, что важно для метрик СУБД. В отчёте (4.Philosophical_instruction_BETA_v5.1.txt) явно выделены ложные связи (например, идентичные коэффициенты для Extension/IO/Lock). Добавлен блок «WHERE IT WILL BREAK» (Pre-Mortem), полезный для прогнозирования узких мест.
-
v5.1 — минимальные отличия от v5 в контексте данной задачи; добавлен Self-Correction Protocol, но в предоставленном отчёте он не проявился, так как не было предыдущих ответов.
Общий вывод по инструкциям:
Все версии инструкций способны генерировать структурированный отчёт с эпистемической маркировкой.
Однако для задач анализа производительности PostgreSQL наиболее релевантны версии v5 и v5.1, поскольку они:
-
Требуют явного указания доменных критериев (что соответствует инструкция_pg_expecto.txt — «если информации недостаточно, укажи, каких данных не хватает»).
-
Включают Contrastive Check, снижающий риск интерпретации корреляции как причинности (критично при анализе метрик вроде wa ~ util).
-
Предоставляют Pre-Mortem для прогнозирования отказов, что соответствует требованию «анализировать тренды, а не точечные значения».
1. Итоговый отчет о влиянии инструкции на состав и полноту подготовленного отчета
На основе сравнения четырёх отчётов, сгенерированных с использованием соответствующих версий инструкций, установлено следующее влияние методологии на результат.
1.1. Состав отчета
Общие разделы (присутствуют во всех версиях):
-
Общая информация (конфигурация, периоды).
-
Ключевые проблемы СУБД и инфраструктуры.
-
Рекомендации по оптимизации.
-
Необходимая дополнительная информация.
Различия в составе:
Интегральный приоритет типов ожиданий:
-
v3.5: 🟢
-
v4: 🟢
-
v5 / v5.1: 🟢
Явное указание на ограничения агрегации:
-
v3.5: 🟡
-
v4: 🟡
-
v5 / v5.1: 🟢 (в v5.1 выделено)
Проверка внутренней согласованности метрик:
-
v3.5: Отсутствует
-
v4: Частично
-
v5 / v5.1: 🟢 (отмечено противоречие cpu idle медиана vs тренд)
Блок «WHERE IT WILL BREAK» (Pre-Mortem):
-
v3.5: Отсутствует
-
v4: Отсутствует
-
v5 / v5.1: 🟢
Contrastive Check (альтернативные объяснения):
-
v3.5: Отсутствует
-
v4: Отсутствует
-
v5 / v5.1: 🟢 (указание на общий фактор для Extension/IO/Lock)
Статус доменных критериев:
-
v3.5: Не запрошены
-
v4: Запрошены, но не получены
-
v5 / v5.1: Запрошены явно в тексте
Вывод: Инструкции v5/v5.1 обеспечивают более полный состав отчёта за счёт включения протоколов Pre-Mortem, Contrastive Check и более строгой проверки внутренней непротиворечивости данных.
1.2. Полнота анализа
Под полнотой понимается глубина проработки выводов и учёт ограничений исходных данных.
-
v3.5: Анализ корректен, но многие утверждения остаются на уровне 🟡. Например, связь Extension ↔ us отмечена, но не проверена на возможную ложную корреляцию.
-
v4: Более структурирован, явно разделены 🟢 и 🟡. Однако не хватает критического взгляда на одинаковые коэффициенты корреляции для Extension, IO, Lock.
-
v5 / v5.1: Наиболее полный. Отчёт v5.1 явно указывает: «Типы Extension, IO и Lock демонстрируют практически идентичные коэффициенты корреляции… что может указывать на общий фактор». Это предотвращает ошибочную интерпретацию каждой метрики как независимой причины. Также в v5.1 замечено противоречие в данных cpu idle (медиана выросла, но тренд отрицательный) и запрошено уточнение исходных рядов. Это соответствует требованию инструкция_pg_expecto.txt о проверке внутренней согласованности.
Оценка влияния инструкции:
Использование v5.1 привело к наиболее полному и осторожному анализу, где явно обозначены границы применимости выводов и перечислены необходимые дополнительные данные. Инструкции v3.5 и v4 дают приемлемый результат, но уступают в глубине верификации.
2. Рекомендация по выбору и применению инструкции для подготовки итогового сводного отчета по производительности СУБД и инфраструктуры
На основании сравнительного анализа и требований инструкция_pg_expecto.txt рекомендуется:
2.1. Выбор инструкции
Рекомендуемая версия: Philosophical_instruction_BETA_v5.1.md (или v5 при отсутствии v5.1).
Обоснование:
Соответствие принципам анализа метрик СУБД:
-
Contrastive Check (3.14) снижает риск ложной каузальной интерпретации корреляций, что критически важно при работе с iostat, vmstat, WAIT_EVENT_TYPE.
-
Pre-Mortem (3.12) позволяет прогнозировать сценарии деградации (например, «что произойдёт при дальнейшем росте утилизации дисков»), что ценно для планирования мощностей.
-
Self-Correction Protocol (3.27) полезен при итеративном анализе, когда новые данные могут изменить предыдущие выводы.
Учёт доменной специфики:
-
Протокол Domain Detection (3.2) обязывает агента запросить критерии (пороговые значения util, допустимый aqu_sz, целевой hit ratio), без которых анализ остаётся на уровне 🟡. Это прямо соответствует требованию инструкция_pg_expecto.txt «если информации недостаточно — укажи, каких данных не хватает».
Эпистемическая строгость:
-
Система статусов 🟢/🟡/🔴/⬛ с учётом свежести данных предотвращает выдачу устаревших рекомендаций (например, по параметрам конфигурации).
-
Calibrated Uncertainty запрещает слова «очевидно» без источника, что дисциплинирует формулировки.
Практическая применимость:
-
Выходной отчёт по структуре (# Общая информация, # Ключевые проблемы, # Рекомендации, # Необходимая дополнительная информация) полностью соответствует шаблону, заданному в incident.txt.
-
Блок «WHERE IT WILL BREAK» может быть напрямую использован командой эксплуатации для приоритезации рисков.
2.2. Рекомендации по применению инструкции для анализа производительности PostgreSQL
Для получения максимально качественного отчёта с использованием Philosophical_instruction_BETA_v5.1 следует:
Предоставить агенту доменные критерии ДО начала анализа (как того требует п.3.2 инструкции). В контексте PostgreSQL и инфраструктуры это могут быть:
-
Целевые значения утилизации дисков (%util), при превышении которых считается, что подсистема перегружена.
-
Приемлемая доля cpu iowait и cpu steal.
-
Ожидаемый cache hit ratio для shared_buffers.
-
Критические значения для LWLock ожиданий (например, доля BufferMapping > X%).
-
Известные паттерны ложных корреляций в данной среде (например, Extension всегда коррелирует с us, потому что расширения работают в user space).
-
Обеспечить агента исходными временными рядами метрик, а не только агрегированными отчётами. Это позволит выполнить требования п.3.24 (Smoothness Principle) и избежать артефактов агрегации, на которые указано в v5.1-отчёте (противоречие медианы и тренда cpu idle).
-
Использовать режим Deep («глубже», «как мастер») при необходимости детального объяснения механизмов (например, почему растёт BufferMapping). Это активирует расширенный контекстный анализ.
-
Включать в запрос явное указание на тип задачи — Analysis / Recommendation или High-Stakes (если инцидент критичен для бизнеса). Это гарантирует применение всех необходимых протоколов: Multi-Hypothesis, Self-Consistency, Contrastive Check.
-
При получении отчёта обращать внимание на блок «Необходимая дополнительная информация» и по возможности предоставить запрошенные данные (планы запросов, pg_stat_bgwriter, логи) для повышения статуса выводов с 🟡 до 🟢.
Заключение:
Инструкция Philosophical_instruction_BETA_v5.1 в сочетании с доменными критериями, предоставленными в инструкция_pg_expecto.txt, обеспечивает наивысшее качество и достоверность отчёта о производительности СУБД PostgreSQL среди рассмотренных версий. Рекомендуется использовать её в качестве основы для стандартизации процесса диагностики инцидентов.
Общий итог
Проведенное сравнение версий инструкций Philosophical_instruction в рамках задачи PG_EXPECTO убедительно демонстрирует, что качество автоматизированной диагностики PostgreSQL напрямую зависит от внедрения механизмов эпистемической строгости. Если ранние версии (v3.5, v4) успешно справляются с базовой структуризацией данных и выдачей осторожных оценок, то переход к философскому ядру и протоколам верификации в v5.1 знаменует качественный скачок. Включение блоков Contrastive Check и Pre-Mortem не просто повышает полноту отчета, но и выполняет критическую функцию защиты от ложной интерпретации корреляций (таких как связь Extension, IO и Lock), что является краеугольным камнем анализа метрик СУБД. Итоговый вердикт: инструкция v5.1 обеспечивает наивысшую достоверность выводов, однако ее эффективность находится в прямой зависимости от полноты предоставленных доменных критериев и первичных временных рядов.
Послесловие
Эволюция от Philosophical_instruction v3.5 до v5.1 в контексте проекта PG_EXPECTO отражает более глобальный тренд в разработке автономных AI-агентов для эксплуатации инфраструктуры. Мы наблюдаем движение от простого реферирования логов к полноценному расследованию с внутренней самопроверкой. Способность инструкции не только находить проблему, но и явно указывать на границы собственного незнания (через запрос недостающих данных) превращает нейросеть из «оракула» в надежного ассистента-исследователя. Дальнейшее развитие методологии видится в углублении предиктивной аналитики на основе Pre-Mortem сценариев, что позволит командам эксплуатации перейти от реактивного тушения пожаров производительности к проактивному управлению надежностью СУБД.
Следующая статья цикла:
Как двухуровневая система инструкций — предметная PG_EXPECTO и эпистемическая Philosophical_instruction — превращает описание симптомов в верифицируемый план действий и устраняет иллюзию полного знания при диагностике PostgreSQL.
ссылка на оригинал статьи https://habr.com/ru/articles/1027408/