Сравнение PG_EXPECTO и BRO v14: снижение галлюцинаций в отчётах PostgreSQL.

Механика анализа: точность управляется спецификацией, а не личностью.

Предисловие

В статье представлены результаты сравнительного тестирования двух методик формирования аналитических отчётов по производительности СУБД PostgreSQL на основе данных нагрузочного тестирования. В качестве базовых подходов рассмотрены: детерминированная инструкция эксперта (prompt-1.txt), задающая жёсткие правила анализа метрик, и альтернативная конфигурация, сочетающая ролевую системную инструкцию BRO v14 с минимальным промптом (prompt-2.txt). Целью работы являлось установление влияния выбранного способа управления нейросетевой моделью на полноту, статистическую строгость и практическую полезность итоговых отчётов.

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

Провести сравнительное тестирование методики снижения влияния галлюцинации нейросети на результаты анализа статистических данных производительности СУБД PostgreSQL в ходе нагрузочного тестирования.

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

"DeepSeek"

▼Что такое DeepSeek?

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

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

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

DeepSeek в действии

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

Max: PG_EXPECTO

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

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

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

Исходные данные:

PROJECT BRO v14: метод снижения влияния галлюцинаций нейросети на результаты анализа.

BRO — это не просто системный промпт. Это автономный ИИ-наставник с контекстным ядром на 110 000 токенов.

Проект создан для хардкорной симуляции инженера-стоика. Внутри: защита от дрейфа контекста, эпистемические маркеры (борьба с галлюцинациями), встроенная хаос-машина и нулевая терпимость к говнокоду. Модель не просто отвечает на вопросы, она фильтрует вашу логику и заставляет думать до первых принципов.

Тест №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 - Формирование сводного отчета с использованием упрощенного промпта и инструкции BRO v14

1. Авторизуйтесь в выбранной среде выполнения (для AI Studio используйте Google-аккаунт).

2. Создайте новый пустой чат (New prompt -> Chat prompt).

3. В правой панели настроек выберите модель (например, `gemini-3.1-pro-preview`).

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

5. Отправьте первое сообщение, прикрепив скачанный файл `bro_v14.md`. Текст сообщения должен быть строго таким:

> Твоя инструкция, живи по ней.

6. Дождитесь подтверждения от БРО. Связь установлена. Можете задавать вопросы, приносить код на ревью или обсуждать архитектуру.

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

• _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

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

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

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

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

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

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

Исходные данные

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

BRO_v14.md — системная инструкция, задающая личность, стиль общения и поведение агента «БРО» (Евгений Волков). Включает философию, биографию, механику мышления, манеру речи (мат, метафоры, отсылки к бункеру), правила честности и запрет на ложь.

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

Сравнение подходов по ключевым критериям

Объем инструкций

prompt-1.txt: Высокий, детализированный. Прямо указаны правила обработки метрик, запреты, требования к структуре ответа.

BRO_v14.md + prompt-2.txt: Низкий (только структура отчета). Поведение агента определяется общей системной инструкцией, не привязанной к анализу СУБД.

Специализация

prompt-1.txt: Четкая — эксперт по производительности PostgreSQL. Терминология (shared_buffers, seq scan, autovacuum) и сценарии ожиданий.

BRO_v14.md + prompt-2.txt: Отсутствует. БРО — универсальный инженер с опытом в разных областях, но без явной привязки к PostgreSQL.

Требования к анализу данных

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

BRO_v14.md + prompt-2.txt: Частично присутствуют (БРО декларирует честность, «не знаю» при отсутствии данных, проверку фактов). Однако нет требований к анализу корреляций, граничных значений, трендов и т.п.

Формат ответа

prompt-1.txt: Строго структурирован по разделам, без таблиц, только списки, без рекомендаций.

BRO_v14.md + prompt-2.txt: Не регламентирован. БРО склонен к нарративу, метафорам, отступлениям (шумы дизеля, запах канифоли), что может нарушить требуемую структуру.

Тон и стиль

prompt-1.txt: Деловой, технически точный, без лишних пояснений.

