Хабр·Russia·Monday, September 14, 2026 at 06:25 PM

Промпт-инжиниринг для моделей надежности отказоустойчивого кластера

Translate

avers_529 минут назад

Ранее в «Базовые модели надежности отказоустойчивого кластера» [2] были показаны теоретические подходы к построению моделей (непрерывная цепь Маркова, CTMC, Continuous-Time Markov Chain) отказоустойчивого кластера (fault-tolerant cluster).

Предлагаемый ниже практикум «Промпт-инжиниринг для моделей надежности отказоустойчивого кластера» имеет цель популяризации практических расчетов надежности «подручными средствами» - через ИИ/AI (искусственный интеллект через AI-чат, например, ChatGPT). Задача – формализовать промпты для формирования модели надежности и проведения по ней расчета стационарного коэффициента готовности, Кг.

Промпт (prompt) - запрос, текстовая инструкция, которую пользователь даёт нейросети.

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

Коэффициента готовности, напомним [1], что Кг – численно равен вероятности застать систему (в данном случае кластер) в одном из ее работоспособных состояний (сложение вероятностей каждого такого состояния). Предлагаемые подходы могут быть применены и для других сложных резервируемых структур с учетом ограничений СТМС: случайный процесс «без памяти» с дискретными состояниями и непрерывным временем, а также экспоненциальное распределение времён до отказа/восстановления, независимость отказов компонентов, см. [6], [7].

Специализированные для расчетов надёжности пакеты RAS (Reliability, Availability, and Serviceability) типа SHARPE, MEADEP, RAScad, CARMS, RAPTOR и т.п. позволяют строить и рассчитывать сложные модели. Есть более простые системы (и бесплатные), которые можно использовать для рассмотренных ранее моделей надежности отказоустойчивого кластера, например, relind.ru. Можно использовать универсальные средства (не специализированные под расчет надёжности), например, для расчета марковских цепей, или расчеты делать непосредственно в Matlab и Mathcad и подобных. Однако все это требует достаточно высокий «порог входа» и имеет встроенные в конкретный soft-продукт ограничения, как, по существу, так и по визуализации.

Рассмотрим вариант «быстрого \ легкого старта» при поддержке ИИ, причем не только для расчёта показателя надежности (Кг), но и визуализации модели и оформления результатов.

Последовательность действий:

- вводим базовый промпт (запрос) и оцениваем результат - как проверка адекватности ИИ на основе объемной постановки задачи: реализация промпта с описанием в нем деталей, включая формат представления результата;

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

Визуализацию графа переходов (марковскую цепь) можно реализовать на технологии «Диаграммы как код» (DaC, Diagram-as-Code): Graphviz (dot), Mermaid, PlantUML и даже RDF Grapher (Resource Description Framework). Публикацию результата предлагается осуществлять непосредственно в github (или githubPages), что потребует учетной записи (бесплатно для создания публичных репозитариев). Для просмотра публичного репозитария учетной записи не требуется. Если используем github, то в качестве DaC логичнее выбрать Mermaid (имеется встроенная поддержка, см. «Рисуем диаграммы Mermaid.js в README-файлах GitHub»). Для просмотра и редактирования Mermaid также можно использовать online-сервис mermaid.live.

В статье приведены принципы, ключевые описания, выводы, но на объемную «текстовку» промптов и их результатов будут даны ссылки на проект на github.

1 Трёхпозиционная модель (модель 3/2)

1.1 Базовый промпт «Трёхпозиционная модель»

В [2] на "Рис. 1 Простейшая модель надежности отказоустойчивого кластера из двух узлов (дублированная группа)» была приведена классическая (упрощенная) модель кластера. Задача базового промпта – воспроизвести модель эту модель.

Схема (граф) продублирована на рис.1 в DaC Mermaid. Напомним, что это случай (тип модели): нагруженный резерв (2* λ), одна ремонтная бригада (1* µ), без учета необнаруженного отказа и без failover & failback.

Рис. 1. Граф Трехпозиционной модели двухузлового кластера

Код mermaid:

```mermaid

flowchart LR

S2((S2))

S1((S1))

S0_fail([S0_fail])

S2 -->|"2λ"| S1

S1 -->|"μ"| S2

S1 -->|"λ"| S0_fail

S0_fail -->|"μ"| S1

```

Примеры также можно смотреть (редактировать) на mermaid.live.

Работоспособные состояния:

S2 — оба узла работоспособны, отказов нет;

S1 — один узел работоспособен, второй узел отказал или находится в ремонте.

Неработоспособное состояние:

S0_fail — оба узла отказали, кластер неработоспособен.

хотя ИИ его может построить по описанию самостоятельно.

