О! Точно! Последний раз я держал в руках диск с МРТ. Правда, за чем он мне нужен, я так и не понял. Результаты были доступны врачу во внутренней системе поликлиники.
LLM не обладает пониманием инженера — она обладает статистической уверенностью, которая может быть катастрофически ошибочной. Человеческое «ничего не понял, надо уточнить» — это не баг, а важнейший механизм верификации, основанный на реальном понимании предметной области. LLM же с абсолютно одинаковой уверенностью сгенерирует и гениальный краевой кейс, и тест, проверяющий деление на ноль через сакральный смысл числа 42, если это коррелирует с её обучающей выборкой.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели. И то, что написание тестов вы отдадите другому ИИ ровным счетом ничего не меняет.
Утверждение, что агент «возвращает только нужное, безо всяких промежуточных этапов», выдает непонимание природы LLM-агентов в продакшене. Вы называете «мусором» ту самую цепочку рассуждений, которая, является единственным способом для LLM решать сложные задачи с приемлемой точностью. Агент не «шуршит», фильтруя мусор, — он галлюцинирует на каждом промежуточном шаге. Проблема «основного контекста» никуда не исчезает: она просто переносится в контекст агента, где, благодаря многоагентности, ошибки накапливаются, а возможность человека проконтролировать логику стремиться к нулю.
Ну и главное: сравнение с человеком, который «не помнит каждую строчку кодовой базы», некорректно. Человек не помнит код, но он хранит ментальную модель системы. Он знает, почему модуль А не должен вызывать модуль Б напрямую, потому что полгода назад это приводило к гонке состояний. LLM не помнит синтаксис и не строит ментальную модель. Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Проблема не в том, кем написан тест, а в том, что вы делегируете машине верификацию истинности, на которую у машины нет ни права, ни способностей.
А кто-то еще пользуется дисками, кроме консольщиков? Я уже и забыл, когда последний раз в руках держал CD или DVD. Где-то в закромах валяется внешний привод, но ни на одном компе, ноутбуте их давно уже нет.
А вы знаете, это прекрасный вопрос. Для меня он полностью закрывает необходимость дальнейшей дискусси.
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый. По этому LLM оперирует энтропией, а не "понятностью".
Юнит тесты для проверки ИИ, которые пишет сам ИИ? Это способ самоуспокоения и к проверке кода имеет весьма касательное отношение. И даже 100% покрытие тестами написанными ИИ не даст гарантии, что код правильный.
Проблема ИИ, не в том, что ИИ ошибается. Проблема в том, что ИИ прячет ошибку за правдоподобным кодом. И на синтетических тестах (даже написанных вручную) все может работать, а продавшее - ломаться.
Почему я пытаюсь ограничить LLM? Да потому, что контекст LLM, даже со всеми ухищрениями, сильно меньше контекста человека. Если ИИ скормить слишком много информации, он начинает ее сжимать. А это чревато тем, что важные требования могут оказаться потеряны, а ИИ сосредоточится на второстепенных. Примеров этому достаточно много даже здесь.
ИИ не задает вопросы, потому что ему непонятно. Он задает их, потому что в его настройках прописано: «Если энтропия запроса выше X%, возьми три наиболее частых неоднозначности из обучающей выборки и сформулируй их как вопросы».
ИИ может остановиться и указать на ошибку. Но не потому, что понял логику, а потому что:
В обучающей выборке были похожие баги, и он запомнил паттерн ошибки.
У него есть встроенный валидатор.
Он сопоставил ваш код с известной проблемой.
Если вы дадите ему уникальную архитектурную задачу, которой нет в интернете, он не остановится. Он спокойно напишет красивый код, который упадет в рантайме, потому что он не просчитывает последствия на 10 шагов вперед.
Это не решает те ограничения о которых говорилось выше. Это не решает проблему потери середины. Это не решает проблему контекста. Это не решает много других проблем. Это решает лишь проблему поиска и анализа небольшого объема данных на большом объеме кодовой базы. Да инструмент полезный, но очень ограниченный.
Меня всегда умиляет слово "понимает" в привязке к ИИ.
Мой нож понимает как разделать мясо. Мой автомобиль понимает ПДД. А самолет понимает аэродинамику. А мой компьютер вообще все понимает, он очень начитанный, у него куча книг на жестком диске.
Код и бизнес логика это хоть и связанные, но разные задачи. Код это ответственность программиста. Бизнес-логика - архитектора(аналитика) и заказчика. Но это именно зона ответственности.
У меня программисты вполне себе разбираются в бизнес логике которую реализуют. Умеют критически оценивать запросы пользователей и задавать вопросы.
ИИ же, в принципе, не разбирается в предметной области. Ни в какой. Он знает некоторые шаблонные решения, да и то, если они опубликованы в интернете. Но не более.
Если человек видит и задает вопросы, когда что-то не укладывается в его знание процесса. То, ИИ не будет ничего "уточнять". Он просто реализует. И даже если его попросить проанализировать, он не найдет ошибок бизнес-логики. Он сможет найти только отличия от известных ему шаблонов.
Это называется: бумага все стерпит. Вы можете писать о себе все что хотите. Что вы пинками дверь к директору открываете. Что он ГД во всем с вами советуется. Что личного шофера отправляет за вами, когда что-то не работает... Никто это все равно проверять не будет.
А реальност она совсем другая. Если ваше "ядро" не будет удовлетворять бизнес, на все ваши рассказы про математичность ядра, про грязые руки и прочее... никто не посмотрит. И будете вы переписывать свое ядро не так, что бы было красиво, а так что бы бизнес был доволен.
Разные реальности — это удобная отмазка для тех, кто не хочет признавать, что его "красивые алгоритмы" решают не ту задачу. Бизнес-логика — это не грязь, это критерий истины. Если твой код не приносит деньги и не решает проблемы пользователя, это просто коллекция абстракций в вакууме.
Вот вы занимаетесь передергиванием, а в суть сказанного не вникаете.
Если вместо 10 программистов будут работать 5 - это оптимизация. А если вместо 10 программистов будет работать 5 операторов - это замена. Потому что квалификация программиста несоизмерима выше квалификации оператора.
Потому, что программист сможет "надавать по рукам LLM", когда она сморозит глупость. А оператор даже не поймет, то она сморозила глупость.
"И не надо говорить про другую LLM. Ей все равно понадобится дополнительный контекст, который не был озвучен на совещании, но присутствует в головах участников. "
Читать код сложнее. Это очевидно.
Хех... какая наивность. Я то еще помню те времена, когда некоторые заводские диски оказались с вирусом.
Ну и DVD+/-R где-то все таки записывали. Так что получить на диск вирус - вполне возможно.
О! Точно! Последний раз я держал в руках диск с МРТ. Правда, за чем он мне нужен, я так и не понял. Результаты были доступны врачу во внутренней системе поликлиники.
LLM не обладает пониманием инженера — она обладает статистической уверенностью, которая может быть катастрофически ошибочной. Человеческое «ничего не понял, надо уточнить» — это не баг, а важнейший механизм верификации, основанный на реальном понимании предметной области. LLM же с абсолютно одинаковой уверенностью сгенерирует и гениальный краевой кейс, и тест, проверяющий деление на ноль через сакральный смысл числа 42, если это коррелирует с её обучающей выборкой.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели. И то, что написание тестов вы отдадите другому ИИ ровным счетом ничего не меняет.
Утверждение, что агент «возвращает только нужное, безо всяких промежуточных этапов», выдает непонимание природы LLM-агентов в продакшене. Вы называете «мусором» ту самую цепочку рассуждений, которая, является единственным способом для LLM решать сложные задачи с приемлемой точностью. Агент не «шуршит», фильтруя мусор, — он галлюцинирует на каждом промежуточном шаге. Проблема «основного контекста» никуда не исчезает: она просто переносится в контекст агента, где, благодаря многоагентности, ошибки накапливаются, а возможность человека проконтролировать логику стремиться к нулю.
Ну и главное: сравнение с человеком, который «не помнит каждую строчку кодовой базы», некорректно. Человек не помнит код, но он хранит ментальную модель системы. Он знает, почему модуль А не должен вызывать модуль Б напрямую, потому что полгода назад это приводило к гонке состояний. LLM не помнит синтаксис и не строит ментальную модель. Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Проблема не в том, кем написан тест, а в том, что вы делегируете машине верификацию истинности, на которую у машины нет ни права, ни способностей.
А кто-то еще пользуется дисками, кроме консольщиков? Я уже и забыл, когда последний раз в руках держал CD или DVD. Где-то в закромах валяется внешний привод, но ни на одном компе, ноутбуте их давно уже нет.
А вы знаете, это прекрасный вопрос. Для меня он полностью закрывает необходимость дальнейшей дискусси.
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый. По этому LLM оперирует энтропией, а не "понятностью".
Юнит тесты для проверки ИИ, которые пишет сам ИИ? Это способ самоуспокоения и к проверке кода имеет весьма касательное отношение. И даже 100% покрытие тестами написанными ИИ не даст гарантии, что код правильный.
Проблема ИИ, не в том, что ИИ ошибается. Проблема в том, что ИИ прячет ошибку за правдоподобным кодом. И на синтетических тестах (даже написанных вручную) все может работать, а продавшее - ломаться.
Почему я пытаюсь ограничить LLM? Да потому, что контекст LLM, даже со всеми ухищрениями, сильно меньше контекста человека. Если ИИ скормить слишком много информации, он начинает ее сжимать. А это чревато тем, что важные требования могут оказаться потеряны, а ИИ сосредоточится на второстепенных. Примеров этому достаточно много даже здесь.
Какой вы самокритичный... ну раз не понимаете, то и ладно.
ИИ не задает вопросы, потому что ему непонятно. Он задает их, потому что в его настройках прописано: «Если энтропия запроса выше X%, возьми три наиболее частых неоднозначности из обучающей выборки и сформулируй их как вопросы».
ИИ может остановиться и указать на ошибку. Но не потому, что понял логику, а потому что:
В обучающей выборке были похожие баги, и он запомнил паттерн ошибки.
У него есть встроенный валидатор.
Он сопоставил ваш код с известной проблемой.
Если вы дадите ему уникальную архитектурную задачу, которой нет в интернете, он не остановится. Он спокойно напишет красивый код, который упадет в рантайме, потому что он не просчитывает последствия на 10 шагов вперед.
Это не решает те ограничения о которых говорилось выше. Это не решает проблему потери середины. Это не решает проблему контекста. Это не решает много других проблем. Это решает лишь проблему поиска и анализа небольшого объема данных на большом объеме кодовой базы. Да инструмент полезный, но очень ограниченный.
Меня всегда умиляет слово "понимает" в привязке к ИИ.
Мой нож понимает как разделать мясо. Мой автомобиль понимает ПДД. А самолет понимает аэродинамику. А мой компьютер вообще все понимает, он очень начитанный, у него куча книг на жестком диске.
RAG не снимает ограничения ИИ. Он обходит некоторые, но не всегда успешно.
Код и бизнес логика это хоть и связанные, но разные задачи. Код это ответственность программиста. Бизнес-логика - архитектора(аналитика) и заказчика. Но это именно зона ответственности.
У меня программисты вполне себе разбираются в бизнес логике которую реализуют. Умеют критически оценивать запросы пользователей и задавать вопросы.
ИИ же, в принципе, не разбирается в предметной области. Ни в какой. Он знает некоторые шаблонные решения, да и то, если они опубликованы в интернете. Но не более.
Если человек видит и задает вопросы, когда что-то не укладывается в его знание процесса. То, ИИ не будет ничего "уточнять". Он просто реализует. И даже если его попросить проанализировать, он не найдет ошибок бизнес-логики. Он сможет найти только отличия от известных ему шаблонов.
Это называется: бумага все стерпит. Вы можете писать о себе все что хотите. Что вы пинками дверь к директору открываете. Что он ГД во всем с вами советуется. Что личного шофера отправляет за вами, когда что-то не работает... Никто это все равно проверять не будет.
А реальност она совсем другая. Если ваше "ядро" не будет удовлетворять бизнес, на все ваши рассказы про математичность ядра, про грязые руки и прочее... никто не посмотрит. И будете вы переписывать свое ядро не так, что бы было красиво, а так что бы бизнес был доволен.
Но вы продолжайте в себя верить.
Ох уж эти сказки, ох уж эти сказочники...
А причем тут программисты? Речь шла об умении ИИ проверять бизнес логику.
Но, вообще-то, для человека разбирающегося в предметной области, это повод задать вопрос бизнесу, нет ли тут ошибки. ИИ на это внимания не обратит.
Разные реальности — это удобная отмазка для тех, кто не хочет признавать, что его "красивые алгоритмы" решают не ту задачу. Бизнес-логика — это не грязь, это критерий истины. Если твой код не приносит деньги и не решает проблемы пользователя, это просто коллекция абстракций в вакууме.
Вот вы занимаетесь передергиванием, а в суть сказанного не вникаете.
Если вместо 10 программистов будут работать 5 - это оптимизация. А если вместо 10 программистов будет работать 5 операторов - это замена. Потому что квалификация программиста несоизмерима выше квалификации оператора.
Потому, что программист сможет "надавать по рукам LLM", когда она сморозит глупость. А оператор даже не поймет, то она сморозила глупость.
Ответили на то что вам удобно, а все остальное проигнорировали... Не удивлен.
Нет, это вы не внимательно меня читали.
"И не надо говорить про другую LLM. Ей все равно понадобится дополнительный контекст, который не был озвучен на совещании, но присутствует в головах участников. "
Не лучше. Меньше. Причем в разы.