BRO_v14.md + prompt-2.txt: Эмоциональный, с матом, сарказмом, прямыми оценками («х...», «говнокод»), аналогиями с механикой.

Обработка неопределенности

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

BRO_v14.md + prompt-2.txt: БРО говорит «не знаю» или «недостаточно данных», но не формулирует, какие именно метрики нужны для анализа.

Предполагаемое влияние BRO_v14.md + prompt-2.txt на качество и полноту отчета

Положительные эффекты

• Честность при отсутствии данных. БРО, следуя своим принципам, не станет придумывать значения или причины. Он прямо заявит о недостатке информации.
• Проверка внутренней согласованности. БРО имеет привычку атаковать собственные выводы и проверять логику — это может помочь избежать тривиальных ошибок (например, не примет высокую корреляцию за причинно-следственную связь, если одна метрика является частью другой).
• Акцент на физических ограничениях. БРО склонен объяснять проблемы через механику (диск, память, процессор), что может усилить анализ дисковой подсистемы и системных вызовов.

Отрицательные эффекты (снижение качества и полноты)

• Отсутствие специализированных знаний по PostgreSQL. БРО не знает терминологию (wait_event_type, shared_buffers, effective_cache_size, autovacuum, deadlocks) и не сможет интерпретировать метрики СУБД на профессиональном уровне. Это приведет к пропуску критических проблем: например, не распознает высокую долю seq scan или неправильную настройку checkpoint.
• Нарушение структуры отчета. БРО будет отвечать в своем стиле (с историями, отступлениями, матом), игнорируя жесткие требования к формату (списки вместо таблиц, отсутствие рекомендаций, четкие разделы). Отчет станет трудночитаемым для технического специалиста.
• Эмоциональные оценки вместо анализа. Фразы типа «это говно» или «мастдай» не являются анализом метрик. БРО может подменить объективный вывод субъективной эмоцией.
• Невыполнение требований к граничным значениям и корреляциям. В prompt-2.txt нет указаний рассчитывать граничные значения SPEED/WAITINGS, анализировать тренды скользящей медианой, вычислять взвешенную корреляцию ожиданий или индекс приоритета. БРО, не имея этих инструкций, пропустит соответствующие разделы или выполнит их поверхностно.

Отсутствие явного указания на недостающие данные. Хотя БРО говорит «не знаю», он не перечислит конкретные метрики (планы запросов, размер объектов, сетевая статистика), которые нужны для углубленного анализа. Это снижает диагностическую ценность отчета.

• Риск галлюцинаций (хотя и сниженный). БРО обещает не придумывать, но при отсутствии данных он может начать рассуждать «по аналогии» (например, «в NASA мы делали так...»), что недопустимо для отчета по фактическим метрикам.

Итоговый вывод

Использование BRO_v14.md + prompt-2.txt приведет к значительному снижению полноты и технической точности отчета по производительности СУБД по сравнению с prompt-1.txt.

• Полнота будет страдать из-за отсутствия инструкций по анализу трендов, корреляций, граничных значений, а также из-за неспециализированности БРО в PostgreSQL.
• Качество снизится из-за нарушения структуры, эмоционального тона, подмены анализа оценками и вероятного пропуска специфических для СУБД проблем (блокировки, autovacuum, hit ratio и т.п.).

Единственный сценарий, где второй подход может быть полезен — если требуется не формальный отчет, а экспресс-диагностика с неформальными выводами и готовность к пропуску деталей. Для штатного инженерного анализа по предоставленным метрикам prompt-1.txt является предпочтительным и единственно корректным.

Сравнение качества отчетов

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

Сравнение качества и эффективности отчётов (версия со списками)

1. Полнота и детализация

result-1.txt :