Хотя LLM способны генерировать Mermaid-код по описанию (языком человека), в состав промпт был добавлен код mermaid (граф). Рекомендуется предоставлять явный шаблон для обеспечения воспроизводимости и корректности синтаксиса, хотя бы в стартовом промпт – это снизит число итераций (не потребует корректирующих синтаксис промптов).

Первый блок кода mermaid определяет легенду: работоспособные состояния – отображать кругом (двойные скобки «((»), а неработоспособные – овалом («([»). Далее показаны переходы с подписью интенсивностей.

Базовый промпт (Исходная модель базового промпта три состояния двухузлового кластера размещен в m3-prompt_full.md.

Его задача задать основу модели и правила оформления результата. Он задает формат DaC, как располагать базовые элементы (узлы графа S0, S1, S2_fail), формат (графической) легенды. Так как состояний у модели (графа) – три, то в названии «Трёхпозиционная модель».

Предлагается использовать оба варианта представления формул.

Вариант 1 «Формулы записывай линейным текстом с использованием Unicode-символов» обусловлен:

а) GitHub Markdown и другие понимают не весь перечень команд LaTeX-обертки (т.е. будут ошибки на станице github при рендеренге LaTeX);

б) перенос в другую систему публикации потребует поддержки LaTeX, точнее всего набора команд LaTeX-обертки, сгенерированного конкретной ИИ – моделью (LLM)

Т.е. могут возникнуть сложности при переносе содержания LaTeX для публикации на иных ресурсах (даже если они имеют поддержку LaTeX).

Вариант 2 «Оформи ответ в режиме GitHub Markdown, формулы в LaTeX-обертке» - как дублирующий вариант.

Для прямого копирования ответа в github markdown некоторым моделям ИИ (например, perplexity.ai) нужно явно указывать, чтобы ИИ представил ответ в формате, совместимом с github mermaid, а при использовании LaTeX формулы обёртывал в $...$ и $$...$$.

Более того:

- проблема 1: GitHub Markdown некорректно отображает многострочные формулы с \\ и + на новых строках внутри одного $$...$$. Решение — записывать всю формулу в одну строку без переносов.

- проблема 2: GitHub Markdown некорректно отображает длинные формулы с \cdot, \left(, \right) и разрывами строк внутри $$...$$. Поэтому ИИ нужно также указывать чтобы все длинные формулы были разбиты на короткие однострочные выражения, без \left(, \right), без \cdot внутри дробей, и без переносов внутри $$...$$.

Подобное устраняется новым запросом с указанием неверного отображения информации в ответе.

1.2 Результат базового промпт

Выполнение ИИ – моделью (LLM) базового промпта должно выдать результат (perplexity.ai) с эталонным, см. m3-report.md

Формула Кг (стационарный коэффициент готовности, Unicode):

Кг = (μ² + 2λμ) / (μ² + 2λμ + 2λ²)

Или LaTeX:

Для сравнения см. формулу в [3]

Пример расчета Кг. Для данных:

- MTBF = 30 000 часов;

- MTTR = 24 часа.

Получим Кг = 0,999 998 72

2 Пятипозиционная модель (модель 5/2)

Напомним расширение \ развитие трехпозиционной модели.

В [2] на «Рис. 2 ClusterFail Failover / Failback модель надежности отказоустойчивого кластера» была показана модель 5/2, которая включает состояния Failover / Failback. На рис. 2 настоящей статьи продублируем граф с дополнительными обозначениями.

**Рис. 2. Граф Пятипозиционной модели двухузлового кластера**

Модель 5/2 отражает режим Nontransparent recovery, nontransparent repair и добавляет состояния Failover / Failback. В [2] рассмотрены четыре комбинации nontransparent / transparent & recovery / repair.

Эту модель (5/2) «промптить» не будем, но она важна как промежуточная для более понятного перехода к восьмипозиционной, в которую (8/2) уже будут включены состояния сбоя (Transient fault) и скрытого отказа (latent).

3 Восьмипозиционная модель (модель 8/2)

3.1 Промпт и результат

Ставится задача: Базовую Трёхпозиционную модель дополнить состояниями (позициями):

- Failover / Failback;

- состояния сбоя (для каждого узла кластера, т.е. дополнительно два состояния S2_tf и S1_tf)

- скрытого отказа (S_latent).

**Рис. 3. Граф Восьмипозиционной модели двухузлового кластера**

Модель 8/2 на mermaid.live.

Необнаруженный отказ был рассмотрен в разделе «4 Необнаруженный отказ» [3], например, ⴄ = 0,99 означает, что из 100 отказов один будет необнаруженный и обнаружение внешними средствами (внешним контролем) «необнаруженного» отказа (необнаруженного средствами кластера, т.е. внутри кластерным контролем) задерживается на время 1/ θ (в среднем).

В модели считается, что в состоянии сбоя узла (Transient fault) кластер находится в состоянии отказа (как и в Приложении 1 к [2]).

Проведем расчет Кг для прежних MTBF и MTTR и «малых» Failover / Failback (30 / 90 секунд соответственно). Другие величины:

- Среднее время перезапуска после временного сбоя Ttr = 180 секунд;

- Среднее время обнаружения скрытого отказа = 8 часов;

- Среднее время между временными сбоями одного узла = 1 год (8 760 часов).

Кг = 0,999 963

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

3.2 Другие расширения базовой модели

Могут быть иные установки / допущения, например, можно считать, что S2_tf – состояние работоспособности. Можно определить, что failover с некой вероятностью может быть неуспешным и тогда дополнительно будет переход из него в S0_fail (в восьмипозиционной модели) или можно предусмотреть особое состояние, например, Единая точка отказа, Single Point of Failure, SPF, см. Приложение 1 к [2], как вариант - отказ «переключателя на резерв» (виртуального).

Аналогично failover могут быть неуспешными failback или восстановление после сбоя (T_tr) и тогда должны быть предусмотрены переходы из этих состояний в состояние отказа, например, в S0_fail.

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

Может быть иной набор состояний, иная конфигурация кластера и допущения. Вариант модели с узлами активный \ пассивный рассмотрен в [5] и [11] (Тёплый резерв, warm standby).

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

3.3 Server vs Server

Статьи про надёжность могут писать ИТ-шники, а могут математики. При этом будет различаться терминология, например, «Server». Математики в статьях по теории «Систем массового обслуживания», СМО (например, [9]) в части моделирования вычислительных систем под сервер вводить «Server», например, «Server vacation», это Ремонтник (а не вычислительный сервер), например, «Отдых ремонтника» (repairman). В такой трактовке Отказ сервера – это Отказ Ремонтника. В этой конкретной статье «Server» (Сервер) — это не узел вычислительного кластера, а ремонтный прибор (ремонтник / ремонтная бригада), который восстанавливает отказавшие рабочие элементы системы. Возникает классическая путаница терминов теории СМО: авторы рассматривают задачу о ремонте машин (Machine Repair Problem). В ней «клиентами» (заявками в очереди) являются отказавшие узлы кластера (units / machines) а «сервером» (server) называют того, кто их обслуживает (ремонтирует). Авторы используют слова Server и Repairman как синонимы.

Вариант модели, когда выделены разные состояния для ремонтной бригады (vacation, busy, broken) показан в [9], «Ремонтник также может отказать и потребовать ремонта» («The repairman may also break down and require repair»). Смотрится странно, когда первую сломанную ремонтную бригаду начинает чинить вторая ремонтная бригада с такой-то интенсивностью. Это к вопросу разных взглядов на процесс ИТ-шника и математика.

Полагаю, что подобное (как «ремонт сломанной ремонтной бригады», так и заболел, ушел в отпуск и т.п.) - неоправданное усложнение задачи, т.к. подобное можно заложить (учесть) в μ (Repair rate, интенсивность ремонта, 1/MTTR), тем более с учетом редких отказов (узлы кластера - высоконадёжные элементы). Условные «Иванов и Петров» могут заболеть, но ремонтная бригада – нет (есть замещение и т.п.).

4 Двенадцатипозиционная модель (модель 12/3)

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

Рассмотрим трехузловый кластер: промпт prompt12_full.md, результат: report12_full.md.

Граф показан на рис. 4., в двенадцатипозиционной модели добавлен узел и соответствующие новому узлу три состояния: сбоя, failover (переконфигурирование) и failback (переключение после восстановления узла).

**Рис. 4. Граф Двенадцатипозиционной модели трехузлового кластера**

Модель 12/3 на mermaid.live.

Кг = 0,999 947

Аналогичным образом можно увеличивать кратность резерва.

4.2 Кумулятивный запрос

Выше были показаны полные промпты. Однако можно использовать кумулятивный запрос (cumulative - «накопительный»), т.е. на основе Базового промпта (такого-то) сделай … и далее второй промпт с уточнением новой конфигурации.

Эксперимент. Выбираем новую ИИ-модель, например, deepseek (ранее использовал perplexity). Ставим задачу исполнить prompt8_full.md

Смотрим и видим, что в ответе проблемы с LaTeX. Даем технический промпт – доработку:

Ты не учел «Важные требования к LaTeX-формулам для GitHub Markdown:». При копировании и вставке в GitHub не отображается LaTeX, т.е. нужно добавить $$ … $$ и для inline-формул использовать $...$. Исправь ответ.

Смотрим результат report8_full_deepseek.md и сверяем с report8_full.md. Убеждаемся, что «все хорошо». Далее даем на выполнение кумулятивный промпт:

Составь модель и выполни расчет Двенадцатипозиционной модели трехузлового кластера (модель 12/3).

Дополни Восьмипозиционную модель двухузлового кластера третьим узлом, предусмотри 12 состояний, из них новые:

- S3 — три узла работоспособны, отказов нет;

- S3_tf — временный сбой одного из трех узлов, два узла работоспособны, но считаем, что кластер в состоянии отказа (на время перезагрузки после сбоя);

- S3_failover при переходе из S3 в S2 (переконфигурирование)

- S2_failback при переходе из S2 в S3

Требования к оформлению оставь прежними (как и для Восьмипозиционной модели).

Для примера расчета используй те же значения, что и для Восьмипозиционной модели.

Сверяем прежний report12_full.md (на основе полного промпт prompt12_full.md) с полученным report12_cum_deepseek.md. Убеждаемся, что «все хорошо».

5 Краткий анализ полученных моделей

Сравним Кг моделей m3, m8, m12.

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

- модель 3/2 (базовая): 0,999 998 7, ожидаемый простой за год ~40 с.

- модель 8/2 (расширенная): 0,999 963, ожидаемый простой за год ~19 мин.

- модель 12/3 (расширенная): 0,999 947, ожидаемый простой за год ~28 мин.

Некоторые выводы:

1 Базовая модель 3/2 имеет наивысшую готовность (~40 секунд простоя в год), так как не учитывает transient faults, latent failures, failover и failback.

2 Модель 8/2 имеет готовность ниже на порядок (~19 минут простоя в год) из-за дополнительных неработоспособных состояний.

3 Модель 12/3 имеет ещё более низкую готовность (~28 минут простоя в год), чем 8/2, при тех же параметрах.

3.1 Феномен «двухузловая архитектура может быть предпочтительнее трёхузловой»: при η=0.99 и Tdetect=8 ч двухузловая расширенная модель (8/2) обеспечивает лучшую готовность, чем трёхузловая (12/3).

3.2 Причина: в 12/3 больше комбинаций скрытых отказов (3 узла вместо 2), что увеличивает вклад S_latent и связанных состояний в неготовность.

3.3 Вывод: Для систем с неполным диагностическим охватом (η<0.999) и длительным временем внешнего контроля (T_detect>1 ч) двухузловая архитектура может быть предпочтительнее трёхузловой с точки зрения стационарной готовности, даже при наличии одного дополнительного резервного узла.

Сравнение Кг и подробный анализ феномена (с анализом подобных исследований) рассмотрен в analysis.md.

Заключение

ИИ меняет привычный мир. Он позволяет заменить специализированные программы (калькуляторы) расчета надёжности: частично в части построения модели и на 100% в части расчета имеющейся модели, включая, формирование по графу системы уравнений, ее решение, подстановку значений и т.п.

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

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

Для повышения доверия: один и тот же промпт задать на исполнение разным моделям ИИ (LLM), а отдельной группе ИИ – сравнить полученные результаты.

Рекомендуется в промпт добавлять «Приведи замечания к промпт».

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

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

Однако, использование ИИ-модели для расчета надёжности сложных систем является наиболее легким стартом и эффективным инструментом, включающим мощнейший мыслящий механизм (AI). Среди простых советов его использования можно привести: на старте исследования использование типовых промпт с эталоном – ответом (дать ИИ «Точку опоры»); ответы по дальнейшим запросам сверять разными ИИ-моделями («Доверяй, но проверяй»); в сам промпт вставлять задачу оценки полноты и качества (неточности, противоречия и т.п.) текущего промпт (с описанием модели) и самой ИИ-модели скорректировать промпт (Обратная связь). Идеальные ответы от ИИ бывают не всегда, иногда нужно ИИ поправлять, например, дать корректирующий промпт. Однако в отличие от готовых программ не нужно вникать в часто сложную (непонятную) логику программы, странности ее интерфейса, а можно задать в промпте требования к формату представления ответа и запрашивать любой уровень детализации (пояснений) полученного ответа. Обсуждение модели, ее модификация, поиск подобных исследований и все это «человеческом» языком и все это бесплатно и на высоком инженерном уровне. В исследовании приведены артефакты от ИИ perplexity и deepseek, но при тестировании использовались и другие ИИ-модели.

Одним из направлений развития концепта может служить «семантическая версия», когда вначале создается базовая онтология надежности кластера, а потом на ее основе строится моделирование конкретной конфигурации кластера. Это позволит систематизировано и на формальном языке знаний фиксировать параметры модели. Концепт такой формализации (на основе строгого формализма) кроме онтологии позволит использовать штатные механизмы \ инструменты \ возможности Linked Data, включая языки запросов и верификации, reasoned etc. Кроме того, формализации модели в RDF (Resource Description Framework, «среда описания ресурса») является также DaC-технологией, где с помощью фильтров может быть получено привычное отображение марковской цепи / графа, т.е. управление визуализацией (RDF grapher) с использованием фильтров видимости: «тип сущности», «предикат» и др.