Спасибо. Согласен в целом. Полагаю, кстати, что реальный прорыв (= не нужно финальное слово руководителя, иначе это не совсем прорыв, как по мне) случится только на резервуарных вычислениях, которые имеют шанс дать нам сильный ИИ. На жестких правилах уже пробовали получить полноценный ИИ (GOFAI - без шансов), теперь пробуют на стохастике, где ограничение базовое зашито. Вероятность, что объединение двух ограниченных методов даст качественный скачок выглядит не очень высокой. Хотя текущую ситуацию гибрид может и улучшить.
Интересная информация, спасибо автору. Предположу, что её можно применить и расширительно, пусть и более просто - хоть "на современных моделях проблема может быть уже неактуальна", но для многих, кто использует бесплатные модели типа Gemini 1.5. может быть полезно даже в формулировке запроса на критику указать что-то типа: "Найди недостатки в своём ответе и покритикуй их. Допустима ситуация при которой недостатки не будут найдены и изменения не нужны. В ответе сохраняй размер первоначального ответа, не теряя фокус" (т.е. стараясь обойти все три выявленные структурные проблемы).
Описанное выглядит логично и должно помочь уменьшить рутину и ускорить выполнение задач РП (хотя я бы не стал сейчас оставлять анализ рисков на усмотрение ИИ, особенно в сложных проектах - группы рисков он может оставить в стороне, т.к. понимания контента не хватит. Но относительно описанных выше - даст хорошую экспертную оценку для РП).
Но интересен ещё и другой аспект применения. Ключевым навыком для РП является коммуникация. На неё уходит значительное время. Представим проект, где есть не только разработка, но и интеграция на объекте Заказчика, требующая оформления кучи бумаг для допусков, согласования времени работ и т.д. Чисто технически ИИ с этим справиться должен, но вот доверить ему коммуникацию с Заказчиком без контроля РП или АП (администратора) проекта выглядит рискованным. Одна галлюцинация, и отношения с Заказчиком могут быть сильно испорчены. Как понимаю, пока такое можно сделать всё в том же режиме - все черновики готовятся ИИ, но проверяются РП. Разговоры или переписка с Заказчиком - пока только сам РП. Предположу, что до решения проблемы с галлюцинациями (и, вероятно, это будет уже не LLМ) решение задачи устранения рутинной коммуникации мы не получим. А жаль.
Очень хорошо и полно описано, полезно будет многим интересующимся, полагаю.
Что ещё можно затронуть для расширения полноты: 1) “как LLM "понимает" запрос” (токенизация - эмбеддинги - Attention простыми словами); 2) галлюцинации и почему LLM продолжает галлюцинировать, даже получая от пользователя обратную связь, что LLM галлюцинирует в ответе, и даже логично описывая, что она сделает, чтобы это остановить (и что далее всё равно не делает:-)).
Спасибо. Согласен в целом.
Полагаю, кстати, что реальный прорыв (= не нужно финальное слово руководителя, иначе это не совсем прорыв, как по мне) случится только на резервуарных вычислениях, которые имеют шанс дать нам сильный ИИ.
На жестких правилах уже пробовали получить полноценный ИИ (GOFAI - без шансов), теперь пробуют на стохастике, где ограничение базовое зашито. Вероятность, что объединение двух ограниченных методов даст качественный скачок выглядит не очень высокой. Хотя текущую ситуацию гибрид может и улучшить.
Интересная информация, спасибо автору. Предположу, что её можно применить и расширительно, пусть и более просто - хоть "на современных моделях проблема может быть уже неактуальна", но для многих, кто использует бесплатные модели типа Gemini 1.5. может быть полезно даже в формулировке запроса на критику указать что-то типа: "Найди недостатки в своём ответе и покритикуй их. Допустима ситуация при которой недостатки не будут найдены и изменения не нужны. В ответе сохраняй размер первоначального ответа, не теряя фокус" (т.е. стараясь обойти все три выявленные структурные проблемы).
Описанное выглядит логично и должно помочь уменьшить рутину и ускорить выполнение задач РП (хотя я бы не стал сейчас оставлять анализ рисков на усмотрение ИИ, особенно в сложных проектах - группы рисков он может оставить в стороне, т.к. понимания контента не хватит. Но относительно описанных выше - даст хорошую экспертную оценку для РП).
Но интересен ещё и другой аспект применения. Ключевым навыком для РП является коммуникация. На неё уходит значительное время. Представим проект, где есть не только разработка, но и интеграция на объекте Заказчика, требующая оформления кучи бумаг для допусков, согласования времени работ и т.д. Чисто технически ИИ с этим справиться должен, но вот доверить ему коммуникацию с Заказчиком без контроля РП или АП (администратора) проекта выглядит рискованным. Одна галлюцинация, и отношения с Заказчиком могут быть сильно испорчены. Как понимаю, пока такое можно сделать всё в том же режиме - все черновики готовятся ИИ, но проверяются РП. Разговоры или переписка с Заказчиком - пока только сам РП. Предположу, что до решения проблемы с галлюцинациями (и, вероятно, это будет уже не LLМ) решение задачи устранения рутинной коммуникации мы не получим. А жаль.
Большое спасибо за дополнение к тексту и за дополнительные ссылки. Статья стала ещё полезнее, на мой взгляд.
Очень хорошо и полно описано, полезно будет многим интересующимся, полагаю.
Что ещё можно затронуть для расширения полноты:
1) “как LLM "понимает" запрос” (токенизация - эмбеддинги - Attention простыми словами);
2) галлюцинации и почему LLM продолжает галлюцинировать, даже получая от пользователя обратную связь, что LLM галлюцинирует в ответе, и даже логично описывая, что она сделает, чтобы это остановить (и что далее всё равно не делает:-)).