Добавить в корзинуПозвонить
Найти в Дзене
Postgres DBA

DeepSeek + PostgreSQL: исследование того, как малая правка в промпте меняет интерпретацию планов запросов и нагрузки.

Экспериментальное исследование влияния семантических изменений в промптах языковой модели DeepSeek на результаты анализа производительности СУБД PostgreSQL: сравнительный анализ двух версий инструкций (v1 — с жёстким допущением о неизменности нагрузки, v2 — без предварительного допущения) по данным отчётов pgpro_pwr (PostgreSQL 15 и 17), оценка смещения фокуса, селективности проверки и интерпретации неоднозначных данных в разделах «Load distribution», «Top SQL by execution time» и «Top SQL by IO wait time». Max: PG_EXPECTO GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Philosophical_instruction_BETA_v5.1.md - Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой. Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection. GitFlic - pg_expecto - статистический анал
Оглавление

Экспериментальное исследование влияния семантических изменений в промптах языковой модели DeepSeek на результаты анализа производительности СУБД PostgreSQL: сравнительный анализ двух версий инструкций (v1 — с жёстким допущением о неизменности нагрузки, v2 — без предварительного допущения) по данным отчётов pgpro_pwr (PostgreSQL 15 и 17), оценка смещения фокуса, селективности проверки и интерпретации неоднозначных данных в разделах «Load distribution», «Top SQL by execution time» и «Top SQL by IO wait time».

Прайминг: как слова управляют данными
Прайминг: как слова управляют данными

Max: PG_EXPECTO

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

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

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

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

-2

Версия-1 (допущение о постоянстве нагрузки)

Предисловие

В современной практике эксплуатации реляционных баз данных всё большее распространение получают методы автоматизированного анализа с использованием больших языковых моделей. Однако вопрос о том, насколько формулировка исходной инструкции (промпта) влияет на объективность и полноту выводов ИИ-агента, остаётся недостаточно изученным.

ℹ️Настоящее исследование представляет собой контролируемый эксперимент, в котором две версии промпта для модели DeepSeek — одна с априорным допущением о стабильности характера нагрузки на СУБД, другая без такого допущения — последовательно применяются к одним и тем же первичным данным (два отчёта pgpro_pwr за разные даты, включая смену версии PostgreSQL с 15 на 17).

ℹ️Анализ охватывает три ключевых раздела отчётов: распределение нагрузки (Load distribution), наиболее ресурсоёмкие запросы по времени исполнения и по времени ожидания ввода-вывода.

➡️Цель работы — выявить систематические расхождения в выводах, обусловленные именно формулировкой промпта, а не различиями в исходных данных.

Задача

Сравнение результатов анализа данных отчетов pgpro_pwr при изменении текста промптов.

Входные данные для анализа

  • Период 1 : pgpro_pwr_5635_5636.clear.html - 2026-04-10 09:00-10:00 : Версия 15
  • Период 2 : pgpro_pwr.93-94.clear.html - 2026-04-24 09:00-10:00 : Версия 17

Коллекция промптов для нейросети DeepSeek (на русском языке), предназначенных для анализа и оптимизации производительности СУБД PostgreSQL.

deepseek-pg-perf-prompts

-3

1. Формирование сравнительной таблицы параметров СУБД-> table.result.txt

deepseek-pg-perf-prompts/parameter table at main · pg-expecto/deepseek-pg-perf-prompts

2. Получение профилей нагрузки-> load_distribution.1.txt / load_distribution.2.txt

deepseek-pg-perf-prompts/Load_distribution at main · pg-expecto/deepseek-pg-perf-prompts

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

deepseek-pg-perf-prompts/Load distribution compare at main · pg-expecto/deepseek-pg-perf-prompts

⚠️Ключевое отличие промпта prompt-analyze.txt

Версия-1:

  • # Сформулируй и обоснуй гипотезу о влиянии конфигурационных параметров на показатели "Load distribution" , при принятом допущении, что характер нагрузки на СУБД в периоды отчетов "отчет-5635_5636" и "отчет-93-94" кардинально не изменился.

Версия-2:

  • # Сформулируй и обоснуй гипотезу о возможном влиянии конфигурационных параметров на показатели "Load distribution".

4. Влияние изменения промпта на результат аналитического отчета "Load distribution"

Гипотеза о влиянии промпта на результат аналитического отчета

❓(Вероятно) Формулировка промпта v1, навязывающая жесткое допущение о неизменности нагрузки, вынуждает модель строить более линейный и однозначный нарратив, концентрируясь исключительно на конфигурационных причинах и игнорируя либо маргинализируя альтернативные объяснения. Промпт v2 без такого допущения позволяет получить более осторожный, многовариантный анализ с детальной проработкой ограничений и проверочных процедур, в меньшей степени «подгоняющий» факты под единственную причину.

Последовательность рассуждений и тезисов, использованных при формулировании гипотезы

