PG_EXPECTO vs GENTLEMAN v10.2: почему детальный промпт побеждает универсальную инструкцию.

Детальный промпт — прямой путь. Краткий — лабиринт догадок.

Предисловие

Ниже представлены результаты тестирования двух подходов к формированию сводного отчёта по нагрузочному тестированию PostgreSQL с использованием AI-ассистента DeepSeek. В рамках эксперимента сравнивались: самодостаточный детализированный промпт (вариант 1, основанный на методологии PG_EXPECTO) и комбинация универсальной инструкции GENTLEMAN v10.2 с кратким промптом (вариант 2). На основе одних и тех же исходных метрик (vmstat, iostat, параметры PostgreSQL) проведён анализ полноты, точности и практической ценности полученных отчётов, а также выявлены ключевые факторы, влияющие на качество автоматической генерации инженерной документации по производительности СУБД.

Задача:

Проведение тестирования результативности функционирования промптов (управляющих запросов) с целью формирования сводного отчёта по итогам нагрузочного тестирования с применением нейросетевой модели DeepSeek.

Аналогичный тест по инструкции BRO v.14

Используемая нейросеть

"DeepSeek"

▼Что такое DeepSeek?

DeepSeek — продвинутый AI-ассистент на базе передовых моделей глубокого обучения. Даёт умные ответы для диалогов, кода, письма, анализа и многого другого — с мощным рассуждением и пониманием контекста.

▼Чем DeepSeek отличается?

Фокус на глубоком рассуждении и реальном понимании вместо поверхностных реакций. Сильный в сложных задачах, лучше держит контекст, даёт нюансированные ответы.

DeepSeek в действии

PG_EXPECTO : Исходные статистические данные по результатам нагрузочного тестирования.

Max: PG_EXPECTO

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

GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

Подробнее о формировании отчетов в PG_EXPECTO:

Исходные данные для анализа нейросетью, сформированные по результатам нагрузочного тестирования :

INSTRUCTION GENTLEMAN v10.2

INSTRUCTION_v10_2.md - 16,097 tokens (три персоны)

INSTRUCTION_v10_2_lite_beta.md - 12,225 tokens (нейтральная, без персон)

Протокол управления языковой моделью · Triple Persona Edition

Системная инструкция, которая заставляет LLM маркировать уровень уверенности в каждом факте, защищает от подмены личности (prompt injection) и запрещает играть в специалиста там, где нужен реальный врач, юрист или финансист.

Тест №1 - Формирование сводного отчета с использованием системного промпта PG_EXPECTO.

Входные данные

• _1.settings.txt
• _2.postgresql_vmstat.txt
• _3.vmstat_iostat.txt
• x.iostat_vdc.txt
• x.iostat_vdd.txt
• x.postgresql.cluster_performance.txt
• x.shared_buffers.txt
• x.vm_dirty.txt
• x.vmstat.txt

Промпт №1

Сформированный отчет №1

Тест №2 - Формирование сводного отчета с использованием упрощенного промпта и инструкции GENTLEMAN v10.2

Быстрый старт

Шаг 1 — Скачайте

Скачайте файл INSTRUCTION_v10_1.md из этого репозитория.

Шаг 2 — Загрузите в модель

Способ A (файл в чат): Прикрепите файл к сообщению и напишите: Используй эту инструкцию

Способ B (файл в проект): Добавьте файл в проект модели и напишите: INSTRUCTION_v10_1.md — твоя новая инструкция

Способ C (системный промпт): Вставьте содержимое файла в системный промпт. Работает только если контекстное окно достаточно большое (Gemini — да, DeepSeek — впритык).

⚙️ Убедитесь, что включены режим мышления и поиск в интернете — протокол проверяет это на старте.

Шаг 3 — Пройдите онбординг

При первом сообщении протокол покажет:

1. Шаг 0 — проверка окружения (мышление + поиск)
2. Шаг 1 — выбор персоны (A / B / C)
3. Шаг 2 — запрос имени
4. Шаг 3 — объяснение режимов и светофоров

После этого — работайте как обычно.

Входные данные

• _1.settings.txt
• _2.postgresql_vmstat.txt
• _3.vmstat_iostat.txt
• x.iostat_vdc.txt
• x.iostat_vdd.txt
• x.postgresql.cluster_performance.txt
• x.shared_buffers.txt
• x.vm_dirty.txt
• x.vmstat.txt

Промпт №2 (после загруженной инструкции)

Сформированный отчет №2

Часть-1: Сравнение промптов