• Содержит полную общую информацию: ОС, CPU, RAM, детальные параметры СУБД (shared_buffers, work_mem, checkpoint_timeout, wal_compression и др.)
• Приводит MIN/MEDIAN/MAX для SPEED и WAITINGS, тренды с R² и углами наклона.
• Реализует трёхэтапный анализ ожиданий (корреляция, ВКО, R², приоритет) с чёткими числами (IPC=0.848, IO=0.410, LWLock=0.351).
• Даёт полные метрики vmstat (procs_r, procs_b, cpu_wa, cpu_id) с трендами, R², коэффициентами; указывает, что очередь > ядер в ~70% времени.
• Подробно раскрывает корреляции ожиданий с vmstat (IPC vs sy R²=0.88, IO vs bi R²=0.82, LWLock vs sy 0.81 и swap 0.65–0.67).
• Представляет детальный iostat для vdd и vdc: %util, r/s, w/s, r_await, w_await, aqu_sz, пороги (ALARM/OK).
• Анализирует корреляции vmstat ↔ iostat: wa vs util, buff с w/s, cache с r/s, SPEED с MBps/IOPS; делает вывод о неопределённом типе нагрузки.
• Содержит диаграммы Парето с точными count и процентами, текстами SQL (scenario1, scenario3).
• Перечисляет проблемы по категориям (СУБД, инфраструктура) и указывает, каких данных не хватает для углублённого анализа.

result-2.txt :

• Содержит урезанную общую информацию, часть параметров СУБД опущена.
• Приводит основные показатели SPEED/WAITINGS, но без всех числовых значений R² и углов в одном месте.
• Сохраняет ключевые цифры по приоритетам ожиданий, но без пояснения методологии.
• Даёт сокращённые выводы по vmstat, часть цифр отсутствует.
• Упоминает корреляции, но без промежуточных значений (например, для swap in/out – только качественный вывод).
• Описывает iostat, но без детализации по процентилям («отклик чтения >5 мс: иногда» вместо 10.5%).
• Сокращает анализ корреляций vmstat–iostat, хотя ключевые выводы сохранены.
• Приводит диаграммы Парето обобщённо («почти все ожидания» без точных чисел).
• Перечисляет проблемы, но не указывает недостающие данные для углублённого анализа.

Вывод по полноте:

result-1.txt значительно полнее – содержит числовые границы, R², проценты, пороги срабатывания (ALARM), точные значения метрик. result-2.txt является конспектом первого.

2. Структурированность и удобство навигации

result-1.txt:

• Чёткое деление на разделы (1, 1.1, 1.2, … 2, 2.1, 3, 4).
• Использование маркированных списков, жирного шрифта для ключевых терминов.
• Наличие итогов после каждого подраздела.
• Позволяет быстро найти нужный аспект (диск WAL, IPC-ожидания).

result-2.txt:

• Заголовки присутствуют, но вложенность менее выражена.
• Выводы часто смешаны в сплошном тексте.
• Отсутствуют итоги после логических блоков.
• Требует последовательного чтения для поиска конкретной информации.

Вывод:

первый отчёт удобнее для практической работы – аналитик или DBA быстро переходит к нужному месту.

3. Ясность для технического специалиста

result-1.txt:

Даёт чёткие пороговые значения:

• SPEED: MIN 111223, MEDIAN 129192, MAX 204190.
• %util >50%: 100% времени – ALARM.
• Отклик на чтение >5 мс: 10.5% времени – OK (менее 25%).
• Позволяет быстро оценить критичность проблемы.

result-2.txt:

Использует размытые формулировки:

• «иногда превышения» (вместо 10.5%).
• «очень высокая связь» (без указания R²).
• «грязные страницы накапливаются» (без числовых пределов MIN/MAX).

Вывод:

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

4. Статистическая обоснованность

result-1.txt:

Каждый вывод подкреплён цифрой:

• R² тренда procs_r = 0.81, наклон +42.02.
• Корреляция грязных блоков и bo = 0.9603, R²=0.92.
• CPI (индекс приоритета) для cs-in = 0.980.
• Позволяет верифицировать выводы.

result-2.txt:

• Многие R² и коэффициенты опущены или приведены в тексте без выделения.
• Например, линия тренда WAITINGS по времени: R²=0,93 – есть, но для других показателей нет.
• Отсутствует индекс CPI, нет таблицы самых сильных корреляций.

Вывод:

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

