Skeleton-of-Thought (SoT)

Суть в двух словах

SoT особенно полезен для:

• аналитических memo;
• long-form статей;
• product docs и strategy notes;
• планов и roadmaps;
• ответов, где важно не забыть раздел или аргумент.

Сначала создай skeleton memo из 4 разделов. Потом кратко раскрой каждый раздел.

Тема: стоит ли запускать AI-помощник для customer success команды.

Зачем вообще нужен skeleton

Монолитная генерация длинного ответа часто ломается так:

• важный раздел забывается;
• середина ответа уезжает в сторону;
• концовка оказывается слабее начала;
• структура выходит неровной;
• разные части дублируют друг друга.

Skeleton-of-Thought помогает, потому что сначала фиксирует shape of answer, а уже потом позволяет модели наращивать содержание.

Где техника особенно сильна

Лучшие кейсы:

• статьи и лонгриды;
• internal docs;
• executive memo;
• due diligence summaries;
• launch plans;
• educational explanations;
• architecture overviews.

Менее полезна техника:

• в коротких factual answers;
• в JSON/schema outputs;
• в small talk;
• там, где already constrained form и так задаёт структуру.

Почему SoT полезен не только для writing

Технику легко принять за "приём для текстов", но её реальная ценность шире. Skeleton полезен везде, где сначала нужно зафиксировать shape of output:

• аналитическая записка;
• набор рекомендаций;
• архитектурный разбор;
• учебное объяснение;
• sectioned report.

То есть SoT хорошо работает не только как writing trick, а как способ стабилизировать multi-section generation.

Как выглядит хороший skeleton

Хороший skeleton:

• короткий;
• иерархически понятный;
• покрывает всю задачу;
• не пытается сразу написать ответ целиком;
• допускает section-by-section expansion.

Плохой skeleton:

• слишком общий;
• содержит готовые выводы вместо разделов;
• дублирует пункты;
• включает слишком много мелких подпунктов.

Что делает skeleton рабочим

Хороший outline:

• покрывает все обязательные разделы;
• удерживает правильный порядок;
• не спорит сам с собой;
• задаёт expansion scope для каждого блока.

Это особенно важно в длинных материалах: плохой skeleton потом масштабирует ошибку на весь документ.

Практический workflow

Самый useful production pattern обычно такой:

1. Сгенерировать skeleton.
2. Проверить его человеком или judge.
3. При необходимости поправить outline.
4. Раскрывать разделы по одному.

Это даёт два сильных плюса:

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

Третий плюс часто недооценивают: такой pipeline проще кэшировать. Если outline уже утверждён, можно регенерировать только один проблемный раздел, а не весь документ целиком.

Как ревьюить skeleton до expansion

Перед разворачиванием полезно проверить outline по четырём вопросам:

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

Это и есть основной quality gate техники. Если плохой skeleton пропустить дальше, expansion обычно только масштабирует исходный structural defect.

Когда section-by-section expansion лучше batch expansion

Есть два рабочих режима:

1. expand all sections in one go
2. expand each section separately

Первый быстрее и удобен для средних текстов. Второй лучше, когда:

• разделы сильно отличаются по тону или типу работы;
• нужен отдельный review каждого блока;
• есть риск section drift;
• часть разделов должна генерироваться с tools или citations.

В production чаще выигрывает гибрид: skeleton целиком, потом expansion по одному блоку или небольшими батчами.

SoT и соседние техники

Частые ошибки

Ещё типичные ошибки:

• skeleton слишком длинный;
• каждый пункт уже превращён в мини-эссе;
• expansion не привязана к конкретным пунктам skeleton;
• структура не проходит даже минимальный review.

Когда лучше выбрать другую технику

SoT не лучший выбор, если:

• нужен procedural solution plan, а не структура ответа;
• требуется строгий machine-readable schema;
• ответ короткий и не требует sectioning;
• проблема не в структуре, а в фактах или reasoning quality.

В этих случаях чаще лучше работают Plan-and-Solve, Structured Output, RAG или verification patterns.

Practical pattern

step_1 = "Сначала дай только outline из 4-6 пунктов."
step_2 = "После утверждения outline раскрой каждый пункт."

Почему это удобно инженерно

Если у вас длинный writing pipeline, SoT часто выгоднее монолитной генерации, потому что:

• проще остановить плохой план раньше;
• легче делать section-by-section edits;
• удобнее подключать human review;
• проще кэшировать outline и переиспользовать его.

Где стоит логировать отдельно

Полезно хранить:

• исходный skeleton;
• утверждённую версию;
• expanded sections;
• время и стоимость на фазу expansion.

Так видно, где pipeline реально выигрывает.

Полезный quality gate перед expansion

def skeleton_is_ready(items: list[str]) -> bool:
    if not 4 <= len(items) <= 7:
        return False
    if any(len(item.split()) > 14 for item in items):
        return False
    return True

Такой примитивный gate не заменяет review, но хорошо отсеивает две частые поломки: слишком рыхлый outline и outline, который уже превратился в пол-статьи.

Что измерять

Для SoT-пайплайна полезно смотреть:

• completeness of final answer;
• section drift rate;
• сколько разделов пришлось перегенерировать;
• latency difference between monolithic and outline-first generation.

Это показывает, помогает ли outline-first подход реально, а не только делает процесс визуально более аккуратным.