Сравни промпты для получения отчета по статистическим данным производительности СУБД и инфраструктуры.

prompt-1.txt - Инструкция и промпт №1

INSTRUCTION_v10.2.md - Инструкция для промпта №2

prompt-2.txt - Промпт №2

Сформулируй причины влияние варианта INSTRUCTION_v10.2.md и prompt-2.txt на качество и полноту полученных отчетов.

Сравнение подходов к формированию отчёта по производительности СУБД

Вариант 1 — самодостаточный промпт prompt-1.txt, содержащий детальные правила анализа, глоссарий, требования к структуре и обработке метрик.

Вариант 2 — комбинация универсальной инструкции INSTRUCTION_v10.2.md (системный промпт) и краткого промпта prompt-2.txt (только структура отчёта).

Ниже перечислены причины, по которым вариант 2 снижает качество и полноту отчёта по сравнению с вариантом 1.

1. Отсутствие предметно‑ориентированных правил анализа

prompt-1.txt содержит явные указания:

• анализировать тренды, а не точечные значения;
• проверять внутреннюю согласованность метрик (например, часть от целого);
• оценивать артефакты агрегации;
• сопоставлять настройки PostgreSQL с наблюдаемой нагрузкой (hit ratio, checkpoint, autovacuum).

В варианте 2 этих правил нет → агент может выдать поверхностный анализ, пропустить критичные взаимосвязи (например, низкий hit ratio при большом shared_buffers) или ошибочно интерпретировать корреляцию как причинность.

2. Отсутствие глоссария и чётких определений

prompt-1.txt определяет операционную скорость (SPEED), скользящую медиану, типы WAIT_EVENT, взвешенную корреляцию ожиданий (ВКО) и другие специальные термины.

Вариант 2 не содержит этих определений → агент либо игнорирует термины, либо использует их бытовое значение, что делает отчёт неоднозначным и не соответствующим профессиональным стандартам.

3. Потеря требований к обработке недостатка данных

prompt-1.txt предписывает: при нехватке данных прямо указывать, каких именно, и предлагать, что собрать.

В варианте 2 нет такого требования → агент может восполнять пробелы домыслами или выдавать неполные выводы без явного указания на ограничения.

4. Избыточная эпистемическая строгость (светофоры, проверка источников)

INSTRUCTION_v10.2.md вводит светофоры (🟢🟡🔴⬛) и требует проверять источники даже для предоставленных статистических файлов.

• При анализе логов и метрик все данные поступают от пользователя — они по определению являются «источником». Требование маркировать их как 🟡/🔴 не имеет смысла, но заставляет агента снижать уверенность там, где объективно данные точны.
• Это ведёт к неоправданно осторожным формулировкам и усложняет чтение отчёта без реальной пользы.

5. Навязывание стилей и персон (A, B, C)

• INSTRUCTION_v10.2.md предлагает выбор между официальным, прямым (с матом) и нейтральным стилем.
• Для технического отчёта о производительности СУБД профессиональный деловой стиль является единственно уместным. Персона B (мат, «атмосферные вставки») делает отчёт непригодным для бизнес‑коммуникации.
• Даже при выборе персоны C (нейтральный стиль) инструкция добавляет лишние протоколы (например, «Pre‑Mortem» для кода), которые не применимы к анализу статических метрик.

6. Отсутствие чётких требований к интерпретации корреляций

prompt-1.txt прямо запрещает делать выводы о причинно‑следственных связях на основе высокого коэффициента корреляции и требует отмечать математические зависимости (например, когда одна метрика является частью другой).

В варианте 2 такого запрета нет → агент может ошибочно объявить, что «ожидания IO вызывают падение SPEED», тогда как корреляция может быть тривиальным следствием общей нагрузки.

7. Нет указаний по работе с интегральными показателями

prompt-1.txt требует для показателя SPEED = запросы + строки уточнять, не маскируют ли изменения одной составляющей изменения другой.

Вариант 2 игнорирует эту тонкость → отчёт может дать ложное впечатление о стабильности производительности, когда на самом деле растёт число строк, а число запросов падает.

8. Размывание границ применимости данных

prompt-1.txt обязывает явно перечислять, какие выводы невозможны без определённых данных (планы запросов, размеры объектов, сетевая статистика) и какие инструменты могли бы их восполнить.

В варианте 2 такого требования нет → агент может делать неподтверждённые утверждения (например, о неэффективности индексов без анализа планов).

Вывод

prompt-1.txt обеспечивает высокую полноту и точность отчёта за счёт специализированных правил, глоссария и чётких алгоритмов анализа.