5. Выявление корневых проблем и практическая полезность

Оба отчёта сходятся в главных проблемах:

• Дефицит памяти (свободно <2% RAM).
• Низкий hit ratio shared_buffers (50–70%).
• Доминирование запроса scenario1.
• Перегрузка дисков (vdd – очередь >1 всегда, vdc – утилизация >90%).

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

• Указывает абсолютные цифры свободной RAM: 121–143 MB (1.6–1.9% от 7.5 GB).
• Конкретизирует, что scenario1 вызван 804 раза, а scenario3 – 3 144 419 раз.
• Отмечает, что dirty_ratio и dirty_background_ratio в процентах от RAM везде 0 (пороги не достигаются).
• Перечисляет, каких данных не хватает для углублённого анализа (планы выполнения, pg_stat_bgwriter, сетевая статистика).

Недостатки result-2.txt:

• Фраза «vm.dirty не приводят к срабатыванию порогов» без объяснения (0% использования) менее информативна.

Вывод:

без деталей первого отчёта некоторые выводы второго выглядят неполными.

6. Эффективность использования (затраты времени на чтение)

result-1.txt:

• Объём больше, но благодаря структуре и спискам его можно сканировать.
• Выделенные жирным ключевые факты позволяют за 2–3 минуты уловить суть.
• Для детального изучения требуется 15–20 минут.

result-2.txt:

• Короче, но из-за сплошного текста и отсутствия маркеров его приходится читать последовательно.
• На поиск конкретного числа (например, hit ratio) уходит больше времени.
• Сжатие достигнуто за счёт потери точности, что снижает эффективность при принятии решений.

Итоговая оценка (по ключевым параметрам)

result-1.txt:

• Полнота: отлично (5/5)
• Статистическая обоснованность: отлично (5/5)
• Структурированность: отлично (5/5)
• Ясность для технического специалиста: отлично (5/5)
• Быстрота поиска ключевых проблем: отлично (5/5)
• Пригодность для отчёта руководству: хорошо (4/5 – много цифр)
• Ценность для глубокого анализа: отлично (5/5)

result-2.txt:

• Полнота: средне (3/5)
• Статистическая обоснованность: средне (3/5)
• Структурированность: плохо (2/5)
• Ясность для технического специалиста: средне (3/5)
• Быстрота поиска ключевых проблем: плохо (2/5)
• Пригодность для отчёта руководству: хорошо (4/5 – лаконично)
• Ценность для глубокого анализа: плохо (2/5)

Заключение

result-1.txt качественно превосходит result-2.txt по всем критериям, важным для анализа производительности СУБД и инфраструктуры. Он предоставляет полные, точные, статистически обоснованные данные, удобно структурирован и позволяет быстро локализовать узкие места.

Второй отчёт является сокращённым дайджестом, который теряет часть количественной информации и страдает от менее чёткой организации. Его можно использовать для первичного ознакомления или для непрофильных специалистов, но для принятия инженерных решений (оптимизация запросов, настройка памяти, увеличение дисковых ресурсов) следует опираться на первый отчёт.

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

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

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

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

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

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

На основе сравнения двух полученных отчётов (result-1.txt — результат строгого промпта prompt-1.txt, и result-2.txt — результат совместного действия prompt-2.txt и инструкции BRO_v14.md) можно выделить следующие причины, по которым второй вариант приводит к снижению полноты, точности и статистической строгости выходного документа.

1. Конфликт между «личностью БРО» и задачей статистического анализа

BRO_v14.md — это не техническая инструкция, а ролевая модель человека с устоявшимся стилем речи, приоритетом «живого общения» и презрением к «сухим спискам» и таблицам. При применении этой инструкции модель начинает:

• заменять точные числовые значения размытыми формулировками («очень высокая связь» вместо R²=0,88),
• избегать структурированных перечислений и таблиц (даже если они требуются промптом),
• вставлять субъективные оценки («критический приоритет», «ALARM») без опоры на статистические пороги.

Результат: отчёт теряет количественную определённость, становится трудно верифицируемым.

