Специализированная модель для аудита PostgreSQL. Небольшая, быстрая, работает на одной потребительской видеокарте — и при этом отдаёт строгий, проверяемый результат: критичность, доказательства с числами, расчёты и конкретные действия.
Модель не пишет «эссе». Каждый ответ — структура, которую можно проверить и по которой можно действовать:
{
"task": "alert_analysis",
"thresholds": {"long_tx_sec": 120, "dead_pct": 20},
"alert": {
"kind": "long_transaction",
"details": {"pid": 3980, "sec": 372, "state": "idle in transaction"}
},
"stats": { "sessions": [...], "locks": [...], "queries": [...] }
}
→
{
"severity": "critical",
"evidence": [{"metric": "xact_age", "value": 372, "unit": "s"},
{"metric": "blocked_by_pid", "value": 7}],
"calculations": ["372 / 120 = 3.1x порога"],
"reasoning": "idle in transaction держит блокировку на orders;
7 сессий в очереди — каскад",
"recommendations": [
{"action": "terminate_backend", "pid": 3980},
{"action": "set_parameter",
"name": "idle_in_transaction_session_timeout",
"suggested_value": "5min"}
]
}
~4 600 примеров в финальном миксе. Каждый слой закрывает свою способность — от знания предметной области до работы с реальным форматом агента.
Знания PostgreSQL 18: параметры конфигурации, системные представления, wait events, пороговые значения. Фундамент — «что означает эта метрика и когда это плохо».
Причинно-следственные цепочки и диагностические деревья: от симптома к корню. Учит модель рассуждать, а не подбирать похожие ответы.
Многоходовое расследование по логам: какие записи значимы, как их связать между собой и с состоянием базы.
Реальный формат снапшота и алерта нашего агента + детерминированные эталоны с правильными действиями (VACUUM, terminate_backend). Оба режима — audit и alert, 7 сценариев с балансом критичности. Именно этот слой делает модель «своей» для DBAigent.