ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Сравнить CoT vs ToT vs MCTS на своем домене

1. Цель задачи

Научиться эмпирически сравнивать три подхода к рассуждению (reasoning): Chain-of-Thought (CoT), Tree-of-Thought (ToT) и Monte Carlo Tree Search (MCTS) на предмет точности (accuracy), задержки (latency) и стоимости (cost) в конкретном предметном домене. Выбрать наилучший подход для возможного внедрения в production-систему, где требуется многошаговое логическое рассуждение.

Ключевой результат Отчёт с таблицами сравнения, визуализациями и обоснованной рекомендацией по выбору подхода для заданного домена.

2. Исходные данные

Если нет реального инструмента — симулируем:

1. Датасет: используем 50–100 вопросов из GSM8K (математика) или HotpotQA (multi-hop QA).
2. LLM: используем бесплатную модель через Ollama (например, Llama 3 8B) или OpenAI API с низким лимитом.
3. Реализации: для ToT и MCTS возьмём готовые репозитории, адаптируем их под свой формат вопросов. Если репозиторий не работает — симулируем упрощённые версии:
   • ToT: фиксированное дерево глубины 3, ветвления 2, оценивает каждый узел через LLM.
   • MCTS: 50 симуляций, UCT-формула, оценка через LLM как reward.

3. Технологический стек

4. Этапы выполнения

Этап 1: Подготовка датасета и бенчмарка (2–3 часа)

Действия

1. Выбрать домен (например, решение математических задач или ответы на вопросы с несколькими шагами).
2. Собрать или сгенерировать датасет
   • Использовать существующий датасет (GSM8K, MATH, HotpotQA) или
   • Синтезировать: попросить LLM сгенерировать 100 вопросов с эталонными ответами.
3. Разделить датасет 70% train (для настройки гиперпараметров), 30% test (для финального сравнения). Если датасет мал — кросс-валидация.
4. Определить метрики
   • Accuracy: точность совпадения ответа с эталоном (строгое/частичное совпадение, LLM-as-judge).
   • Latency: среднее время ответа на вопрос (в секундах).
   • Cost: количество затраченных токенов * цена токена.
5. Написать вспомогательные функции

   def calculate_accuracy(predictions, ground_truth):
       # точное совпадение после нормализации
       pass
   
   def measure_latency(func, *args):
       import time
       start = time.time()
       result = func(*args)
       return result, time.time() - start
   

6. Зафиксировать baseline
   Выполнить один прямой запрос к LLM (без дополнительного reasoning) на каждом тестовом вопросе. Записать accuracy, latency, cost.

Ожидаемый результат этапа

• Датасет в формате JSON (список {id, question, answer}).
• Функции для расчёта метрик.
• Baseline-метрики.

Этап 2: Реализация методов CoT, ToT, MCTS (4–6 часов)

Действия

1. Chain-of-Thought (CoT):

   • Использовать промпт: "Let's think step by step."
   • Реализовать функцию cot(question) -> (answer, trace).
   • Замерить latency и количество токенов.
   • Код

     def cot(question: str) -> str:
         prompt = f"Question: {question}\nLet's think step by step. Final answer:"
         response = llm_call(prompt)
         return extract_answer(response)
     

2. Tree-of-Thought (ToT):

   • Реализовать класс ToT с параметрами: глубина max_depth=3, ветвление branch=2, метод оценки vote или value.
   • Каждый узел — это частичный ход рассуждения (например, шаг в математической задаче).
   • Оценка через LLM: "Evaluate the promise of this reasoning step."
   • Выбор лучшего пути по сумме оценок.
   • Псевдокод

     class ToT:
         def solve(self, question):
             root = Node(question)
             for depth in range(self.max_depth):
                 leaves = self.expand(root, branch)
                 scores = self.evaluate(leaves)
                 root = select_best(leaves, scores)
             return root.full_trace()
     

3. Monte Carlo Tree Search (MCTS):

   • Реализовать класс MCTS с UCT-селекцией, экспансией, симуляцией (rollout) и backpropagation.
   • Параметры: количество симуляций num_simulations=50, exploration constant C=1.4.
   • Каждый узел — состояние частичного решения (например, текущая строка рассуждения).
   • Симуляция: случайный выбор шагов до конечного ответа, оценка через LLM или эвристику.
   • Псевдокод

     class MCTS:
         def solve(self, question):
             root = Node(question)
             for _ in range(self.num_simulations):
                 node = self.select(root)
                 if not node.is_terminal():
                     node = self.expand(node)
                 reward = self.simulate(node)
                 self.backpropagate(node, reward)
             return best_child(root).full_trace()
     

4. Интегрировать логирование
   Каждый вызов LLM записывать в лог: prompt, response, количество токенов, время.

Ожидаемый результат этапа

• Три рабочие функции/класса: solve_cot, solve_tot, solve_mcts.
• Модульные тесты на синтетических примерах (2–3 вопроса с известными ответами).
• Логирование всех вызовов LLM.

Этап 3: Запуск экспериментов и сбор данных (2–3 часа)

Действия