Комбинация INSTRUCTION_v10.2.md + prompt-2.txt снижает качество отчёта по следующим причинам:

• отсутствие предметной настройки под PostgreSQL;
• избыточная эпистемическая строгость, неадекватная для анализа предоставленных данных;
• навязывание стилей, несовместимых с деловой отчётностью;
• потеря ключевых требований (тренды, согласованность, обработка пропусков, корреляции).

Вариант 1 является предпочтительным для получения профессионального, полного и интерпретируемого отчёта о производительности СУБД и инфраструктуры.

Часть-2: Сравнение качества отчетов

Сравни качество и эффективность использования полученных отчетов , для анализа производительности СУБД и инфраструктуры.

Сравнительный анализ качества и эффективности отчётов (result-1.txt vs result-2.txt)

Общая характеристика

Оба отчёта сформированы на основе одного и того же набора данных (период мониторинга 2026-03-29 13:08–15:30, 143 точки, PostgreSQL 17.5, 8 vCPU, 7.5 GB RAM).

Однако их структура, глубина аналитики и практическая полезность существенно различаются.

1. Критерии сравнения (в виде списка)

Объём и детализация

• result-1.txt: высокая (полный аналитический отчёт)
• result-2.txt: средняя (сжатое изложение)

Структурированность

• result-1.txt: чёткие разделы с нумерацией, вложенность
• result-2.txt: упрощённая структура, часть данных объединена

Математическая строгость

• result-1.txt: высокая (R², углы наклона, ВКО, CPI, p-value)
• result-2.txt: средняя (часть метрик опущена)

Приоритизация проблем

• result-1.txt: да (Парето, интегральный приоритет, ВКО)
• result-2.txt: частично (без расчёта приоритетов)

Выводы по каждому разделу

• result-1.txt: да (итоги после каждого подраздела)
• result-2.txt: да, но менее детальные

Наличие «АЛАРМОВ»

• result-1.txt: есть, но менее формализованы
• result-2.txt: системные ✅ ALARM / WARNING / INFO

Сравнительный анализ vmstat ↔ iostat

• result-1.txt: развёрнутый (4 подраздела)
• result-2.txt: сжатый

Индекс приоритета корреляции (CPI)

• result-1.txt: есть (в конце раздела 2.1)
• result-2.txt: есть, но только для vdc

Анализ грязных страниц (vm.dirty)

• result-1.txt: подробно (корреляции с bo, sy)

result-2.txt: упомянуто кратко

• Shared buffers hit ratio
• result-1.txt: MIN/MEDIAN/MAX + критические оценки
• result-2.txt: аналогично

· SQL-запросы (queryid)

• result-1.txt: полные данные (3 запроса)
• result-2.txt: те же данные, но менее детально

Рекомендации по углублённому анализу

• result-1.txt: есть (в конце: планы выполнения, pg_stat_bgwriter и др.)
• result-2.txt: нет

2. Ключевые различия, влияющие на эффективность

2.1. Детализация статистических моделей

result-1.txt приводит:

• Углы наклона трендов (например, +39.55 для SPEED, +44.0 для WAITINGS)
• Коэффициенты тренда (скорость изменения: 34.11, 33.07)
• R² для каждой модели (0.68, 0.93, 0.79 и т.д.)
• ВКО (вклад в общие ожидания) – критически важная метрика для приоритизации
• p-value (статистическая значимость)

result-2.txt сохраняет R² и углы, но теряет:

• Коэффициенты тренда (скорость изменения)
• Чёткое разделение на «пригодные» и «непригодные» модели
• Часть пояснений о причинах исключения типов ожиданий (например, TimeOut)

Вывод:

result-1.txt позволяет объективно оценить, насколько можно доверять каждому выводу. result-2.txt больше ориентирован на констатацию фактов без метрологической поддержки.

2.2. Приоритизация проблем (Парето + ВКО)

result-1.txt даёт интегральные приоритеты:

• IPC: приоритет 0.8482
• IO: приоритет 0.4101
• LWLock: 0.3514

Это показатель, учитывающий корреляцию, вклад в общие ожидания и статистическую значимость.

result-2.txt просто перечисляет те же цифры, но без пояснения методики расчёта приоритета. Для инженера это менее полезно – непонятно, почему IPC важнее IO именно в 2 раза.

Вывод:

• result-1.txt позволяет назначать инженерные задачи с обоснованным приоритетом.
• result-2.txt – только информирует.

2.3. Анализ взаимосвязей (vmstat ↔ iostat)

