От осторожных гипотез к верифицированным выводам: тест инструкций на реальных метриках нагрузки.
⚠️Официальное предупреждение (дисклеймер)⚠️
Настоящая статья подготовлена с использованием технологий искусственного интеллекта.
В частности:
— экспериментальные данные обработаны и проанализированы нейросетью;
— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;
— макет статьи редактировался и корректировался нейросетью.
Лицам, придерживающимся позиции «ИИ-веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.
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.