От осторожных гипотез к верифицированным выводам: тест инструкций на реальных метриках нагрузки.

Видеть не просто метрики, а первопричину. Философская оптика для PostgreSQL.

⚠️Официальное предупреждение (дисклеймер)⚠️

Настоящая статья подготовлена с использованием технологий искусственного интеллекта.

В частности:

— экспериментальные данные обработаны и проанализированы нейросетью;

— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;

— макет статьи редактировался и корректировался нейросетью.

Лицам, придерживающимся позиции «ИИ-веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Предыдущая статья цикла

PG_EXPECTO + Philosophical_instruction_v3.5_beta: двойной анализ инцидента PostgreSQL / Хабр

Содержание

1. Исходные данные по инциденту производительности СУБД
2. Инструкции Philosophical_instruction для нейросети
3. Формирование отчета по инциденту производительности СУБД PostgreSQL c помощью инструкции и промпта PG_EXPECTO
4. Анализ отчета по инциденту производительности СУБД с помощью инструкции "Philosophical_instruction_v3_5_beta"
5. Анализ отчета по инциденту производительности СУБД с помощью инструкции "Philosophical_instruction_v4"
6. Анализ отчета по инциденту производительности СУБД с помощью инструкции "Philosophical_instruction_v5"
7. Анализ отчета по инциденту производительности СУБД с помощью инструкции "Philosophical_instruction_v5.1"
8. Анализ влияния инструкций "Philosophical_instruction_*" на качество и полноту отчета
Общий итог
Послесловие

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

PG_EXPECTO v.7 : Анализ инцидента производительности высоконагруженной СУБД (CPU=200 RAM=1TB). | Postgres DBA | Дзен

2. Инструкции Philosophical_instruction для нейросети

Philosophical Instruction vX/X Beta Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой.

Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection.

Loc-ID/Philosophical_instruction: Philosophical Instruction Beta Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой. Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection.

3. Формирование отчета по инциденту производительности СУБД PostgreSQL c помощью инструкции и промпта PG_EXPECTO

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.

PG_EXPECTO + Philosophical_instruction 5.1 = повышение качества анализа инцидентов PostgreSQL | Postgres DBA | Дзен

Сравнение результатов «PG_EXPECTO + Philosophical_instruction»: 3.5 -> 4 -> 5 -> 5.1