Diagram of Thought (DoT, «диаграмма мыслей») — reasoning pattern, в котором рассуждение строится как directed acyclic graph, а не линейная цепочка или дерево. В 2026 его полезно понимать не как "красивую визуальную метафору", а как critique-oriented graph pattern для задач, где ценность даёт не просто ветвление, а явный цикл proposal -> criticism -> refinement.
| Характеристика | CoT | ToT | DoT |
|---|---|---|---|
| Структура | Линейная цепочка | Дерево | DAG |
| Самокритика | Нет | Нет (оценка путей, но не критика) | Да, встроенная |
| Возврат к шагам | Нет | Частичный (backtracking) | Полный (любой узел) |
| Число вызовов API | 1 | Десятки (BFS/DFS) | 1 (всё в одном промпте) |
| Подходит для | Простое рассуждение | Поисковые задачи | Аналитика, дебаты, решения |
Техника уместна там, где:
Это хороший fit для:
Но для задач с одним легко проверяемым ответом DoT часто избыточен: там проще работают ToT, verification или solver-backed workflows.
Метод: Diagram of Thought (DoT). Задача: Стоит ли стартапу из 5 человек переходить с монолита на микросервисы? Роли: - [P] Proposer: предложи аргумент - [C] Critic: найди слабость - [R] уточнение после критики - [S] Summarizer: обобщи Строй DAG — указывай связи между узлами.
P1: Микросервисы дают независимый деплой — каждый разработчик может деплоить свой сервис отдельно.
C1 → критикует P1: В команде из 5 человек каждый и так знает весь код. Независимый деплой экономит секунды, но добавляет сложность оркестрации (Docker, K8s, service mesh). Для 5 человек это overhead.
P2: Микросервисы позволяют масштабировать только нагруженные части системы.
C2 → критикует P2: Стартапу из 5 человек обычно рано думать о масштабировании. Premature optimization. Монолит на одном сервере справится с первыми 10K пользователей.
R1 → уточняет P1 + P2 с учётом C1 + C2: Микросервисы имеют смысл для команды 5 человек только если продукт уже в продакшене с высокой нагрузкой и чётко выделенными доменами. Для MVP — однозначно монолит.
P3: Монолит проще тестировать, дебажить и онбордить новых разработчиков.
C3 → критикует P3: Это верно для маленького монолита. Но если монолит уже 200K строк с запутанными зависимостями — тестирование и дебаг тоже страдают.
R2 → уточняет P3 с учётом C3: Ключевой фактор — не архитектура, а качество кода. Чистый монолит с модульной структурой лучше плохих микросервисов.
P4: Компромисс: модульный монолит (monolith with clear module boundaries), готовый к будущему разделению.
C4 → критикует P4: Разумно, но требует дисциплины. Без code review и архитектурных границ модульный монолит быстро превращается в big ball of mud.
[S] Summarizer → обобщает R1, R2, P4, C4:
Вердикт: НЕ переходить на микросервисы.
Рекомендация:
1. Чем DoT отличается от Tree of Thoughts (ToT)?
2. Какие три роли используются в Diagram of Thought?
3. Для каких задач DoT подходит лучше всего?