Стенограмма встречи → список задач: промпты для локальных LLM, которые работают

Почему это больно и как AI может помочь

Вы сидите на совещании. Минут 45. Кто-то говорит "нужно проанализировать", кто-то обещает "сделаю к пятнице", а ещё кто-то упоминает "обсудим в следующий раз". Потом вы тратите час, пытаясь выудить из конспекта, кому что делать и когда. Знакомо?

Локальные LLM решают эту проблему на раз. Не нужно отправлять конфиденциальные записи в облако. Не нужно платить за API. Просто кидаете стенограмму в модель и получаете готовый JSON с задачами, дедлайнами и ответственными. Звучит как магия? Это просто грамотный промпт.

Что ломается в теории и работает на практике

В учебниках всё просто: "дайте модели инструкцию - получите результат". В реальности модель либо генерирует эссе вместо списка, либо приписывает задачи не тем людям, либо вообще игнорирует дедлайны.

Проблема в том, что LLM - не база данных. Она не ищет шаблоны, а достраивает вероятностную картину. Поэтому промпт должен не просто просить "извлеки задачи", а задавать контекст, в котором "задача" имеет конкретное определение.

1Как НЕ надо делать

Вот классическая ошибка, которая даёт мусор вместо задач:

# ПЛОХОЙ промпт - так делать не стоит
prompt = """
Извлеки все задачи из этой стенограммы встречи.

{transcript}
"""

Почему это плохо? Потому что модель не знает, что такое "задача" в вашем понимании. Она может посчитать задачей "нужно подумать над этим" или "обсудим позже". Результат будет бесполезным.

2Рабочий промпт с JSON Schema

Вот что работает с современными локальными моделями (тестировал на Llama 3.2 70B через Ollama):

SYSTEM_PROMPT = """Ты - ассистент по обработке встреч. Твоя задача - извлекать конкретные action items (задачи с чёткими поручениями) из стенограмм.

КРИТЕРИИ ЗАДАЧИ:
1. Есть конкретный исполнитель (имя или роль)
2. Есть конкретное действие (глагол: подготовить, отправить, проверить)
3. Есть срок или контекст выполнения ("к пятнице", "до следующей встречи", "после получения фидбека")
4. Задача была явно поручена или принята, а не просто упомянута

ИГНОРИРУЙ:
- Общие обсуждения без конкретных действий
- Фразы типа "нужно подумать", "возможно сделаем", "обсудим позже"
- Мнения и комментарии без поручений

Верни результат в формате JSON строго по схеме ниже."""

USER_PROMPT = """
Стенограмма встречи:
{transcript}

Извлеки все action items и верни их в формате JSON по этой схеме:
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "task_id": {"type": "string", "description": "Уникальный ID задачи (генерируй на основе содержания)"},
      "description": {"type": "string", "description": "Чёткое описание задачи"},
      "assignee": {"type": "string", "description": "Исполнитель (имя из стенограммы или роль)"},
      "deadline": {"type": "string", "description": "Срок или контекст выполнения"},
      "source_context": {"type": "string", "description": "Цитата из стенограммы, откуда взята задача"}
    },
    "required": ["task_id", "description", "assignee", "deadline", "source_context"]
  }
}

Только JSON, без дополнительного текста."""

Магия здесь в детализации критериев. Модель понимает разницу между "Мария сказала, что отправит отчёт" (задача) и "Все согласились, что отчёт нужен" (не задача).

Пример реальной работы

Допустим, у вас такая стенограмма:

Алексей: Нужно подготовить презентацию по квартальным результатам к среде.
Мария: Я займусь сбором данных по продажам.
Иван: А я проверю цифры из финансового отчёта.
Алексей: Хорошо, Мария, пришли мне данные до завтра.
Иван: А презентацию кто будет делать?
Алексей: Я сам сделаю, если Мария пришлёт данные вовремя.

С промптом выше модель вернёт:

[
  {
    "task_id": "sales_data_q1",
    "description": "Собрать данные по продажам для квартального отчёта",
    "assignee": "Мария",
    "deadline": "до завтра",
    "source_context": "Мария: Я займусь сбором данных по продажам. Алексей: Хорошо, Мария, пришли мне данные до завтра."
  },
  {
    "task_id": "finance_check_q1",
    "description": "Проверить цифры из финансового отчёта",
    "assignee": "Иван",
    "deadline": "к среде",
    "source_context": "Иван: А я проверю цифры из финансового отчёта."
  },
  {
    "task_id": "presentation_q1",
    "description": "Подготовить презентацию по квартальным результатам",
    "assignee": "Алексей",
    "deadline": "к среде",
    "source_context": "Алексей: Нужно подготовить презентацию по квартальным результатам к среде. Алексей: Я сам сделаю, если Мария пришлёт данные вовремя."
  }
]

Обратите внимание: модель связала разрозненные реплики в одну задачу для Алексея. Это то, что не сделает простой парсинг по ключевым словам.

Продвинутые схемы для сложных случаев

Что если в встрече участвует 10 человек и задачи пересекаются? Или если нужно учитывать приоритеты? Вот расширенная схема:

