Предисловие
В работе с генеративными нейросетями при решении задач технической диагностики существенное значение приобретает способ управления выходными форматами и содержательной точностью ответов. Одним из инструментов такого управления выступает системный промпт — набор инструкций, определяющих роль модели, правила обработки данных, требования к стилю и полноте ответа. Настоящее исследование посвящено сравнительному анализу двух режимов промптирования применительно к задаче формирования сводного отчёта по производительности СУБД PostgreSQL и сопутствующей инфраструктуры.
В качестве экспериментального материала использованы два промпта: базовый (содержащий только структуру отчёта и общие требования) и расширенный (включающий детализированный системный промпт с десятью правилами, заданием роли эксперта и указанием стиля). На основе предоставленных статистических данных (метрики PostgreSQL, vmstat, параметры конфигурации) были получены два ответа нейросети — result-1.txt и result-2.txt. В представленном ниже анализе проведено сопоставление этих ответов по таким критериям, как указание периода наблюдения, полнота единиц измерения, интерпретация качества моделей, выявление недостающих данных, формальность терминологии и фиксация аномалий. Цель работы — оценить влияние системного промпта на характер ответа, а также определить эффективность и целесообразность его применения в задачах анализа производительности реляционных СУБД.
Пример отчета с использованием системного промпта
Исходный промпт
Сформируй сводный отчет по производительности СУБД и инфраструктуры.
Для формирования отчета используй списки, вместо таблиц.
Исключи из отчета рекомендации, только анализ.
Состав отчета:
# Общая информация
# Общий анализ операционной скорости и ожиданий СУБД
## Граничные значение операционной скорости (SPEED) и ожиданий СУБД(WAITINGS)
## Анализ трендов операционной скорости (SPEED) и ожиданий СУБД(WAITINGS)
## 1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД
### Итог по разделу "1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"
## 2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat
### Итог по разделу "2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"
## 3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat
### Итог по разделу "3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat"
## 4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID
### Итог по разделу "4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID"
# Детальный анализ – граничные значения и корреляции
## Ожидания СУБД
## Память и буферный кэш
## Дисковая подсистема (I/O)
## CPU и системные вызовы
## Блокировки и ожидания LWLock
## Анализ запросов (queryid)
# Ключевые проблемы
## Проблемы СУБД
## Проблемы инфраструктуры
# Заключение
С использованием системного промпта
Ты — эксперт по производительности СУБД PostgreSQL.
Твоя задача — анализировать статистические данные (метрики, логи, выводы из pg_stat_database, pg_stat_statements, системные показатели) и давать точный, предметный анализ метрик и корреляций.
Правила:
1. Отвечай строго на основе предоставленных данных. Если информации недостаточно для однозначного вывода — прямо укажи, каких именно данных не хватает, и предложи, что нужно собрать для более точного анализа.
2. Не придумывай метрики, значения или причины. Не используй общие фразы без подтверждения цифрами.
3. Если в данных есть аномалии или противоречия — отметь их и объясни возможные сценарии, но без домыслов.
4. Ответ должен быть структурирован:
- Краткое резюме (основные выводы).
- Детальный анализ по ключевым метрикам (нагрузка на CPU/IO, использование памяти, блокировки, медленные запросы, эффективность кэша, параметры конфигурации).
- Если данных недостаточно — перечень необходимых дополнительных метрик или срезов.
5. Используй профессиональную терминологию (shared_buffers, effective_cache_size, seq scan, index scan, checkpoint, autovacuum, deadlocks и т.п.). При ссылке на параметры указывай их единицы измерения.
6. Если в данных присутствуют временные интервалы — анализируй тренды, а не точечные значения. Указывай период наблюдения.
7. Не предлагай изменений конфигурации без уверенности в их необходимости. Если сомневаешься — предложи провести дополнительную диагностику.
8.Если у тебя нет точной информации или данных недостаточно для уверенного ответа, не придумывай. Скажи:Недостаточно данных для ответа.
9.Даже если таблицы нагляднее — используй только списки.
10.Исключи из отчета рекомендации, только анализ.
Стиль: деловой, технически точный, без лишних пояснений.
Если пользователь не предоставил сами данные, а только вопрос — запроси конкретные метрики и период наблюдения.
Сформируй сводный отчет по производительности СУБД и инфраструктуры.
Состав отчета:
# Общая информация
# Общий анализ операционной скорости и ожиданий СУБД
## Граничные значение операционной скорости (SPEED) и ожиданий СУБД(WAITINGS)
## Анализ трендов операционной скорости (SPEED) и ожиданий СУБД(WAITINGS)
## 1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД
### Итог по разделу "1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"
## 2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat
### Итог по разделу "2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"
## 3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat
### Итог по разделу "3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat"
## 4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID
### Итог по разделу "4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID"
# Детальный анализ – граничные значения и корреляции
## Ожидания СУБД
## Память и буферный кэш
## Дисковая подсистема (I/O)
## CPU и системные вызовы
## Блокировки и ожидания LWLock
## Анализ запросов (queryid)
# Ключевые проблемы
## Проблемы СУБД
## Проблемы инфраструктуры
# Заключение
Вопрос нейросети
Проанализируй промпты к нейросети "prompt-1.txt", "prompt-2.txt". Сравни результаты ответов :"result-1.txt" , "result-2.txt". Проанализируй влияние добавления системного промпта в "prompt-2.txt" на характер ответа "result-2.txt", оцени эффективность и целесообразность применения добавления системного промпта, для анализа статистических данных производительности СУБД PostgreSQL.
Сравнительный анализ промптов и результатов (в формате списков)
1. Содержательные различия промптов
- prompt-1.txt – содержит только структуру отчёта и общие требования (использовать списки, исключить рекомендации). Отсутствуют инструкции о роли модели, правилах работы с данными, стиле ответа.
- prompt-2.txt – включает полный системный промпт, который:
задаёт роль «эксперт по производительности PostgreSQL»;
вводит 10 конкретных правил (отвечать строго по данным, не придумывать, указывать на нехватку данных, анализировать тренды, использовать профессиональную терминологию, не предлагать изменения без уверенности, не использовать таблицы и т.д.);
определяет стиль (деловой, технически точный);
требует явно запрашивать недостающие метрики.
2. Сравнение результатов (result-1.txt vs result-2.txt)
Оба отчёта следуют заданной структуре, содержат одни и те же числовые значения (метрики, корреляции, R², углы трендов). Однако result-2.txt отличается следующими улучшениями:
По критерию «Указание периода наблюдения»
- result-1.txt: отсутствует.
- result-2.txt: присутствует («2026-03-14 09:56 – 12:18 (143 точки, ~2.5 часа)»).
По критерию «Единицы измерения параметров»
- result-1.txt: приводятся не всегда (например, dirty pages size в КБ, но без пояснения).
- result-2.txt: приводятся системно (shared_buffers = 1919 МБ, dirty_ratio = 30% (≈2.25 ГБ) и т.д.).
По критерию «Интерпретация качества моделей»
- result-1.txt: есть R² и углы, но без пояснений порогов.
- result-2.txt: добавлены качественные оценки («очень высокое качество», «модель непригодна»).
По критерию «Выводы о статистической значимости»
- result-1.txt: есть, но менее формализованы.
- result-2.txt: чётко разделены («корреляция значима», «ВКО < 0.01 – игнорируется»).
По критерию «Указание на недостающие данные»
- result-1.txt: отсутствует.
- result-2.txt: добавлен отдельный блок в Заключении (iostat, планы запросов, статистика контрольных точек и т.д.).
По критерию «Стиль и терминология»
- result-1.txt: технически корректен, но встречаются менее строгие формулировки («система не справляется»).
- result-2.txt: более формальный, с ссылками на конкретные параметры и события (DataFileRead, vm.dirty_ratio).
По критерию «Наличие противоречий/аномалий»
- result-1.txt: не отмечены.
- result-2.txt: отмечено противоречие (высокий hit ratio 96–98%, но огромные ожидания IO) – указано, что проблема не в кэше.
3. Влияние системного промпта на характер ответа
Системный промпт в prompt-2.txt заставил модель:
- явно указать период наблюдения (правило 6);
- перечислить недостающие данные (правила 1, 8) – в result-1 этого нет;
- использовать единицы измерения для всех параметров (правило 5);
- избегать общих фраз без цифр – все выводы подкреплены значениями R², корреляций, процентилями;
- чётко разделять статистически значимые и незначимые связи (например, «модель непригодна» для wa);
- не давать рекомендаций – в обоих отчётах их нет, но в result-2 дополнительно подчёркнуто, что требуется диагностика;
- сохранять деловой стиль – без лишних пояснений, только анализ.
При этом фактические цифры и основные выводы совпадают. Системный промпт не изменил «мнение» модели о данных, а улучшил форму подачи, полноту и строгость отчёта.
4. Эффективность и целесообразность применения системного промпта
Эффективность – высокая.
Системный промпт повысил:
- информативность – появился период наблюдения, список недостающих данных;
- точность – все утверждения привязаны к метрикам, нет домыслов;
- практическую ценность – инженер получает не только анализ, но и чёткий перечень того, что ещё нужно измерить;
- соответствие лучшим практикам – указание на непригодные модели (R²=0.13) предотвращает ложные выводы.
Целесообразность – безусловно да.
Анализ производительности СУБД требует высокой дисциплины от аналитика. Системный промпт действует как «чек-лист» для модели, снижая риск:
- пропуска временного контекста;
- использования неспециализированной лексики;
- необоснованных обобщений;
- отсутствия критической оценки качества данных.
Без системного промпта (prompt-1.txt) модель выдала технически правильный, но менее полный и менее строгий отчёт. Добавление системного промпта не увеличило риск галлюцинаций, а наоборот, ограничило их.
5. Рекомендация
Для задач технического анализа (особенно производительности, отказоустойчивости, безопасности) системный промпт обязателен. Он должен включать:
- роль эксперта;
- правила работы с данными (не придумывать, указывать на пробелы);
- требования к единицам измерения, периодам, терминологии;
- запрет на рекомендации без уверенности;
- структуру ответа.
В данном случае системный промпт из prompt-2.txt является образцовым для класса задач «анализ метрик PostgreSQL». Его целесообразно использовать как шаблон.