Я, честно говоря, совершенно не вижу проблем. Возьмем ClickUp AI Project Manager для примера. Все до единого СааСы сейчас делают такие тулы. 95% функций таких копилотов сейчас реализовано с помощью трех-четырех инструментов:
- Системный промпт. Все вот эти функции типа “create action items for a task” или “summarise a meeting” обычно ограничиваются просто системным промптом, типа “Ты - проектный менеджер. Составь список дел для задачи: {текст задачи}”. Это максимально просто и именно тут будут перемешаны всякие старые практики. Но так не обязательно делать!
- Файн-тюнинг на практиках, если обычный системный промпт работает совсем нестабильно. Но с нашей точки зрения, это опять непонятный black-box и мешанина практик: кто оценивал, что это хорошее саммари встречи, кенийцы? (Ничего не меняется и если файн-тюн не по принципу RLHF а на основе корпуса примеров - нам все еще ничего не известно о практике.
- Tools & APIs. Вроде, Microsoft Copilot знает, что если его спрашивают про какой-то документ, то он может пойти в Microsoft SharePoint API, чтобы их искать. А Gemini - в Google Drive API. A ClickUp AI - знает, что помимо Tasks API, там еще есть такие типы объектов как Roadmaps, OKRs, Docs, etc.
- К предыдущему пункту стыкуются RAG indexes на уровне документов организации. Ну это просто вариант Search API.
Но никто, насколько я вижу, не применяет подход custom GPTs, с использованием идей из интерфейса их создания - GPT editor.
Допустим, мы знаем, что action items должны браться не из “головы LLM”, а исходить от старшего инженера/архитектора в подразделении. “Методологом”/директором по развитию выступает сам AI, а именно editor, который просит для каждого раздела в корпоративном issue tracker чтобы с ним кто-то пообщался, до того, как функцию “create action items for a task” можно исполнить. AI выспрашивает у старшего инженера чеклист, роли других стейкхолдеров, интересы которых надо учитывать в решениях по дизайну данной целевой системы, и т. д. (я даже не знаю, что еще, но всего не очень много вещей). Потом ответы переформатируются (GPT editor тоже это делает), сохраняются, и их всегда можно отредактировать, продолжив этот “методологический” чат.
Затем, когда кто-то нажимает кнопку “create action items for a task”, LLM исполняет довольно нехитрый flow (cf. AlphaCodium), c шагами вроде:
- Составь список того, что уже было сделано, исходя из истории тикета: {описание + комментарии}.
- Составь список того, что должно было быть сделано, исходя из такого чеклиста: {чеклист из хранилища, специфичный для подразделения}, и такого описания задачи: {описание}.
- Сопоставь пункты из списка {должно было быть сделано} со списком {уже сделано}. Убери уже сделанное.
Это кажется очень простым, более чем в пределах досягаемости текущих LLM, и я не вижу, в чем тут проблема и где LLM может врать и работать не по практике.
Аналогично с саммари митинга: не просто “сделай саммари митинг: {транскрипт}”, а довольно простой flow - какой был тип митинга (принятие решения или операционное планирование), какие роли были, какие интересы они проявляли, к какому трейдоффу пришли.