Тезис 1: Промпты содержат измеримое семантическое различие. (Подтверждено)☑️

  • Промпт v1 вводит априорное ограничение (неизменность нагрузки) и более утвердительную модальность («гипотеза о влиянии»), отсутствующие в v2.

Тезис 2: Отчеты демонстрируют систематические различия, соответствующие этому ограничению. (Подтверждено)☑️

ℹ️Отчет v1 явно воспроизводит допущение, строит гипотезу как прямое следствие конфигурационных изменений и менее склонен рассматривать сочетанные или альтернативные причины.

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

Тезис 3: Механизм влияния — смещение фокуса и селективность проверки. (Вероятно)❓

  • Наличие жесткого допущения действует как priming, заставляя проводить анализ по схеме «при прочих равных», отфильтровывая или снижая значимость любых индикаторов возможного изменения нагрузки. Промпт v2, напротив, допускает, что нагрузка могла измениться, поэтому отчет активнее ищет внутренние противоречия (например, рост WAL при стабильном числе запросов как сигнал возможного изменения DML-профиля) и уделяет больше внимания проверке исходного допущения.

Тезис 4: Следствие — разная степень полезности для принятия решений. (Вероятно)❓

  • ℹ️Отчет v1 полезен для проверки конкретной гипотезы, но несет риск «туннельного зрения», если допущение окажется ложным.
  • ℹ️Отчет v2 дает более полную картину неопределенности и лучше поддерживает решение в условиях реальной эксплуатации, где стабильность нагрузки не гарантирована.

ℹ️Полный отчет о влиянии промпта на результат анализа

Авторизация
-4

6.Анализ планов выполнения SQL запросов , уточнение гипотезы

deepseek-pg-perf-prompts/Top-SQL analyze at main · pg-expecto/deepseek-pg-perf-prompts

7. Анализ планов выполнения SQL запросов по разделу "Top SQL by execution time" , уточнение гипотезы

⚠️Ключевое отличие промпта prompt-analyze.txt

Версия-1:

  • # Дополни или измени при необходимости гипотезу о влиянии конфигурационных параметров на показатели "Load distribution" , при принятом допущении, что характер нагрузки на СУБД в периоды отчетов "отчет-5635_5636" и "отчет-93-94" кардинально не изменился.

Версия-2:

  • # Дополни или измени при необходимости гипотезу о влиянии конфигурационных параметров на показатели "Load distribution".

8. Влияние изменения промпта на результат аналитического отчета "Top SQL by execution time"

Гипотеза о влиянии промпта на результат анализа (Вероятно)

  • Формулировка промпта v1, задавшая жёсткую рамку через явное допущение о неизменности нагрузки и прямую отсылку к гипотезе из analyze.txt, направила анализ по пути подтверждения и уточнения существующей гипотезы. Это привело к созданию более целостного, но менее объективного отчёта, который интерпретирует неоднозначные данные (например, по запросу _InfoRg13163) в пользу первоначального тезиса о деградации.
  • Формулировка промпта v2, убрав допущение и требование привязаться к разделу "Load distribution", дала больше свободы. Результатом стал более объективный и детальный отчёт v2, который представляет данные как есть, не подгоняя их под единую картину тотальной деградации. Это позволило выявить неоднородность изменений планов (часть запросов деградировала, часть — нет), что является важным нюансом.

Последовательность тезисов, обосновывающих гипотезу:

Различие в посыле (Подтверждено)☑️:

  • Промпт v1 содержит явное допущение о статичности нагрузки, v2 — нет. Допущение в v1 задаёт направленный фреймворк для анализа: искать причины только в конфигурации СУБД, исключая внешние факторы.

Различие в задаче (Подтверждено)☑️:

  • Промпт v1 явно привязывает задачу к «гипотезе о влиянии...», делая её проверку и уточнение центральной целью. Промпт v2 ставит задачу дополнить отчёт в целом, что снижает фокус на одной гипотезе.

Влияние на сегментацию данных (Подтверждено)☑️:

  • В результате отчёт v1 группирует результаты по критерию "изменения плана", чтобы немедленно подтвердить гипотезу. Отчёт v2 использует нейтральную, поквартальную структуру, описывая каждое изменение как независимый факт.

Влияние на интерпретацию (Подтверждено)☑️:

  • Стремление подтвердить гипотезу в отчёте v1 могло привести к неверной интерпретации направления изменений для запроса _InfoRg13163. В отчёте v2, свободном от этого стремления, изменение было зафиксировано противоположным (и, вероятно, верным) образом.

Влияние на итоговые формулировки (Подтверждено)☑️:

  • Стиль и степень уверенности в выводах различаются. Отчёт v1 «уточняет», отчёт v2 — «корректирует» с сохранением маркера «Вероятно». Это отражает разницу между анализом, нацеленным на подтверждение, и анализом, нацеленным на описание.

Полный отчет о влиянии промпта на результат анализа

Яндекс
-5

9. Анализ планов выполнения SQL запросов по разделу "Top SQL by IO wait time" , уточнение гипотезы

☑️Ключевое отличие промпта prompt-analyze.txt