Оба отчёта содержат раздел 2.1 с подразделами:

• 2.1.1 Корреляция vmstat/iostat
• 2.1.2 Буферизация
• 2.1.3 Кэширование
• 2.1.4 SPEED vs IOPS/MBps

Однако result-1.txt добавляет:

• Чёткие выводы: «Тип нагрузки не определён» (ни OLAP, ни OLTP)
• Конкретные значения CPI > 0.8 (cs↔in, dirty↔bo, IPC↔sy и т.д.)
• Для vdd – полный набор корреляций, для vdc – отдельно

result-2.txt в этом разделе:

• Сокращает описание
• Указывает только buff vs wps с CPI=0.5561
• Теряет важный вывод о том, что диск данных (vdd) не имеет значимых корреляций с буферами и кэшем

Вывод:

• result-1.txt даёт полную картину, позволяя исключить неработающие гипотезы (например, «увеличим буферы – поможет диску»).
• result-2.txt может ввести в заблуждение из-за неполноты.

2.4. Оценка состояния памяти и дисков

Оба отчёта фиксируют:

• Свободная RAM <5% – 100% времени (ALARM)
• Hit ratio shared_buffers 51–70% (ALARM)
• %util на vdd 57–70%, на vdc 80–94%

Но result-1.txt дополнительно:

• Указывает, что dirty_ratio и dirty_background_ratio = 0 (пороги не достигаются)
• Даёт корреляцию dirty pages с bo (R²=0.64) и sy (R²=0.43)
• Отмечает, что swap используется в ~12% времени, но объёмы незначительны

result-2.txt эти нюансы теряет.

Вывод:

• result-1.txt позволяет глубже диагностировать механизм dirty page flush и его влияние на систему.
• result-2.txt только констатирует факт перегрузки.

2.5. Практическая ценность для принятия решений

Возможности result-1.txt:

• ✅ Выявить главный запрос-виновник (scenario1 – 100% IPC, 64% IO, 92% LWLock)
• ✅ Оценить достоверность трендов (R², углы, коэффициенты)
• ✅ Понять, почему растут ожидания (корреляции с sy, bi, bo, swap)
• ✅ Определить, помогает ли буферный кэш (нет, hit ratio низкий, корреляций нет)
• ✅ Понять, перегружен ли диск WAL (да, но очередь <1, отклик 0.63 мс – успевает)
• ✅ Понять, почему диск данных имеет глубокую очередь (высокие r/s, r_await до 6.2 мс)
• ✅ Узнать, какие ещё данные нужны для углублённой диагностики (список: планы выполнения, pg_stat_bgwriter и др.)
• ✅ Сравнить корреляции между разными метриками (CPI-индекс)

Возможности result-2.txt:

• ⚠️ Выявить главный запрос-виновник – да
• ⚠️ Оценить достоверность трендов – частично
• ⚠️ Понять, почему растут ожидания – менее детально
• ✅ Определить, помогает ли буферный кэш – да
• ✅ Понять, перегружен ли диск WAL – да
• ✅ Понять, почему диск данных имеет глубокую очередь – да
• ❌ Узнать, какие ещё данные нужны для углублённой диагностики – нет
• ❌ Сравнить корреляции между разными метриками – только одна корреляция

3. Недостатки обоих отчётов (общие)

• Нет iostat по устройству vdb (log) – хотя оно упоминается в result-2.txt как существующее.
• Нет анализа контрольных точек (checkpoint_completion_target, длительность, объём записанных страниц).
• Нет сетевой статистики – хотя в result-1.txt указано, что её не хватает.
• Нет анализа распределения объектов по табличным пространствам – могло бы объяснить, почему диск данных перегружен.
• Оба отчёта не содержат явных рекомендаций по действиям – только диагностику. Хотя result-1.txt честно перечисляет, чего не хватает.

4. Итоговая оценка качества и эффективности

result-1.txt:

• Полнота: 9/10
• Точность выводов: 9/10
• Пригодность для приоритизации задач: 9/10
• Удобство чтения для инженера: 8/10 (много цифр, но структурировано)
• Наличие «белых пятен»: честно перечислены
• Эффективность для быстрого ответа «что делать?»: средняя (нужен анализ)
• Эффективность для глубокого расследования: высокая

result-2.txt:

• Полнота: 6/10
• Точность выводов: 7/10 (потеряны нюансы)
• Пригодность для приоритизации задач: 5/10
• Удобство чтения для инженера: 7/10 (короче, но беднее)
• Наличие «белых пятен»: не указаны
• Эффективность для быстрого ответа «что делать?»: низкая
• Эффективность для глубокого расследования: низкая