1. Описать план экспериментов

   • Тестовая выборка: 30 вопросов (можно 50, если позволяет бюджет).
   • Каждый вопрос прогнать через 4 метода: baseline (простой), CoT, ToT, MCTS.
   • Для каждого метода повторить 3 раза для оценки стабильности (среднее).
   • Записать: accuracy (каждого вопроса), latency, total input tokens, total output tokens.

2. Написать скрипт эксперимента

   import pandas as pd
   results = []
   for q in test_set:
       for method in ['baseline', 'cot', 'tot', 'mcts']:
           for _ in range(3):
               res = run_method(method, q)
               results.append({
                   'question_id': q.id,
                   'method': method,
                   'correct': res.answer == q.answer,
                   'latency': res.latency,
                   'input_tokens': res.input_tokens,
                   'output_tokens': res.output_tokens
               })
   df = pd.DataFrame(results)
   df.to_csv('experiment_results.csv', index=False)
   

3. Запустить эксперименты

   • Если используете платные API — ограничить бюджет (например, не более 10$).
   • Если локальная модель — следить за временем выполнения.
   • В случае ошибок (таймаут, битый ответ) — логировать и исключать вопрос из метрик.

4. Первичный анализ

   • Построить сводную таблицу средних метрик по каждому методу.
   • График: accuracy vs latency (на каждом вопросе).
   • График: boxplot latency по методам.

Ожидаемый результат этапа

• CSV-файл с сырыми результатами.
• Сводная таблица средних метрик.
• Начальные визуализации.

Этап 4: Анализ, сравнение и отчёт (2–3 часа)

Действия

1. Статистический анализ

   • Вычислить средние и медианные latency, cost per question.
   • Сравнить accuracy: критерий МакНемара или попарное сравнение.
   • Проверить, какой метод даёт значимо лучше accuracy при допустимой latency.

2. Оценить trade-offs

   • Построить scatter plot: accuracy vs latency (размер точки — cost).
   • Выделить pareto-front: методы, которые не доминируются другими.
   • Для production: какой метод даёт приемлемую accuracy (<5% падения относительно лучшего) при минимальной latency и cost.

3. Написать итоговый отчёт в Markdown

   • Введение: цель, домен, датасет.
   • Описание методов и их реализаций.
   • Таблица результатов:

     Метод	Accuracy	Latency (s)	Cost ($ за 1000 вопросов)
     Baseline	..	..	..
     CoT	..	..	..
     ToT	..	..	..
     MCTS	..	..	..

   • Рекомендация: например, "CoT — лучший баланс: accuracy на 2% ниже ToT, но latency в 3 раза меньше".

4. Подготовить артефакты

   • Все скрипты в Git.
   • Jupyter Notebook с визуализациями.
   • Файл final_report.md.

Ожидаемый результат этапа

• Итоговый отчёт.
• Рекомендация с обоснованием.

5. Критерии приемки (Definition of Done)

• Датасет с 100+ вопросов и эталонными ответами сохранён в JSON.
• Реализованы и протестированы хотя бы CoT и один из сложных методов (ToT или MCTS).
• План эксперимента документирован и воспроизводим (random seed фиксирован).
• Собраны метрики accuracy, latency, cost для каждого метода на тестовой выборке (минимум 30 вопросов).
• Создана сводная таблица сравнения.
• Построены минимум два графика: accuracy vs latency, boxplot latency.
• Итоговый отчёт содержит обоснованную рекомендацию с учётом trade-off.
• Весь код организации выложен в Git-репозиторий с README.
• Указаны все использованные API ключи (окружение .env) – секреты не коммитить.
• Время выполнения в рамках бюджета времени (не более 14 часов).

6. Ожидаемый результат

• Основной артефакт Файл final_report.md (10–15 страниц в формате Markdown).
• Дополнительно
  • Папка src/ с кодом реализаций и скриптов экспериментов.
  • Папка data/ с датасетом и experiment_results.csv.
  • Папка figures/ с сохранёнными графиками (.png).
  • Jupyter Notebook analysis.ipynb с интерактивными визуализациями.

Содержание отчёта:

1. Постановка задачи и описание домена.
2. Обзор датасета.
3. Описание трёх методов и их конфигураций.
4. Подробные результаты экспериментов (таблицы, графики).
5. Статистический анализ значимости различий.
6. Рекомендация с обоснованием (почему именно этот метод лучше других для данного домена).
7. Ограничения эксперимента и возможные улучшения.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание для первого раза Если реализация ToT и MCTS даётся сложно, увеличьте время Этапа 2 до 8 часов. Рекомендуется начать с CoT и одного сложного метода (например, ToT), а MCTS добавить, если позволяет время.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я сформировал датасет минимум из 100 вопросов с эталонными ответами.
• Я реализовал хотя бы два метода (CoT + один из ToT/MCTS) и один baseline.
• Я запустил эксперимент на тестовой выборке (не менее 30 вопросов) и записал метрики.
• Я построил таблицу сравнения и хотя бы два графика.
• Я написал итоговый отчёт, содержащий исследовательский анализ и рекомендацию.
• Я проверил, что код воспроизводим (указаны seed, версии библиотек).
• Я убедился, что не превысил бюджет времени (10–15 часов).
• Я документировал все параметры методов (глубина, ветвление, число симуляций).
• Я указал, какой метод был бы выбран для production и почему.