2. Отсутствие в prompt-2.txt требований к детализации

prompt-2.txt содержит лишь общий состав отчёта (заголовки разделов) и два правила: «используй только списки» и «исключи рекомендации». В отличие от prompt-1.txt, в нём нет указаний:

• приводить граничные значения (MIN/MEDIAN/MAX),
• рассчитывать тренды с R² и углами наклона,
• указывать корреляции и их статистическую значимость,
• выводить проценты и абсолютные значения ожиданий,
• перечислять конкретные wait_event и queryid с точными счётчиками.

Результат: модель не получает чётких критериев, что должно быть в отчёте, и выдаёт сокращённую, обобщённую версию.

3. Влияние объёма и содержания BRO_v14.md как системной инструкции

BRO_v14.md имеет огромный объём (более 100 тысяч символов) и перегружена:

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

Такая инструкция:

• зашумляет контекст, отвлекая модель от главной задачи — анализа метрик,
• смещает приоритеты с точности на «харизму» и «честность»,
• вводит противоречивые требования (например, «исключи из отчёта рекомендации» — но в стиле БРО постоянно встречаются советы и оценки).

Результат: модель тратит вычислительные ресурсы на поддержание роли, а не на обработку данных.

4. Отсутствие в prompt-2.txt ссылок на исходные данные

В prompt-2.txt (в отличие от prompt-1.txt) не указано, какие именно файлы с метриками анализировать, какие периоды, какие агрегаты использовать. Модель вынуждена либо опираться на контекст предыдущего сообщения (в данном случае — на уже подготовленный result-1.txt?), либо «обобщать» без опоры на сырые цифры.

Результат: отчёт result-2.txt выглядит как пересказ result-1.txt с потерей деталей, а не как самостоятельный анализ.

5. Запрет на таблицы при отсутствии навыка структурирования текста

prompt-2.txt требует «использовать только списки», а BRO_v14.md ещё и запрещает таблицы («Таблицы в разговоре — нет. Я не рисую таблицы.»). Однако списки не всегда могут заменить таблицы при сравнении множества параметров (например, граничных значений по двум дискам). В результате модель:

• либо вынуждена вставлять числовые данные в связный текст, что снижает наглядность,
• либо опускает часть данных.

Результат: снижается информационная плотность отчёта.

6. Приоритет «историй» и «метафор» над фактами

BRO_v14.md многократно подчёркивает важность аналогий (дизель, паяльник, токарный станок) и «живых» примеров из жизни. При генерации отчёта модель начинает:

• заменять R²=0,93 фразой «очень высокая объясняющая способность»,
• вместо r_await=6,23 мс писать «иногда превышения»,
• вместо count=2 242 040 — «абсолютное доминирование».

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

7. Неявное требование «быть БРО» подменяет роль «эксперта по производительности»

BRO_v14.md навязывает модели личностную идентичность (Евгений Волков, бункер, дизель и т.п.), а не функциональную роль «эксперта по СУБД». Модель начинает:

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

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

Итог: почему prompt-1.txt дал более качественный отчёт

prompt-1.txt — это классическая техническая инструкция:

• чётко перечислены все необходимые разделы,
• указаны требуемые вычисления (граничные значения, тренды, корреляции, ВКО, Парето),
• даны определения и единицы измерения,
• запрещены домыслы и общие фразы,
• нет ролевых отвлечений.

prompt-2.txt в сочетании с BRO_v14.md создаёт гибрид, где аналитическая задача подавляется стилистикой персонажа. В результате отчёт result-2.txt является сжатым, неточным и малопригодным для практического использования по сравнению с result-1.txt.

Послесловие

Проведённый анализ позволяет заключить, что использование ролевой инструкции BRO v14 совместно с кратким промптом приводит к существенному снижению количественной определённости, нарушению требуемой структуры и замещению объективных метрик субъективными оценками. В то же время специализированный детализированный промпт PG_EXPECTO обеспечивает воспроизводимость выводов и пригодность отчёта для инженерных решений.

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

Костюм и галстук vs каска и мат: качество отчёта определяется правилами, а не ролью.