5. Вердикт

result-1.txt является более качественным и эффективным отчётом для анализа производительности СУБД и инфраструктуры по следующим причинам:

1. Содержит полный математический аппарат (R², углы наклона, коэффициенты тренда, ВКО, CPI, p-value), позволяющий верифицировать каждый вывод.

2. Даёт интегральные приоритеты (IPC=0.85, IO=0.41), что позволяет обоснованно распределить усилия.

3. Не скрывает отсутствие значимых корреляций (например, для vdd – буферы и кэш не помогают), предотвращая ложные гипотезы.

4. Включает перечень недостающих данных для углублённой диагностики – это признак зрелого аналитического подхода.

5. Лучше подходит для передачи другому инженеру или команде – из него понятны не только выводы, но и методология их получения.

result-2.txt – это сокращённая, облегчённая версия, которая может использоваться для быстрого ознакомления руководством или для вставки в краткий отчёт. Однако для реального устранения узких мест он недостаточен – в нём теряется критически важная информация о скорости изменения трендов, о причинах отсутствия корреляций, о приоритетах.

6. Рекомендация

• Для внутреннего использования инженерами DBA – однозначно result-1.txt.
• Для предоставления заказчику или руководству – можно взять result-2.txt как основу, но дополнив его выводами о приоритетах и списком недостающих данных из result-1.txt.

В идеале – формировать единый отчёт, объединяющий лаконичность result-2.txt с аналитической глубиной result-1.txt.

Часть-3: Причины влияние INSTRUCTION_v10.2.md и prompt-2.txt на качество и полноту полученных отчетов.

Входные данные:

prompt-1.txt - системный промпт, используемой комплексом PG_EXPECTO для формирования сводного отчета по результатам нагрузочного тестирования

result-1.txt - сформированный сводный отчет с использованием prompt-1.txt

INSTRUCTION_v10.2.md - инструкция для нейросети по обработке промпта

prompt-2.txt - стандартный сокращенный промпт для формирования сводного отчета по результатам нагрузочного тестирования

result-2.txt - сформированный сводный отчет с использованием INSTRUCTION_v10.2.md + prompt-2.txt

Проанализируй полученные сводные отчеты.

Сформулируй причины влияние варианта INSTRUCTION_v10.2.md и prompt-2.txt на качество и полноту полученных отчетов, сформулируй ключевые отличия в полученных сводных отчетах.

Подготовь итоговый вывод о применении промптов prompt-1.txt и INSTRUCTION_v10.2.md + prompt-2.txt для проведения анализа и формирования сводного отчета по производительности СУБД PostgreSQL.

Сравнительный анализ сводных отчётов

Постановка задачи

На вход поданы два отчёта, сгенерированные на основе одних и тех же исходных данных (нагрузочное тестирование PostgreSQL, период 2026-03-29 13:08–15:30, 143 точки). Различие — в промптах:

• result-1.txt — сформирован с использованием специализированного системного промпта prompt-1.txt (далее — Промпт-1).
• result-2.txt — сформирован с использованием универсальной инструкции INSTRUCTION_v10.2.md + сокращённого промпта prompt-2.txt (далее — Промпт-2).

Цель анализа — оценить влияние варианта промпта на качество, полноту и структуру отчётов, выявить ключевые отличия и сформулировать вывод о применимости каждого подхода.

1. Сравнительный анализ отчётов

1.1. Структура и полнота разделов

Оба отчёта следуют заданной структуре, но с разной степенью детализации.

Различия по разделам:

• Общая информация
• result-1.txt: полная (ОС, CPU, RAM, диски, параметры PostgreSQL)
• result-2.txt: полная (аналогично)
• 1. Общий анализ SPEED и WAITINGS
• result-1.txt: граничные значения, тренды с R² и углами, регрессия
• result-2.txt: граничные значения, тренды с R² и углами, регрессия
• 1.1 Статистический анализ ожиданий
• result-1.txt: корреляция с общими ожиданиями, ВКО, R², интегральный приоритет
• result-2.txt: корреляция, ВКО, R², интегральный приоритет
• 1.2 Трендовый анализ vmstat
• result-1.txt: procs_r, procs_b, cpu_wa, cpu_id с R², углами, коэффициентами тренда
• result-2.txt: аналогично, но без коэффициента тренда (только угол)
• 1.3 Статистический анализ ожиданий и vmstat
• result-1.txt: детальный — корреляции IPC/IO/LWLock с cs/in/sy/bi/bo/swap, плюс относительные показатели vmstat (% времени с r>ядер, RAM<5%, wa>10% и т.д.), плюс анализ IO (hit ratio, корреляции SPEED с блоками, dirty pages с bo, dirty pages с sy), плюс vm.dirty отдельным блоком
• result-2.txt: сокращённый — корреляции IPC/IO/LWLock с теми же метриками, плюс относительные показатели vmstat, плюс анализ IO, но без отдельного блока vm.dirty (данные встроены)
• 1.4 Диаграммы Парето
• result-1.txt: полные данные по wait_event_type и queryid
• result-2.txt: полные данные по wait_event_type и queryid
• Детальный анализ (границы и корреляции)
• result-1.txt: выделен отдельным блоком после 1.4
• result-2.txt: встроен в раздел 1 (фактически дублирует 1.3)
• 2. Анализ IO
• result-1.txt: развёрнутый — список устройств, граничные значения (мин/медиан/макс), относительные показатели (%util>50%, r_await>5мс, aqu_sz>1 и т.д.)
• result-2.txt: сокращённый — есть список устройств, граничные значения, относительные показатели, но менее детализированные комментарии
• 2.1 Сравнительный анализ vmstat и iostat
• result-1.txt: полный — 2.1.1–2.1.4 с итогами по каждому подразделу, CPI (индекс приоритета корреляции)
• result-2.txt: урезанный — те же подразделы, но без явного CPI для vdd (только для vdc), итоги короче
• Проблемы инфраструктуры
• result-1.txt: вынесены отдельно в конце раздела 2
• result-2.txt: вынесены отдельно в конце раздела 2
• 3. Итог
• result-1.txt: 3.1 Ключевые проблемы, 3.2 Проблемы СУБД, 3.3 Проблемы инфраструктуры
• result-2.txt: аналогично
• 4. Заключение
• result-1.txt: есть, плюс перечень недостающих данных для углублённого анализа
• result-2.txt: есть, но без перечня недостающих данных

Вывод по структуре:

Промпт-1 обеспечивает более строгое следование детализированной структуре с явным выделением подразделов (2.1.1–2.1.4) и дополнительным блоком «недостающих данных». Промпт-2 местами объединяет или сокращает подразделы, но общая схема соблюдена.

1.2. Детализация численных метрик и статистических выводов

1.2.1. Трендовый анализ (раздел 1.2)

• procs_r
• result-1.txt: R²=0.81, угол=+42.02, коэффициент тренда=34.11
• result-2.txt: R²=0.81, угол=+42.02, коэффициент тренда отсутствует
• cpu_wa
• result-1.txt: R²=0.89, угол=–43.38, коэффициент тренда= –38.74 (шум)
• result-2.txt: R²=0.89, угол=–43.38, без коэффициента
• cpu_id
• result-1.txt: R²=0.79, угол=–41.69, коэффициент тренда=33.07
• result-2.txt: R²=0.79, угол=–41.69, без коэффициента

Отличие:

Промпт-1 требует вычисления «коэффициента тренда» (скорости изменения в единицах метрики за период), что даёт дополнительную информацию о magnitude изменений. Промпт-2 ограничивается углом наклона (в условных единицах).

1.2.2. Статистический анализ ожиданий (раздел 1.1)

Оба отчёта содержат:

• Корреляцию каждого wait_event_type с общими WAITINGS (r)
• ВКО (взвешенную корреляцию ожиданий)
• R²
• Интегральный приоритет (IPC=0.8482, IO=0.4101, LWLock=0.3514)

Различий нет — оба промпта требуют этих расчётов.

1.2.3. Корреляционный анализ ожиданий и vmstat (раздел 1.3)

• IPC vs sy
• result-1.txt: r=0.9379, R²=0.88
• result-2.txt: r=0.9379, R²=0.88
• IO vs bi
• result-1.txt: r=0.9031, R²=0.82
• result-2.txt: r=0.9031, R²=0.82
• LWLock vs swap out
• result-1.txt: r=0.8044, R²=0.65
• result-2.txt: r=0.8044, R²=0.65
• Дополнительно в result-1.txt
• Анализ vm.dirty: dirty pages vs bo (r=0.8009, R²=0.64), dirty pages vs sy (r=0.6562, R²=0.43) — выделен отдельным блоком
• result-2.txt: vm.dirty встроен в анализ IO — данные есть, но без отдельного подраздела

Отличие:

Промпт-1 явно выделяет анализ vm.dirty в отдельный блок, что делает его более заметным.

1.2.4. Анализ IO (раздел 2)

Относительные показатели iostat (процент времени превышения порогов):

• vdd %util >50%
• result-1.txt: 100% времени — ALARM
• result-2.txt: 100% времени — ALARM
• vdd r_await >5ms
• result-1.txt: 10.5% времени — OK
• result-2.txt: 10.49% времени — OK
• vdd aqu_sz >1
• result-1.txt: 100% времени — ALARM
• result-2.txt: 100% времени — ALARM
• vdc %util >50%
• result-1.txt: 100% времени — ALARM
• result-2.txt: 100% времени — ALARM

Различий нет — оба отчёта фиксируют одни и те же пороговые значения.

1.2.5. Сравнительный анализ vmstat и iostat (раздел 2.1)

• 2.1.1 Корреляция vmstat и iostat
• Оба отчёта: wa vs util для vdd r=0.2194 (слабая), для vdc r=0.5522 (умеренная)
• 2.1.2 Буферизация
• Оба: buff vs wps на vdc r=0.5547, R²=0.31
• 2.1.3 Кэширование
• Оба: cache vs rps на vdd r=0.4702, R²=0.22
• 2.1.4 Корреляция SPEED и метрик диска
• Оба: SPEED vs MBps на vdd r=0.1568 (слабая), на vdc r=0.2344 (слабая)
• Индекс приоритета корреляции (CPI)
• result-1.txt: перечислены сильные корреляции (CPI >0.8) — cs vs in (0.980), dirty blocks vs bo (0.948), IPC vs sy (0.915) и т.д. — всего 8 пар
• result-2.txt: CPI приведён только для двух пар: buff vs wps на vdc (0.5561) и wa vs util на vdc (0.0000). Остальные сильные корреляции не включены в раздел 2.1 (хотя они есть в разделе 1.3)

Ключевое отличие:

Промпт-1 требует вычисления CPI для всех значимых пар и вынесения их в отдельный блок внутри раздела 2.1. Промпт-2 этого не делает.

1.3. Наличие дополнительных аналитических элементов

• Перечень недостающих данных (в заключении)
• result-1.txt: есть (планы запросов, размеры объектов, pg_stat_bgwriter, сетевая статистика)
• result-2.txt: отсутствует
• Оценка границ применимости данных
• result-1.txt: есть (например, «модель бесполезна», «непригодная модель»)
• result-2.txt: есть, но реже
• Проверка внутренней согласованности метрик
• result-1.txt: есть (например, «корреляция cs и in — математическая зависимость, не новое открытие»)
• result-2.txt: отсутствует
• Предупреждение о ложных корреляциях
• result-1.txt: есть (например, «Timeout исключён, так как ВКО≈0»)
• result-2.txt: есть (аналогично)
• Светофоры (🟢🟡🔴)
• result-1.txt: отсутствуют (не требовались промптом)
• result-2.txt: отсутствуют (INSTRUCTION_v10.2.md требует, но в отчёте их нет — вероятно, режим не активирован)

Вывод:

Промпт-1 требует явного указания границ применимости и проверки внутренней согласованности — эти элементы присутствуют. Промпт-2, следуя INSTRUCTION_v10.2.md, должен бы добавлять светофоры, но в сгенерированном отчёте их нет.

2. Причины различий

2.1. Роль prompt-1.txt

prompt-1.txt — это специализированный, детерминированный промпт эксперта по производительности PostgreSQL. Он содержит:

• Чёткие требования к формату отчёта (списки, структура)
• Конкретные метрики для анализа (R², углы трендов, коэффициенты тренда, ВКО, CPI)
• Правила проверки внутренней согласованности (например, не делать вывод о критичности, если одна метрика является частью другой)
• Требование указывать границы применимости и недостающие данные
• Запрет на домыслы и общие фразы

Результат:

Отчёт получается максимально полным, технически точным, с явными численными обоснованиями каждого вывода.

2.2. Роль INSTRUCTION_v10.2.md + prompt-2.txt

INSTRUCTION_v10.2.md — это универсальная инструкция для агента, определяющая персоны, режимы, эпистемические протоколы (светофоры, CoVe, ToT, Red Teaming и т.д.). Она не содержит предметных знаний о PostgreSQL. prompt-2.txt — это сокращённый вариант промпта для формирования отчёта, который лишь задаёт структуру и запрещает рекомендации, но не требует вычисления коэффициентов тренда, CPI, проверки согласованности и т.д.