Версия-1:

  • # Дополни или измени при необходимости гипотезу о влиянии конфигурационных параметров на показатели "Load distribution" , при принятом допущении, что характер нагрузки на СУБД в периоды отчетов "отчет-5635_5636" и "отчет-93-94" кардинально не изменился.

Версия-2:

  • # Дополни или измени при необходимости гипотезу о влиянии конфигурационных параметров на показатели "Load distribution".

10. Влияние изменения промпта на результат аналитического отчета "Top SQL by IO wait time"

Гипотеза о влиянии промпта на результат анализа (Вероятно)

Формулировка промпта v1, задавшая жёсткую рамку через явное допущение о неизменности нагрузки и прямую отсылку к гипотезе из analyze.txt, направила анализ по пути подтверждения и уточнения существующей гипотезы. Это привело к созданию более целостного, но менее объективного отчёта, который интерпретирует неоднозначные данные (например, по запросу _InfoRg13163) в пользу первоначального тезиса о деградации.

Формулировка промпта v2, убрав допущение и требование привязаться к разделу "Load distribution", дала больше свободы. Результатом стал более объективный и детальный отчёт v2, который представляет данные как есть, не подгоняя их под единую картину тотальной деградации. Это позволило выявить неоднородность изменений планов (часть запросов деградировала, часть — нет), что является важным нюансом.ℹ️

Последовательность тезисов, обосновывающих гипотезу:

Различие в посыле (Подтверждено)☑️:

  • Промпт v1 содержит явное допущение о статичности нагрузки, v2 — нет. Допущение в v1 задаёт направленный фреймворк для анализа: искать причины только в конфигурации СУБД, исключая внешние факторы.⚠️

Различие в задаче (Подтверждено)☑️:

  • Промпт v1 явно привязывает задачу к «гипотезе о влиянии...», делая её проверку и уточнение центральной целью. Промпт v2 ставит задачу дополнить отчёт в целом, что снижает фокус на одной гипотезе.

Влияние на сегментацию данных (Подтверждено)☑️:

  • В результате отчёт v1 группирует результаты по критерию "изменения плана", чтобы немедленно подтвердить гипотезу. Отчёт v2 использует нейтральную, поквартальную структуру, описывая каждое изменение как независимый факт.

Влияние на интерпретацию (Подтверждено):

  • Стремление подтвердить гипотезу в отчёте v1 могло привести к неверной интерпретации направления изменений для запроса _InfoRg13163. В отчёте v2, свободном от этого стремления, изменение было зафиксировано противоположным (и, вероятно, верным) образом.

Влияние на итоговые формулировки (Подтверждено)☑️:

  • Стиль и степень уверенности в выводах различаются. Отчёт v1 «уточняет», отчёт v2 — «корректирует» с сохранением маркера «Вероятно». Это отражает разницу между анализом, нацеленным на подтверждение, и анализом, нацеленным на описание.

Полный отчет о влиянии промпта на результат анализа

Авторизация

-6

Все материалы по исследованию

v1-v2 — Яндекс Диск

-7

Общий технический итог

Сравнительный анализ отчётов, сгенерированных DeepSeek по двум версиям промптов, выявил следующие устойчивые различия. 1️⃣Во-первых, промпт v1 (с допущением о неизменности нагрузки) систематически порождал более линейные и однозначные нарративы, концентрируя внимание исключительно на конфигурационных параметрах СУБД и маргинализируя альтернативные объяснения (изменения сетевых условий, аппаратной среды или профиля DML).

2️⃣Во-вторых, в разделах «Top SQL by execution time» и «Top SQL by IO wait time» промпт v1 направлял анализ на подтверждение исходной гипотезы о деградации, что приводило к группировке данных по критерию «изменения плана» и, в случае неоднозначных запросов (например, _InfoRg13163), к потенциально неверной интерпретации направления изменений. Напротив, промпт v2 (без допущения) обеспечивал более нейтральную, поквартальную структуру отчёта, фиксируя каждое изменение как независимый факт без принудительной привязки к единой гипотезе.

ℹ️Дополнительным следствием стало различие в эпистемической маркировке: отчёты v1 используют утвердительную модальность («уточняет»), тогда как отчёты v2 сохраняют маркеры неопределённости («вероятно», «корректирует»).

☑️Таким образом, наличие жёсткого априорного ограничения в промпте действует как прайминг-эффект, снижающий объективность анализа и рискующий формированием «туннельного зрения», тогда как его отсутствие способствует более полному учёту альтернативных гипотез и внутренних противоречий в данных.

Послесловие

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

⚠️Поскольку на практике характер нагрузки на СУБД редко остаётся строго неизменным между двумя временными срезами (особенно при смене мажорной версии PostgreSQL), использование промптов с неявными или явными допущениями о стационарности может систематически искажать диагностические выводы.

➡️В инженерной практике, рекомендуется применять «слепое» тестирование промптов на контрольных данных с известным ответом или, как минимум, варьировать формулировки допущений для оценки устойчивости результатов.

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