Остановился на описании уровней в "Давайте сразу договоримся, что ИИ никакой не интеллект и никогда им не стане". Так как далее понятие ИИ во всех трех уровнях "разрывов" сужено, в основном, до текущей реализации на LLM.
Так что, нет, не договоримся. Есть много других возможных путей развития. Например, резервуарные вычисления, которым упоминаемая ТАР близка.
Я к тому, что, судя по всему, это очень дорого пока получается - и вычислительная сложность высока и очистка "мусора" сложна и нетривиальна. Скорее, именно поэтому и не собрали.
В том, что описанный Вами путь рабочий, особых сомнений нет. И описание хорошее и интересное. Только вопрос, так как статья Ваша не просто описательная, а с фокусом на новизну: Вы не проверяли, действительно ли предложенное Вами содержит эту существенную новизну?
На мой взгляд, основная проблема не в отсутствии алгоритмического подхода к созданию дата-сета (достаточно простого подхода в Вашем вполне логичном описании), а в экономической эффективности обеспечения вычислительной сложности этого процесса и контроле качества данных из Git-Hub (что является задачей сложной и, веротяно, дорогой).
Если выбрана транскрипция "kNN", то лучше бы её и придерживаться - "смело сказать 1NN ", а не "смело сказать 1-NN". Чтобы читатель не искал ненужный глубинный смысл в формуле: "1-NN".
Вывод про экономику: решая, делать ли сотруднику самому в рабочее время или отдавать на внешний продакшн - выглядит пока как выбор в пользу внешнего выполнения задачи.
Пояснение: Как я понял, внешний продакшн = 200 000 ("с пятью нулями, первая - не единица"). Здесь же получилось 12 000 + 80 часов сверхурочных явно не самого недорогого сотрудника (пусть их никто и не собирается платить), да ещё и с "усталость, раздражение".
P.s. Не знаю, стоила ли того внутренняя премия. Если удовольствие получено в результате, то стоила, наверное.
Вы, безусловно, правы в описании работы LLМ, только не очень ясно, где Вы видите противоречие между Вашим комментарием и общим посылом статьи автора выше. Как я вижу, они хорошо друг друга дополняют. Автор же не фокусируется в статье на возможностях LLМ. Он про умение их использовать говорит. "запустить пайплайн прояснения" под это тоже подпадает. Ведь его запуск это не просто: "а теперь выполни-ка мне Ambiguity Resolution и напиши-ка всё, что вы, ИИ, там обычно пишете"... Gemini 2.5 имеет Ambiguity Resolution встроенным, но с выученной установкой давать "полезные" ответы она их и выдаст, не прерывая генерацию и не загружая спрашивающего своими уточнениями. Для поиска ошибок в задаче её прямо спросить о таком было надо (как я Вас понял, Вы тоже это имели в виду под "проблемой промптов"), а для этого (и для продолжения диалога) и должно у менеджера быть критическое мышление.
Относительно "общаться с LLM на английском " с точки зрения точности: в 2025 году исследование University of Maryland, UMass Amherst и Microsoft показало, что английский всего лишь на шестом месте. Русский, например, его опередил. Так что из-за точности английский нет особого смысла брать. А вот из-за стоимости - да. Известный факт, что русский более токенов требует, чем английский.
Интересно. Два небольших комментария: 1) "Цена: судебный прецедент + серьёзный удар по репутации. " - не совсем так. Цена ошибки ИИ - 800 CAD. А суд и репутация - цена ошибки руководителя, который решил в морально спорной ситуации судиться. 2) "Креативные ассистенты (стихи, идеи). Выдуманная метафора не подсудна." - полагаю, что лучше тут паттерн иметь. Если, например, ассистент начнёт восхвалять что-то запрещённое, то как раз судом может и закончиться в полном соответствии с законом.
Спасибо. Согласен в целом. Полагаю, кстати, что реальный прорыв (= не нужно финальное слово руководителя, иначе это не совсем прорыв, как по мне) случится только на резервуарных вычислениях, которые имеют шанс дать нам сильный ИИ. На жестких правилах уже пробовали получить полноценный ИИ (GOFAI - без шансов), теперь пробуют на стохастике, где ограничение базовое зашито. Вероятность, что объединение двух ограниченных методов даст качественный скачок выглядит не очень высокой. Хотя текущую ситуацию гибрид может и улучшить.
Интересная информация, спасибо автору. Предположу, что её можно применить и расширительно, пусть и более просто - хоть "на современных моделях проблема может быть уже неактуальна", но для многих, кто использует бесплатные модели типа Gemini 1.5. может быть полезно даже в формулировке запроса на критику указать что-то типа: "Найди недостатки в своём ответе и покритикуй их. Допустима ситуация при которой недостатки не будут найдены и изменения не нужны. В ответе сохраняй размер первоначального ответа, не теряя фокус" (т.е. стараясь обойти все три выявленные структурные проблемы).
Описанное выглядит логично и должно помочь уменьшить рутину и ускорить выполнение задач РП (хотя я бы не стал сейчас оставлять анализ рисков на усмотрение ИИ, особенно в сложных проектах - группы рисков он может оставить в стороне, т.к. понимания контента не хватит. Но относительно описанных выше - даст хорошую экспертную оценку для РП).
Но интересен ещё и другой аспект применения. Ключевым навыком для РП является коммуникация. На неё уходит значительное время. Представим проект, где есть не только разработка, но и интеграция на объекте Заказчика, требующая оформления кучи бумаг для допусков, согласования времени работ и т.д. Чисто технически ИИ с этим справиться должен, но вот доверить ему коммуникацию с Заказчиком без контроля РП или АП (администратора) проекта выглядит рискованным. Одна галлюцинация, и отношения с Заказчиком могут быть сильно испорчены. Как понимаю, пока такое можно сделать всё в том же режиме - все черновики готовятся ИИ, но проверяются РП. Разговоры или переписка с Заказчиком - пока только сам РП. Предположу, что до решения проблемы с галлюцинациями (и, вероятно, это будет уже не LLМ) решение задачи устранения рутинной коммуникации мы не получим. А жаль.
Очень хорошо и полно описано, полезно будет многим интересующимся, полагаю.
Что ещё можно затронуть для расширения полноты: 1) “как LLM "понимает" запрос” (токенизация - эмбеддинги - Attention простыми словами); 2) галлюцинации и почему LLM продолжает галлюцинировать, даже получая от пользователя обратную связь, что LLM галлюцинирует в ответе, и даже логично описывая, что она сделает, чтобы это остановить (и что далее всё равно не делает:-)).
Сейчас есть бумажная. Но черно-белая, судя по карточке товара, хотя диаграмма выше - цветная. А вот электронные кончились у них, да:-)
Остановился на описании уровней в "Давайте сразу договоримся, что ИИ никакой не интеллект и никогда им не стане". Так как далее понятие ИИ во всех трех уровнях "разрывов" сужено, в основном, до текущей реализации на LLM.
Так что, нет, не договоримся. Есть много других возможных путей развития. Например, резервуарные вычисления, которым упоминаемая ТАР близка.
По текущим российским рейтингам научных публикаций публикации зарубежные выше оцениваются.
Я к тому, что, судя по всему, это очень дорого пока получается - и вычислительная сложность высока и очистка "мусора" сложна и нетривиальна. Скорее, именно поэтому и не собрали.
В том, что описанный Вами путь рабочий, особых сомнений нет. И описание хорошее и интересное.
Только вопрос, так как статья Ваша не просто описательная, а с фокусом на новизну: Вы не проверяли, действительно ли предложенное Вами содержит эту существенную новизну?
На мой взгляд, основная проблема не в отсутствии алгоритмического подхода к созданию дата-сета (достаточно простого подхода в Вашем вполне логичном описании), а в экономической эффективности обеспечения вычислительной сложности этого процесса и контроле качества данных из Git-Hub (что является задачей сложной и, веротяно, дорогой).
Если выбрана транскрипция "kNN", то лучше бы её и придерживаться - "смело сказать 1NN ", а не "смело сказать 1-NN". Чтобы читатель не искал ненужный глубинный смысл в формуле: "1-NN".
Вывод про экономику: решая, делать ли сотруднику самому в рабочее время или отдавать на внешний продакшн - выглядит пока как выбор в пользу внешнего выполнения задачи.
Пояснение:
Как я понял, внешний продакшн = 200 000 ("с пятью нулями, первая - не единица"). Здесь же получилось 12 000 + 80 часов сверхурочных явно не самого недорогого сотрудника (пусть их никто и не собирается платить), да ещё и с "усталость, раздражение".
P.s. Не знаю, стоила ли того внутренняя премия. Если удовольствие получено в результате, то стоила, наверное.
Вы, безусловно, правы в описании работы LLМ, только не очень ясно, где Вы видите противоречие между Вашим комментарием и общим посылом статьи автора выше. Как я вижу, они хорошо друг друга дополняют.
Автор же не фокусируется в статье на возможностях LLМ. Он про умение их использовать говорит. "запустить пайплайн прояснения" под это тоже подпадает. Ведь его запуск это не просто: "а теперь выполни-ка мне Ambiguity Resolution и напиши-ка всё, что вы, ИИ, там обычно пишете"...
Gemini 2.5 имеет Ambiguity Resolution встроенным, но с выученной установкой давать "полезные" ответы она их и выдаст, не прерывая генерацию и не загружая спрашивающего своими уточнениями. Для поиска ошибок в задаче её прямо спросить о таком было надо (как я Вас понял, Вы тоже это имели в виду под "проблемой промптов"), а для этого (и для продолжения диалога) и должно у менеджера быть критическое мышление.
Относительно "общаться с LLM на английском " с точки зрения точности: в 2025 году исследование University of Maryland, UMass Amherst и Microsoft показало, что английский всего лишь на шестом месте. Русский, например, его опередил. Так что из-за точности английский нет особого смысла брать.
А вот из-за стоимости - да. Известный факт, что русский более токенов требует, чем английский.
Интересно.
Два небольших комментария:
1) "Цена: судебный прецедент + серьёзный удар по репутации. " - не совсем так. Цена ошибки ИИ - 800 CAD. А суд и репутация - цена ошибки руководителя, который решил в морально спорной ситуации судиться.
2) "Креативные ассистенты (стихи, идеи). Выдуманная метафора не подсудна." - полагаю, что лучше тут паттерн иметь. Если, например, ассистент начнёт восхвалять что-то запрещённое, то как раз судом может и закончиться в полном соответствии с законом.
Спасибо. Согласен в целом.
Полагаю, кстати, что реальный прорыв (= не нужно финальное слово руководителя, иначе это не совсем прорыв, как по мне) случится только на резервуарных вычислениях, которые имеют шанс дать нам сильный ИИ.
На жестких правилах уже пробовали получить полноценный ИИ (GOFAI - без шансов), теперь пробуют на стохастике, где ограничение базовое зашито. Вероятность, что объединение двух ограниченных методов даст качественный скачок выглядит не очень высокой. Хотя текущую ситуацию гибрид может и улучшить.
Интересная информация, спасибо автору. Предположу, что её можно применить и расширительно, пусть и более просто - хоть "на современных моделях проблема может быть уже неактуальна", но для многих, кто использует бесплатные модели типа Gemini 1.5. может быть полезно даже в формулировке запроса на критику указать что-то типа: "Найди недостатки в своём ответе и покритикуй их. Допустима ситуация при которой недостатки не будут найдены и изменения не нужны. В ответе сохраняй размер первоначального ответа, не теряя фокус" (т.е. стараясь обойти все три выявленные структурные проблемы).
Описанное выглядит логично и должно помочь уменьшить рутину и ускорить выполнение задач РП (хотя я бы не стал сейчас оставлять анализ рисков на усмотрение ИИ, особенно в сложных проектах - группы рисков он может оставить в стороне, т.к. понимания контента не хватит. Но относительно описанных выше - даст хорошую экспертную оценку для РП).
Но интересен ещё и другой аспект применения. Ключевым навыком для РП является коммуникация. На неё уходит значительное время. Представим проект, где есть не только разработка, но и интеграция на объекте Заказчика, требующая оформления кучи бумаг для допусков, согласования времени работ и т.д. Чисто технически ИИ с этим справиться должен, но вот доверить ему коммуникацию с Заказчиком без контроля РП или АП (администратора) проекта выглядит рискованным. Одна галлюцинация, и отношения с Заказчиком могут быть сильно испорчены. Как понимаю, пока такое можно сделать всё в том же режиме - все черновики готовятся ИИ, но проверяются РП. Разговоры или переписка с Заказчиком - пока только сам РП. Предположу, что до решения проблемы с галлюцинациями (и, вероятно, это будет уже не LLМ) решение задачи устранения рутинной коммуникации мы не получим. А жаль.
Большое спасибо за дополнение к тексту и за дополнительные ссылки. Статья стала ещё полезнее, на мой взгляд.
Очень хорошо и полно описано, полезно будет многим интересующимся, полагаю.
Что ещё можно затронуть для расширения полноты:
1) “как LLM "понимает" запрос” (токенизация - эмбеддинги - Attention простыми словами);
2) галлюцинации и почему LLM продолжает галлюцинировать, даже получая от пользователя обратную связь, что LLM галлюцинирует в ответе, и даже логично описывая, что она сделает, чтобы это остановить (и что далее всё равно не делает:-)).