Я бы немного добавил с точки зрения того, что LLM не даёт. LLM зачастую не умеет правильно абстрагировать реальность, формулировать модель процесса. Поэтому, на мой взгляд, именно умение формулировать модель и объяснять её LLM становится ключевым навыком. Причём модель — это не просто формализация декомпозиции на шаги, но и критерии, которые помогают определять результаты как плохие или хорошие. Зато LLM хорошо умеет следовать построенной модели и проверять себя, используя модель. Модель хорошо встраивается в мультиагентные системы и воркфлоу. Именно умение создавать выразительные модели предметной области/процесса — ключевой навык. А затем уже идут описанные специализации: внедрение ИИ, использование в работе и т. д.
Я не заметил глобальной разницы в том, разные это модели или одинаковые, главное, чтобы они не шарили контекст между собой.
Для критика и генератора важна выстроенная логическая модель, критерии. То есть нельзя абстрактно написать «оцени, хорошо это или плохо», нужно ввести модель оценивания и модель клиента. Как идея, можно брать реальные транскрипты и из них пробовать реконструировать модель пользователя, но я такое не пробовал.
Естественно, если мы вводим какую-то функцию, по которой оптимизируем (критика), то процесс будет оптимизироваться под него. Важно вовремя остановить процесс оптимизации, чтобы не допустить переоптимизации. Также брать широкий спектр разных сценариев для моделирования.
А вы пробовали использовать Alice AI LLM как замену YandexGPT для уменьшения задержки?
У меня в проверке и оптимизации голосовых интерфейсов хорошо работал подход разделения проблем со звуком (turn detection, interruptions) и проблем с содержанием. Проблемы со звуком нормально можно проверить и вычистить вручную. Для содержания хорошо показало моделирование ситуаций и за юзера отвечает ллм. Моделирование дает транскрипт, ллм критик проверяет транскрипт и дает фидбэк, другой агент меняет промпт и перезапускает. Но все это работает настолько хорошо, насколько хороши промпты моделирования, оценки и изменений. И тут получается подмена задачи оптимизации исходного процесса задачей оптимизации процесса, который оптимизирует. Но вторая задача оказывается все же проще, поэтому оно того стоит.
Я бы немного добавил с точки зрения того, что LLM не даёт. LLM зачастую не умеет правильно абстрагировать реальность, формулировать модель процесса. Поэтому, на мой взгляд, именно умение формулировать модель и объяснять её LLM становится ключевым навыком. Причём модель — это не просто формализация декомпозиции на шаги, но и критерии, которые помогают определять результаты как плохие или хорошие. Зато LLM хорошо умеет следовать построенной модели и проверять себя, используя модель. Модель хорошо встраивается в мультиагентные системы и воркфлоу. Именно умение создавать выразительные модели предметной области/процесса — ключевой навык. А затем уже идут описанные специализации: внедрение ИИ, использование в работе и т. д.
Я не заметил глобальной разницы в том, разные это модели или одинаковые, главное, чтобы они не шарили контекст между собой.
Для критика и генератора важна выстроенная логическая модель, критерии. То есть нельзя абстрактно написать «оцени, хорошо это или плохо», нужно ввести модель оценивания и модель клиента. Как идея, можно брать реальные транскрипты и из них пробовать реконструировать модель пользователя, но я такое не пробовал.
Естественно, если мы вводим какую-то функцию, по которой оптимизируем (критика), то процесс будет оптимизироваться под него. Важно вовремя остановить процесс оптимизации, чтобы не допустить переоптимизации. Также брать широкий спектр разных сценариев для моделирования.
А вы пробовали использовать Alice AI LLM как замену YandexGPT для уменьшения задержки?
У меня в проверке и оптимизации голосовых интерфейсов хорошо работал подход разделения проблем со звуком (turn detection, interruptions) и проблем с содержанием. Проблемы со звуком нормально можно проверить и вычистить вручную. Для содержания хорошо показало моделирование ситуаций и за юзера отвечает ллм. Моделирование дает транскрипт, ллм критик проверяет транскрипт и дает фидбэк, другой агент меняет промпт и перезапускает. Но все это работает настолько хорошо, насколько хороши промпты моделирования, оценки и изменений. И тут получается подмена задачи оптимизации исходного процесса задачей оптимизации процесса, который оптимизирует. Но вторая задача оказывается все же проще, поэтому оно того стоит.