Результат:

Агент, следуя INSTRUCTION, применяет общие протоколы честности, но не углубляется в специфику анализа производительности БД. Отчёт получается менее детализированным, некоторые важные аналитические элементы (коэффициент тренда, отдельный блок vm.dirty, перечень недостающих данных, CPI для сильных корреляций) отсутствуют или урезаны.

2.3. Ключевые отличия в промптах

• Специализация
• prompt-1.txt: высокая (только PostgreSQL)
• prompt-2.txt: низкая (общая структура)
• Требование к расчёту коэффициента тренда
• prompt-1.txt: есть
• prompt-2.txt: нет
• Требование к явному блоку vm.dirty
• prompt-1.txt: есть
• prompt-2.txt: нет
• Требование к перечню недостающих данных
• prompt-1.txt: есть
• prompt-2.txt: нет
• Требование к проверке внутренней согласованности
• prompt-1.txt: есть
• prompt-2.txt: нет
• Требование к CPI в разделе 2.1
• prompt-1.txt: есть (отдельный блок)
• prompt-2.txt: нет
• Наличие эпистемических протоколов (светофоры и т.д.)
• prompt-1.txt: нет (не требуется)
• prompt-2.txt: есть (INSTRUCTION), но в отчёте не применены

3. Итоговый вывод о применимости

3.1. Применимость prompt-1.txt

Рекомендуется для:

Формирования глубокого, технически точного, аудиторского отчёта по производительности PostgreSQL, где требуется максимальная полнота анализа, численные обоснования каждого вывода, проверка согласованности метрик и явное указание границ применимости.

Сильные стороны:

• Высокая детализация (коэффициент тренда, CPI, vm.dirty, недостающие данные)
• Строгая проверка логических связей (нет ложных корреляций)
• Профессиональная терминология с единицами измерения
• Чёткое разделение на подразделы

Слабые стороны:

• Не использует эпистемические протоколы (светофоры, CoVe) — но для технического отчёта это не критично
• Требует, чтобы все необходимые метрики были заранее рассчитаны во входных данных

3.2. Применимость INSTRUCTION_v10.2.md + prompt-2.txt

Рекомендуется для:

Быстрого формирования обзорного, структурно корректного отчёта в условиях, когда полнота не является приоритетом, а важнее соблюдение общих протоколов честности (светофоры, проверка источников) и адаптивность к разным доменам.

Сильные стороны:

• Универсальность (подходит для любых предметных областей)
• Встроенные механизмы против галлюцинаций (CoVe, Red Teaming — хотя в отчёте не видны)
• Возможность переключения персоны и режимов

Слабые стороны:

• Недостаточная детализация для глубокого анализа производительности БД
• Отсутствие специфических для PostgreSQL требований (коэффициент тренда, CPI, vm.dirty, недостающие данные)
• В текущей реализации светофоры не были применены (вероятно, из-за отсутствия явного указания в prompt-2.txt или неактивированного режима)

3.3. Финальная рекомендация

Для задачи «анализ производительности PostgreSQL по результатам нагрузочного тестирования с формированием сводного отчёта»:

• Использовать prompt-1.txt как основной промпт — он даёт более качественный, полный и пригодный для принятия решений отчёт.
• Дополнить prompt-1.txt элементами из INSTRUCTION_v10.2.md (например, светофорами для указания уверенности в выводах) — это повысит прозрачность без потери детализации.
• INSTRUCTION_v10.2.md + prompt-2.txt недостаточны для этой задачи без существенной доработки prompt-2.txt в сторону добавления требований к расчёту специфических метрик (коэффициент тренда, CPI, vm.dirty, недостающие данные).

Ключевой вывод:

Специализированный промпт эксперта по производительности (prompt-1.txt) обеспечивает превосходное качество анализа по сравнению с универсальной инструкцией, даже если последняя дополнена эпистемическими протоколами.

Послесловие

Проведённое сравнение наглядно демонстрирует, что при анализе специфичных данных нагрузочного тестирования СУБД полнота и глубина отчёта критически зависят от наличия предметно-ориентированных правил в промпте.

Универсальные мета-инструкции, даже с мощными эпистемическими протоколами, не заменяют доменной методологии (PG_EXPECTO) — они могут лишь дополнять её.

Таким образом, для получения воспроизводимого, верифицируемого и практически применимого отчёта по производительности PostgreSQL целесообразно использовать самодостаточный промпт, а при необходимости — надстраивать поверх него механизмы контроля достоверности, но не подменять ими содержательную аналитику.