{
  "meeting_summary": {
    "title": "string",
    "date": "string",
    "participants": ["string"]
  },
  "action_items": [
    {
      "id": "string",
      "description": "string",
      "assignee": "string",
      "co_assignees": ["string"],
      "priority": "high|medium|low",
      "deadline_type": "absolute|relative|meeting_based",
      "deadline": "string",
      "dependencies": ["string"],
      "status": "new|in_progress|blocked",
      "context": "string"
    }
  ],
  "decisions_made": ["string"],
  "next_meeting_topics": ["string"]
}

Эта схема уже ближе к BPMN-аналитике, но работает с теми же моделями. Mistral Small 2.5 (актуальная на 2026 год) отлично справляется с такой структурой.

Интеграция в пайплайн: от стенограммы до Jira

Один промпт - это хорошо. Но что если нужно обрабатывать десятки встреч в неделю? Вот где пригодится семантический пайплайн.

Представьте такой поток:

1. Zoom/Teams записывает встречу → Whisper транскрибирует
2. Транскрипт попадает в Ollama с промптом выше
3. LLM возвращает JSON с задачами
4. Python-скрипт парсит JSON и создаёт тикеты в Jira/Linear/Asana
5. Участники получают автоматические уведомления

Всё локально. Никаких облачных API. Никаких утечек конфиденциальных данных.

# Пример минимального рабочего скрипта
import requests
import json

# Локальный Ollama с Llama 3.2
OLLAMA_URL = "http://localhost:11434/api/generate"

def extract_action_items(transcript):
    prompt = f"{SYSTEM_PROMPT}\n\n{USER_PROMPT.format(transcript=transcript)}"
    
    payload = {
        "model": "llama3.2:latest",
        "prompt": prompt,
        "stream": False,
        "format": "json"  # Критически важный флаг для новых версий Ollama
    }
    
    response = requests.post(OLLAMA_URL, json=payload)
    # Новые модели возвращают чистый JSON, старые могли вкладывать его в текст
    result = response.json()
    
    # Ollama 0.5.0+ возвращает JSON в поле 'response'
    if 'response' in result:
        try:
            return json.loads(result['response'])
        except:
            # fallback для старых версий
            return extract_json_from_text(result['response'])
    
    return []

Тонкая настройка: когда простого промпта мало

Иногда даже самый детальный промпт даёт сбои. Особенно с:

• Многочасовыми стратегическими сессиями
• Встречами с сильным акцентом или жаргоном
• Стенограммами плохого качества (перебивания, фоновый шум)

Решение? Fine-tuning. Но не тот, что требует GPU за $100k. Достаточно 50-100 размеченных стенограмм и LM Studio на хорошем ноутбуке.

Вы берёте Mistral 7B (или даже меньшую модель) и дообучаете её на своих данных. Не учите всю модель с нуля - используйте LoRA (Low-Rank Adaptation). Это меняет всё:

# Пример подготовки данных для fine-tuning
# Каждый пример - это пара {"transcript": "...", "action_items": [...]}
# 50 таких пар достаточно для значительного улучшения

python prepare_lora_data.py \
  --transcripts_dir ./meeting_transcripts \
  --output ./training_data.jsonl \
  --model mistralai/Mistral-7B-Instruct-v0.3

После 2-3 часов обучения на RTX 4090 вы получаете модель, которая понимает вашу корпоративную культуру, имена коллег и специфичные термины. Точность подскакивает с 90% до 98%.

Чего не умеют даже лучшие промпты (пока)

Не обольщайтесь. Есть вещи, которые даже Llama 3.2 не делает идеально:

• Сарказм и ирония: "Отлично, ещё одна задача на выходные" модель может воспринять как реальное поручение
• Неявные зависимости: если задача B зависит от задачи A, но это не сказано явно, модель не догадается
• Контекст вне стенограммы: модель не знает, что Иван в отпуске на следующей неделе, даже если это влияет на дедлайны

Решение? Человеческий ревью. Но не полный, а выборочный. Настройте систему так, чтобы модель помечала задачи с низкой confidence score (менее 70%) для проверки человеком.

Что дальше: от извлечения задач к управлению проектами

Самый интересный тренд 2025-2026 годов - LLM как ядро локальных ассистентов для встреч. Представьте:

Модель не просто извлекает задачи, а:

1. Следит за выполнением (напоминает о дедлайнах)
2. Предлагает оптимизацию ("Эти две задачи можно объединить"
3. Готовит повестку следующей встречи на основе незавершённых задач
4. Интегрируется с календарём и системой управления проектами

Для этого нужны модели с Tool Calling. Llama 3.2 90B уже умеет вызывать функции. Можно научить её создавать тикеты в Jira через API, слать напоминания в Slack и даже предлагать перепланирование встреч при конфликте дедлайнов.

Но начинать стоит с простого. Возьмите промпт из этой статьи, запустите Ollama с Mistral Small 2.5 (она бесплатная и работает на чём угодно) и обработайте свою последнюю встречу. Первый результат вас удивит. Возможно, даже шокирует - насколько много задач вы пропускали.

Главное - не пытайтесь сделать идеальную систему с первого раза. Начните с извлечения задач. Потом добавьте приоритеты. Потом - интеграцию. Каждый шаг даёт immediate value. А через месяц у вас будет полностью автоматизированный pipeline, который экономит 5-10 часов в неделю. Без единого облачного API.