Там скорее про AGI в математическом плане, так как тут два лагеря:
AGI как система, способная понять абсолютно всё Такую трактовку использует Шлерет. AGI это универсальная система, способная охватить все возможные данные и концепты. Если мы следуем этому определению, то, как утверждает Шлерет, AGI невозможен: алгоритмические системы ограничены семантическим алфавитом и не могут индуктивно выйти за пределы своего (Semantic Closure), особенно в условиях тяжёлых хвостов (α ≤ 1), когда энтропия расходится.
AGI как выдающаяся обобщающая система (человеко-подобная) Если AGI понимать как систему, способную разумно обобщать данные, учиться, адаптироваться в широком диапазоне задач (человеко‑подобный интеллект, но не всесильная модель), то такая AGI может быть теоретически достижима. Этот подход соответствует определению AGI как способности обобщения и адаптации в разнообразных средах, например, как способность учиться и адаптироваться к новым задачам.
Если AGI требует бесконечного символического охвата, то согласно Шлерету, это невозможно.
Если же AGI это скорее человеческий интеллект, способный обрабатывать широкий класс задач, тогда Шлерет лишь указывает, что алгоритмические модели имеют пределы, но уже такие системы могут приближаться к человеческой универсальности.
Поэтому если называть AGI в рамках теоремы Шлерет, то человек сам по себе не способен охватить абсолютно всё, значит человек тоже не является AGI в строгом смысле первой трактовки. Таким образом AGI невозможен если нужен абсолютный охват.
AGI возможен в практическом смысле человеческой универсальности и человек, и алгоритмы могут быть ограниченно универсальны.
Так что выводы Шлерета не оспаривают возможность создания систем, схожих с человеческим интеллектом, но ставят под сомнение концепт AGI как всемогущего оракула, который охватывает всё.
Но изначально была речь про интерпретацию теоремы в рамках галлюцинаций (в рамка поста выше), а она к ним не имеет отношения, об этом я и указал.
Там под AGI подразумевается немного другое. Условно говоря система, которая может описать все что только возможно, то есть любую сложность. Поэтому эту теорему критиковали, так как аргумент был что мозг это AGI. Но автор теоремы все таки говорил там о другом. То есть словами теоремы, наш мог тоже не может обобщать бесконечно и поэтому имеет ограничение по предсказанию/аппроксимации/описанию. Подозреваю, что в теореме фигурирует AGI в данной формулировке, по той причине, что было много обещаний, что появиться AGI и сможет объяснить все на свете.
Не знаю, на сколько Владимир Крылов силен в математике, думаю что достаточно хорошо. Но то что она написал это каша, и интерполировать некоторые субъективные представления без доказательств на LLM, как минимум не профессионально.
Множество всех функций континуально, вычислимых - счётно, мера вычислимых равна нулю
В реальности LLM никогда не аппроксимируют произвольные функции. Они работают внутри фиксированного класса параметризованных функций. Это конечномерные, вычислимые, гладкие отображения. Мы здесь не ищем произвольную функцию. Наша задача аппроксимировать условное распределение языка, а не функцию Z→Z. Аргумент про "меру ноль" ничего не говорит об обучаемости, аппроксимации, обобщении, вероятностных моделях.
сам механизм attention неизбежно содержит появление галлюцинаций
Это просто неверно. Attention линейный по V, детерминированный, полностью вычислимый, не вводит ошибок сам по себе. Галлюцинации прекрасно возникают и без attention (RNN, n-gram), в байесовских моделях, в любом генеративном вероятностном процессе. Attention не причина, это формально "усилитель уверенности".
Галлюцинация не дефект архитектуры
Частично верно, но сказано в неверной формулировке. Более правильно было бы сказать, что галлюцинации это следствие постановки задачи как вероятностного языкового моделирования, а не конкретно трансформеров или attention. Более того, есть множество видов галлюцинаций, которые имеют разные причины и проявляются схожим образом.
Для примера делал разбор, как это у мозга. Даже у краткого частичного описания этого явления, можно понять, что причин существует множество. А существующие архитектуры, не охватывают/учитывают многие моменты.
Это означает, что модель не оптимизируется на истинность, не оптимизируется на выполнимость, не оптимизируется на корректность логического вывода, а только на правдоподобие продолжения. В этом смысле галлюцинация это естественный режим работы модели, когда данных недостаточно, сигнал слабый, распределение неоднозначно, или запрос лежит вне обучающего распределения. Но это не имеет никакого отношения к невычислимым функциям, Тьюрингу и мерам множеств.
теорема о неизбежной ошибке: для любого вычислительно перечислимого множества найдётся вход, на котором модель ошибётся
Это по сути переформулировка теоремы Райса, следствия неразрешимости. Формально верно, но логически вообще не связано с галлюцинациями.
Теорема говорит о точном вычислении функций. LLM не претендуют на точность, они оптимизируют ожидаемую правдоподобность, а не универсальную корректность. По этой логике любой калькулятор галлюцинирует, потому что есть входы вне его спецификации. Это подмена понятий.
Возможно он имел ввиду теорему AGI is Impossible. Here is the Proof. The Infinite Choice Barrier and a New Critique of Artificial Reason. Author: Max M. Schlereth. Не знаю как Крылов, но очень подробно изучал эту работу, так как она была связана с другими нужными мне математическими теоремами. Формально она говорит:
Существует класс задач рассуждения, в которых агенту требуется сделать выбор из неограниченного (неперечислимого или неограниченно растущего) множества альтернатив, без априорного алгоритмического критерия остановки.
Формально это близко к неразрешимости, отсутствию эффективной процедуры выбора, или отсутствию вычислимого функционала оптимальности. Это своего рода вариация аргументов Гёделя, Райса и анти-формалистских аргументов Пенроуза. Но тут важно, что Schlereth говорит о принципиальной невозможности универсального разума, а не об ошибках в конкретных ответах. поэтому если упоминается она, то это натягивание совы на глобус и подмена понятий.
Потому что галлюцинация это уверенный вывод при недостаточной информации, в рамках вероятностного генератора. А ICB это невозможность алгоритмического выбора в бесконечном пространстве альтернатив, даже в идеальных условиях.
Если совсем кратко, то разница в том, что галлюцинации не следствие невозможности выбора, а следствие принуждения к выбору там, где оптимально было бы воздержаться.
Про 33–48% галлюцинаций у reasoning-моделей, здесь он частично прав, но формулирует это как-то криво. Если описывать причину понятно и правильно, то reasoning это длинная цепочка. Она приводит к тому, что вероятность ошибки растёт экспоненциально. То есть по факту это накопление ошибки, а не парадокс рассуждений. Именно об этом я и писал в комментарии ранее:
как об одном конкретном виде галлюцинаций, который приводит к накоплению ошибки и в итоге это проявляется как сдвиг. А так же почему он происходит и как его минимизировать.
Как математик он вроде говорит корректные вещи. Но как специалист по ИИ он явно путает вычислимость и обобщение, подменяет задачу, использует нерелевантные теоремы, не понимает оптимизационную природу LLM. То что я вижу, это ответ человека, который знает теорию вычислимости, но не понимает что именно оптимизируют LLM.
Если следовать его цепочке рассуждения, то AGI невозможно из-за Infinite Choice Barrier => LLM частичный AGI => Следовательно, ошибки LLM (галлюцинации) фундаментальны.
Но на основе ICB, мы можем говорит только о существовании нерешаемых задач, но галлюцинации возникают на решаемых, конечных задачах из-за того, что модель обязана генерировать ответ.
Это хороший вопрос. И ответа у меня на него нет. Надо проводить эксперименты и исследовать это, что в текущих классических архитектурах LLM более оптимально делать в этом случае: завершать генерацию как аналог токена EOS, выдавать признак что "не знаю" или какой-то маркер об этом, или добавлять текст как это делают при CoT вроде "но если подумать с другой стороны" или подобный или же еще что-то. Это надо собирать данные, смотреть на множестве текстов, которые имеют такое окончание. Но как минимум я бы такие места выделял маркеров, чтобы при чтении текста было понятно, что в этом месте модель выбрала ответ случайным образом и не может гарантировать его правильность. Так хотя бы будет понятно, стоит ли доверять данному ответу или нет и это не сложно реализовать на уровне классических LLM.
На самом деле описанную выше ситуацию получить очень легко. Я постоянно ее получаю, так как анализирую генерируемые тексты в процессе обучения моделей. В процессе обучения, тексты содержат много шума, так как модель еще не обучена, но оценить результат надо. Так вот, после того как отдаешь такой шумный текст на анализ, ChatGpt, Gemini, deepSeek, Qwen и другие начинают сыпаться. Они продолжают генерировать связанный текст, но в нем появляются "опечатки", английские буквы внутри русских слов, нарушается контекст и модель не может правильно связать более ранние части нормального текста. Так как когда мы добавляем шумный текст, то пытаемся продолжить генерировать шум. Вот тоже самое возникает в ситуации описанной выше, только по причине выбора шумного токена.
Где это следует из архитектуры трансформеров? Наоборот, из архитектуры трансформеров следует, что это иерархические цепи Маркова. вы понимаете что такое цепь Маркова? Это последовательность условных вероятностей, а ни какая то химера.
Иерархическая - это значит что цепочки условных вероятностей связаны цепочками верхнего уровня, тоже цепей условных вероятностей. Сам разрыв связан с ограниченностью системы интерпретации результата связанный с ее "точностью".
Откуда вы взяли это(?):
Это следует из архитектуры трансформеров и практики масштабирования: связность обеспечивается attention и контекстом.
Разложите attention по блокам и получите связанную цепь Маркова, как на схеме выше.
Раз для понимания, судя по ответам вы используете LLM или не до конца понимает как устроены трансформеры. То вот прогоните теоремы в порядке их следования через LLM: https://disk.yandex.ru/d/pNjCRp-hpS1ywg
Дело в самой природе того, как работают эти системы. Модель учится на огромных массивах текста, пытаясь найти закономерности. Но она не может со стопроцентной точностью разделить правду и ложь - для нее это всего лишь статистические паттерны. Команда OpenAI в своем исследовании показала: даже если дать модели безупречно чистые данные без единой ошибки, она все равно будет время от времени врать. Это не баг, а особенность самого принципа обучения таких систем.
Это во первых. На текущей архитектуре вы от этого не избавитесь. Во вторых в статье речь идет о другой форме проблемы галлюцинаций - это когда модель не знает. Это две разные проблемы галлюцинаций. Одна когда мы продолжаем генерацию шума, и другая когда встречаемся с ситуацией, что все варианты на уровне шума. В цитате из статьи выше, как раз об этом. Что в современных LLM нет механизма для разрешения галлюцинаций, в ситуации когда все варианты на уровне шума.
Где они выяснили причину? Вы понимаете, что обучая модель на разных диалогах, где так же есть "не знаю", модель получает представление о таких ответах. О каких нулях баллах идет речь? Модель обучается по Loss. Если говорить о рассуждениях, так это дообучение модели, где может быть регуляризация. Модели без разницы, что она ответит. Что будет вероятно то и ответит. Вы путаете обучение с регуляризацией с жестко заточенным алгоритмом и неопределенностью. Если вы вводите регуляризацию, то можете выбрать любой критерий. Хоть частое вручающийся символ "А". Только это не имеет отношения к состоянию неопределённости. Вы смотрели ту работу, на чем она была построена.
Если бы все было так просто, то галлюцинаций в ChatGPT не было бы. И он умел отвечать "я не знаю" самостоятельно.
Вы в этом уверены? Можете привести не абстрактные аргументы, а конкретные?
Кто вам сказал, что иначе бы не работали. в большинстве случаев глобальная цепь Маркова не нарушается. Во вторых, небольшие шумы не приводят к неустойчивости иерархии.
Стандартный BPE токенизатор.
Токенизатор построенный на основе цепей Маркова.
У меня есть аргументы. Я смог доказать на примерах и в работах, что мы имеем дело с иерархической цепью Маркова. Одним из таких примеров является построение на основе этого токенизатора, который не является частотным как BPE, а именно основан на цепях Маркова. И при равных условиях при обучении одних и тех же LLM с нуля, мы получаем результат который просто "рвет" классические токенизаторы в процессе обучения, как по скорости обучения.
Так же модель по Loss при обучении заметно быстрее сходиться и дает гораздо более качественный результат. https://t.me/greenruff/2518
Поэтому если вы что-то утверждаете, то приводите аргументы. Я математически доказал, что является иерархическими цепями Маркова, подтвердил это эмпирически, получил предсказательную силу которую наглядно можно пощупать.
Вы не до конца видимо понимаете, как устроена LLM и как она предсказывает вероятности.
Что касается памяти, то вот интересное исследование с фреймворком от Google. Речь про исследование Google про архитектуру Titans + фреймворк MIRAS, где они используют Predict Coding в качестве "удивления"/"новизны" для выбора того. что запоминать.
Если коротко, то проблема в выборе вероятного токееа. Текст это цепь иерархическая цепь Маркова. LLM на выходе выдает условную вероятность с учётом всей иерархии. Но это не значит, что мы можем на каждом шаге выбрать любой токен по критерию top-p/top-k. Так как это ломает цепь, согласованность всех ее уровней. Высокая вероятность не значит, что она допустима в данной цепи. Мы должны учитывать вероятность всей текущей цепи Маркова.
Мы должны учитывать вероятность цепи с учётом порога разрыва цепи Маркова. Сам порог разрыва связан с ограничением кол-ва возможных состояний. Его можно посчитать. Выше ссылке показано как. Только в этом случае мы не разрушаем цепь. Иначе, может возникнуть ситуацию, что мы пытаемся генерировать продолжение шума. Это приводит к тому, что теряется контекст. И это приводит к усилению галлюцинаций.
Особенно сильно это проявляется в том случае, когда сеть "не знает" ответ. В этом случае мы получаем на выходе множество условных вероятностей, которые будут близки по своему значению. И выбор неправильной, легко приводит к тому, что мы выбираем шум и пытаемся его продолжить. Тут два момента:
1) мы все таки можем выбрать правильный, только должны сильно сузить выбор допустимых, чтобы не разрушать контекст.
2) ни один не позволяет сделать выбор, итак чтобы цепь Маркова могла продолжится. То есть мы получаем состояние неопределенности. В случае мозга, запустился бы поиск альтернативного маршрута или это привело к ответу "я не знаю", так как не одна из предложенных вероятностей не допустима, при условии что она не разрушит цепь Маркова. Когда все варианты равновероятны и недопустимы это и есть условно состояние "я не знаю". Но у текущих архитектур LLM нет механизма для обработки такой ситуации. В мозге для этого есть область ACC, она отвечает за подобные конфликты. У LLM такого нет, и она не может прекратить регенерировать текст дальше, так как мы продолжаем выбирать "шум" как следующий токен, даже если мы достигли "неопределенности".
Что касается разрешения состояния неопределенности, то в мозге для этого есть специальный механизм:
Через ЭЭГ ничего не считает. И проблема не в объеме данных, а в том что есть не много способов:
МРТ - позволяет получить много информации но с сильной задержкой по времени и габариты оборудования.
Активные электроды при вживление, позволяет получить детальную информацию на отдельном фрагменте. Они подходят для обучения чему-то, но не для считывания глобальной информации, так как связаны с небольшим локальным участком.
ЭЭГ - тут мы просто получаем размазанное пятно сигнала, при чем с самых верхних слоев неокортекса. Там были ещё другие подходы, но они тоже более крупные и считают не сам сигнал.
В свое время писал небольшой пост об этом, так как много лет работал с ЭЭГ.
Вот что мы реально может считать через ЭЭГ. Это даже близко не мысли. Все остальные утверждения про использование ЭЭГ для чтения всего, это как минимум мошенничество.
Чтобы понять почему нельзя, ну нужно даже иметь огромного опыта с этим. Выше слайд, где описывал ЭЭГ. Это суммарная активность нейронов.
Ещё одна проблема, даже если мы игнорируем остальные, это само рефлексия. Мы не можем отличить это сейчас само рефлексия или это обработка внешнего сенсорного сигнала. То есть мы увидели кошку или представили кошку. Игнорируем это? Хорошо, но проблема в том что при саморефлексии сигнал более слабый. И считать его проблематично, для ЭЭГ его чтение это ближе к уровню шума или на грани. Если вы просто о чем то задумались, а не пытаетесь усиленно сконцентрировать на чем-то свое внимание.
То есть все что мы можем, это по сути считать только верхний слой 1. А это top-down модулирующий сигнал. А до самого исходного сигнала приступившего на вход bottom-up), мы добраться через ЭЭГ не можем, только до его суммарных активностей, когда в какой-то то момент где то был сильный всплеск активности группы нейронов в слое 2/3. То есть что можем зафиксировать всплеск, а может и нет, если он не такой сильный (сенсорный входной стимул был не настолько сильный).
То есть все что в "идеале" мы могли бы получить, это то что в обработанном предложении слово A связано со словом B. Но сами слова мы при этом не знаем (условный пример). При том, что эти слова могут быть не внешними услышанными, а результатом саморефлексии и тут у нас описанная выше проблема саморефлексии.
Как итог мы можем выделить абстрактный top-down модулирующий сигнал и отдельные суммарные проявления сильных сенсорных стимулов bottom-up сигнала.
Поэтому либо в статье журналист изнасиловал ученого либо это мошеннический маркетинг в духе AGI.
Сначала доказал теоремы, где в итоге выводится формула predict coding. Так вот, ошибка Predict Coding в FEP в том, что там она интерпретирует как ошибка. Это в корне не верно. Сама формула правильная в FEP. Predict coding это контекст, он вызван тем, что системе приходиться балансировать и решать проблему неопределенности. Например, у нас есть текст: Маша мыла - предсказали "раму". Но на самом деле мы предсказали распределение, а не конкретно "раму".
Пусть входной сигнал это распределение X. Тогда H (Predict Coding) = X - Y это распределение. Так вот, на следующем шаге X = X*H. В данном случае H это множество других вероятностей, которые могут привести к альтернативным маршрутам, которые могут быть более устойчивыми чем предсказанный Y. Поэтому входной сигнал усиливается, и альтернативный H сильный, то это переключает систему на другой альтернативный маршрут.
В данном случае, если маршрут Y сильнее, то он продолжается. Если H оказывает сильнее влияние, то происходит переключение на альтернативный маршрут, подобие "критического мышление" , точно ли "раму" или там важнее что "мыла утром".
Если же Y и H равны, это значит нет устойчивого маршрута, это аналог "не знаю". Так как ни один из вариантов не является устойчивым предсказанием.
Очень упрощённая схема.
Ну а сам predict coding, это следствие неопределенности. Он связан с тем, что есть ситуации, когда мы пытаемся предсказать следующий шаг, а условная вероятность соответствует сразу нескольким равнозначным вариантам.
То есть predict coding, это не минимизация свободной энергии. А механизм системы выхода из неопределенности и нахождения наиболее устойчивых цепей Маркова, то есть самого вероятного маршрута. Так как предсказание следующего токена не гарантирует, что этот маршрут (цепь Маркова) в целом более устойчивая/сильная.
Но я могу ручаться что они правильные, так проверял их на практике.
В случае же классической интерпретации FEP predict coding это ошибка. Но это лишено смысла. Так как:
1) Predict coding (acc зона и слои 6 неокортекса) не вычитается в таламус, куда они идут, а модулируют входной сигнал, то есть умножаются, делая его слабее/сильнее.
2) Если мы считаем predict coding ошибкой и все таки вычитаем ее из входного сигнала, то ничего не будет. Модель и так предсказала сигнал, какой нам смысл вычитать из входного сигнала остаток. Это просто приведет к тому же устойчивому сигналу. Мы просто лишаем систему выбора альтернативы, говоря ей усилить текущий предсказанный маршрут, который она и так ранее уже предсказала. Считая, что остальной просто шум. Это лишено всякого смысла и не стыкуется с нейробиологией, если мы посмотрим куда идёт сигнал predict coding и как он влияет на входной сигнал.
Частично упрощённо (не все обозначено), но связи правильные.
Я в свое время рисовал маршрут рекуррентной петли. Он не совсем полный, но отражает смысл. На нем видно:
1) predict coding идёт в ассоциативные ядра таламуса и формирует альтернативный сигнал
2) predict coding модулирует сенсорный сигнал, а не вычитает. В FEP же если читать ее, predict coding это err. И затем X-err. Но мы такого в реальности не наблюдаем. А вот модуляция несёт совсем другой смысл.
1) я написал что это компромиссное решение, которое по качеству лучшее. Ого как раз захватывает гармоники через ширину, в то время как в сетки в коде даже этого не делают.
2) LPC делает гораздо, гораздо хуже. Он не приспособлен идеально к речи. Естественно у меня есть код этого через librosa, но там звучание гораздо хуже. Так как librosa больше подходит для неречевых звуков. Что касается pydub, то и с ним у меня была реализация и там тоже что-то было не так. Из всех вариантов, был выбран наиболее лучший по качеству с учётом компромиссов. Остальные давали результат гораздо хуже или ломали что-то ещё.
Вместо того чтобы полагаться на сетки надо проверять, а уже затем утверждать. В этом и заключается проблема, если полагаться на то что утверждает сетка. Я прекрасно знаю, что они отвечают, так как использую их и они в этих моментах очень сильно тупят. И я молчу уже о том, что решая проблему они могут выкинуть что то уже рабочее в коде, какую то деталь, упростить расчет и так далее.
Paart очень известная библиотека. Там же дело не в библиотеке, а к логике реализации. Такие же проблемы возникают и с базами данных. Вот простой пример, который нормально не могут осилить LLM. Нужно перенести SQL с MS SQL на Postgres, это по-моему часть кода одного из отчетов. Ниже два примера MS SQL которые нужно перенести на Postgres. В данном случае есть некоторые участки, где синтаксис будет сильно отличаться или даже может не оказаться аналога. А если еще учесть, что надо динамический запрос, то все усложняется. Вот такие реальные задачи встречаются в жизни.
В первом, LLM постоянно что-то выкидывает, что-то теряет, упускает детали.
Скрытый текст
-- Устанавливаем первый день недели понедельником
SET datestyle = ISO, DMY;
-- Курсор для создания временной таблицы со временем простоя
DO $$
DECLARE
branch_id INT;
work_place_id INT;
wevent INT;
event_time TIMESTAMP;
temp_branch_id INT;
temp_work_place_id INT;
temp_event_time TIMESTAMP;
temp_beg_time TIMESTAMP := NULL;
result_time INTERVAL := INTERVAL '0 seconds';
service_id INT;
service_group_id INT;
BEGIN
DROP TABLE IF EXISTS temp_idle_time_table;
-- Создаем временную таблицу
CREATE TEMP TABLE temp_idle_time_table (
"BRANCH_ID" INT,
"WORK_PLACE_ID" INT,
"EVENT_TIME" DATE,
"IDLE_TIME" INTERVAL
);
-- Цикл для обработки данных
FOR branch_id, work_place_id, wevent, event_time IN
SELECT
ts."BRANCH_ID",
ts."WORK_PLACE_ID",
ts."WEVENT",
ts."EVENT_TIME"
FROM "public"."WP_STATE_STAT" ts
WHERE ts."EVENT_TIME" BETWEEN '2024-09-02'::DATE AND '2024-12-02'::DATE
AND ts."BRANCH_ID" IN (1012)
AND ts."WEVENT" IN (5, 6)
ORDER BY ts."BRANCH_ID", ts."WORK_PLACE_ID", ts."EVENT_TIME", ts."WP_STATE_STAT_ID"
LOOP
-- Проверка смены группы
IF temp_event_time IS NOT NULL AND (
DATE(temp_event_time) <> DATE(event_time) OR
work_place_id <> temp_work_place_id OR
branch_id <> temp_branch_id
) THEN
INSERT INTO temp_idle_time_table ("BRANCH_ID", "WORK_PLACE_ID", "EVENT_TIME", "IDLE_TIME")
VALUES (temp_branch_id, temp_work_place_id, DATE(temp_event_time), result_time);
temp_branch_id := branch_id;
temp_work_place_id := work_place_id;
temp_event_time := event_time;
temp_beg_time := NULL;
result_time := INTERVAL '0 seconds';
END IF;
-- Обработка события WEVENT = 5 или 6
IF wevent = 5 THEN
temp_beg_time := event_time;
ELSE
IF temp_beg_time IS NOT NULL THEN
result_time := result_time + (event_time - temp_beg_time);
temp_beg_time := NULL;
END IF;
END IF;
-- Сохранение текущих данных
temp_branch_id := branch_id;
temp_work_place_id := work_place_id;
temp_event_time := event_time;
END LOOP;
-- Финальная вставка последнего блока
IF temp_event_time IS NOT NULL THEN
INSERT INTO temp_idle_time_table ("BRANCH_ID", "WORK_PLACE_ID", "EVENT_TIME", "IDLE_TIME")
VALUES (temp_branch_id, temp_work_place_id, DATE(temp_event_time), result_time);
END IF;
-- Создаем временную таблицу
DROP TABLE IF EXISTS temp_level_table;
CREATE TEMP TABLE temp_level_table AS
SELECT *
FROM public.FUNC_SRV_PARENT_LEVEL(NULL, NULL, NULL);
-- Добавляем услуги, у которых нет группы
INSERT INTO temp_level_table ("SERVICE_ID")
SELECT s."SERVICE_ID"
FROM "public"."SERVICES" s
WHERE s."BRANCH_ID" = 0
AND s."SERVICE_GROUP_ID" IS NULL;
-- Обрабатываем услуги с группами
FOR service_id, service_group_id IN
SELECT s."SERVICE_ID", s."SERVICE_GROUP_ID"
FROM "public"."SERVICES" s
WHERE s."SERVICE_GROUP_ID" IS NOT NULL
AND s."BRANCH_ID" = 0
LOOP
-- Для каждой услуги добавляем уровни вложенности
INSERT INTO temp_level_table
SELECT *
FROM public.FUNC_SRV_PARENT_LEVEL(0, service_id, service_group_id);
END LOOP;
WITH weekly_periods AS (
SELECT
TS."REG_TIME",
'№' || EXTRACT(WEEK FROM TS."REG_TIME") || ' (' ||
TO_CHAR(DATE_TRUNC('week', TS."REG_TIME") - INTERVAL '1 day', 'DD.MM.YYYY') || ' - ' ||
TO_CHAR(DATE_TRUNC('week', TS."REG_TIME") + INTERVAL '5 day', 'DD.MM.YYYY') || ')'
AS "PERIOD_WEEK"
FROM "TICKETS" AS TS
),
hourly_periods AS (
SELECT
ts."REG_TIME",
TO_CHAR(ts."REG_TIME", 'HH24:00') || ' - ' || TO_CHAR(ts."REG_TIME", 'HH24:59') AS "PERIOD_HOUR"
FROM "TICKETS" ts
)
SELECT
-- Группы отделений и отделения
brgr."BRANCHES_GROUP_NAME" AS BGROUP_NAME,
br."BRANCH_NAME" AS BRANCH_NAME,
-- Уровни вложенности услуги по группам
t."SERVICE_GROUP_NAME_LEV1",
t."SERVICE_GROUP_NAME_LEV2",
t."SERVICE_GROUP_NAME_LEV3",
t."SERVICE_GROUP_NAME_LEV4",
t."SERVICE_GROUP_NAME_LEV5",
t."SERVICE_GROUP_NAME_LEV6",
-- Услуга
sr."SERVICE_NAME" AS SERV_NAME,
-- Приоритет
pr."PRIORITY_NAME",
-- Год
EXTRACT(YEAR FROM ts."REG_TIME") AS PERIOD_YEAR,
-- Месяц (прописью)
TO_CHAR(ts."REG_TIME", 'Month') AS PERIOD_MONTH,
-- Неделя (формат: №Недели (дата первого дня недели - дата последнего дня недели))
wp_week."PERIOD_WEEK",
-- День
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY') AS PERIOD_DAY,
-- Час (часовой период)
hp."PERIOD_HOUR",
-- ФИО сотрудника
CASE
WHEN ts."WORK_USER_ID" IS NULL THEN ' '
ELSE COALESCE(wu."LAST_NAME", '') || ' ' || COALESCE(wu."FIRST_NAME", '') || ' ' || COALESCE(wu."PATRONYMIC", '')
END AS WU_NAME,
-- Рабочее место
wp."WORK_PLACE_NAME" AS WORK_PLACE_NAME,
-- Время включения/выключения рабочего места
(
SELECT TO_CHAR(wps."EVENT_TIME", 'HH24:MI')
FROM public."WP_STATE_STAT" wps
WHERE wps."BRANCH_ID" = ts."BRANCH_ID"
AND wps."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND wps."WEVENT" = 1
AND wps."EVENT_TIME" BETWEEN DATE_TRUNC('day', ts."REG_TIME") AND DATE_TRUNC('day', ts."REG_TIME") + INTERVAL '1 day'
ORDER BY wps."EVENT_TIME"
LIMIT 1
) AS switch_on,
(
SELECT TO_CHAR(wps."EVENT_TIME", 'HH24:MI')
FROM public."WP_STATE_STAT" wps
WHERE wps."BRANCH_ID" = ts."BRANCH_ID"
AND wps."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND wps."WEVENT" = 2
AND wps."EVENT_TIME" BETWEEN DATE_TRUNC('day', ts."REG_TIME") AND DATE_TRUNC('day', ts."REG_TIME") + INTERVAL '1 day'
ORDER BY wps."EVENT_TIME" DESC
LIMIT 1
) AS switch_off,
-- Всего по услуге
COUNT(*) AS RECS_COUNT,
-- Обслужено
SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS SERVICED,
-- Не обслужено
COUNT(*) - SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS NOT_SERVICED,
-- Не вызваны
SUM(CASE WHEN ts."SERVE_UP" IN (0, 5, 6) THEN 1 ELSE 0 END) AS NOT_CALLED,
-- Неявка
SUM(CASE WHEN ts."SERVE_UP" = 3 THEN 1 ELSE 0 END) AS ABSENT,
-- Отложены
SUM(CASE WHEN ts."SERVE_UP" = 4 THEN 1 ELSE 0 END) AS DELAYED,
-- Среднее время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0
THEN TO_CHAR(SUM(EXTRACT(EPOCH FROM ts."SERV_TIME" - ts."CALL_TIME")) / SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END), 'HH24:MI:SS')
ELSE ''
END AS AVG_SERVE_TIME,
-- Максимальное время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0
THEN TO_CHAR(MAX(ts."SERV_TIME" - ts."CALL_TIME"), 'HH24:MI:SS')
ELSE ''
END AS MAX_SERVE_TIME
-- Дополнительно добавить другие вычисления аналогично
FROM "TICKETS" ts
LEFT JOIN "BRANCHES" br ON br."BRANCH_ID" = ts."BRANCH_ID"
LEFT OUTER JOIN "BRANCHES_GROUPS" brgr ON brgr."BRANCHES_GROUP_ID" = br."BRANCHES_GROUP_ID"
LEFT JOIN "WORK_USERS" wu ON wu."WORK_USER_ID" = ts."WORK_USER_ID" AND wu."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "SERVICES" sr ON sr."SERVICE_ID" = ts."SERVICE_ID" AND sr."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN temp_level_table t ON t."SERVICE_ID" = ts."SERVICE_ID"
LEFT JOIN "WORK_PLACES" wp ON wp."WORK_PLACE_ID" = ts."WORK_PLACE_ID" AND wp."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "PRIORITIES" pr ON pr."PRIORITY_ID" = ts."PRIORITY_ID" AND pr."BRANCH_ID" = 0
LEFT JOIN temp_idle_time_table tmp ON tmp."BRANCH_ID" = ts."BRANCH_ID"
AND tmp."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND tmp."EVENT_TIME" = CAST(ts."REG_TIME" AS DATE)
LEFT JOIN weekly_periods wp_week ON wp_week."REG_TIME" = ts."REG_TIME"
LEFT JOIN hourly_periods hp ON hp."REG_TIME" = ts."REG_TIME"
WHERE
ts."QMS_DELETED" = FALSE
AND ts."SERVICE_ID" > 0
AND ts."REG_TIME" BETWEEN '2024-09-02' AND DATE '2024-12-01' + INTERVAL '1 day'
AND EXTRACT(HOUR FROM ts."REG_TIME") BETWEEN 0 AND 23
AND ts."BRANCH_ID" IN (1012)
--AND ts."SOURCE_RECORD_KIND" IN (1, 2, 3, 5, 6)
AND EXISTS (
SELECT 1
FROM "WORK_USERS" u
WHERE ts."BRANCH_ID" = u."BRANCH_ID"
)
GROUP BY
brgr."BRANCHES_GROUP_NAME",
br."BRANCH_NAME", ts."BRANCH_ID",
sr."SERVICE_NAME", ts."SERVICE_ID",
t."SERVICE_GROUP_NAME_LEV1", t."SERVICE_GROUP_NAME_LEV2", t."SERVICE_GROUP_NAME_LEV3",
t."SERVICE_GROUP_NAME_LEV4", t."SERVICE_GROUP_NAME_LEV5", t."SERVICE_GROUP_NAME_LEV6",
pr."PRIORITY_NAME",
EXTRACT(YEAR FROM TS."REG_TIME"),
TO_CHAR(TS."REG_TIME", 'Month'),
wp_week."PERIOD_WEEK",
TO_CHAR(TS."REG_TIME", 'DD.MM.YYYY'),
ts."REG_TIME",
hp."PERIOD_HOUR",
ts."WORK_USER_ID", wu."LAST_NAME", wu."FIRST_NAME", wu."PATRONYMIC",
"WORK_PLACE_NAME", ts."WORK_PLACE_ID"
ORDER BY
BGROUP_NAME,
BRANCH_NAME,
"SERVICE_GROUP_NAME_LEV1", "SERVICE_GROUP_NAME_LEV2", "SERVICE_GROUP_NAME_LEV3",
"SERVICE_GROUP_NAME_LEV4", "SERVICE_GROUP_NAME_LEV5", "SERVICE_GROUP_NAME_LEV6",
SERV_NAME,
PERIOD_YEAR,
PERIOD_MONTH,
"PERIOD_WEEK",
CAST(ts."REG_TIME" AS DATE),
"PERIOD_HOUR",
ts."WORK_USER_ID", wu."LAST_NAME", wu."FIRST_NAME", wu."PATRONYMIC",
pr."PRIORITY_NAME",
WORK_PLACE_NAME;
/*Удаляем за собой временную таблицу*/
drop table temp_level_table;
drop table temp_idle_time_table;
END $$;
Во втором, просто тупо допускает ошибки не понимания в чем дело. LLM использует string_agg при конвертировании, и упускает некоторые моменты особенности Postgres при работе с string_agg. Из за этого код она пишет, код при выполнении иногда выдаст ошибку, LLM пытается ее исправить, но зациклено по кругу исправляет одно и тоже, не понимая некоторых нюансов работы string_agg.
Скрытый текст
-- Устанавливаем язык вывода дат
SET datestyle = 'ISO, DMY';
WITH weekly_periods AS (
SELECT
ts."REG_TIME",
'№' || EXTRACT(WEEK FROM ts."REG_TIME") ||
' (' || TO_CHAR(ts."REG_TIME" - INTERVAL '1 day' * (EXTRACT(DOW FROM ts."REG_TIME") - 1), 'DD.MM.YYYY') ||
' - ' || TO_CHAR(ts."REG_TIME" + INTERVAL '1 day' * (7 - EXTRACT(DOW FROM ts."REG_TIME")), 'DD.MM.YYYY') || ')' AS "PERIOD_WEEK"
FROM "TICKETS" ts
),
hourly_periods AS (
SELECT
ts."REG_TIME",
TO_CHAR(ts."REG_TIME", 'HH24:00') || ' - ' || TO_CHAR(ts."REG_TIME", 'HH24:59') AS "PERIOD_HOUR"
FROM "TICKETS" ts
)
SELECT
-- Группы отделений и отделения
brgr."BRANCHES_GROUP_NAME" AS "BGROUP_NAME",
br."BRANCH_NAME" AS "BRANCH_NAME",
-- Роль
COALESCE(wp."WP_ROLE_NAME", ' ') AS "ROLE_NAME",
-- Услуга
sr."SERVICE_NAME" AS "SERV_NAME",
-- Год
EXTRACT(YEAR FROM ts."REG_TIME") AS "PERIOD_YEAR",
-- Месяц (прописью)
TO_CHAR(ts."REG_TIME", 'Month') AS "PERIOD_MONTH",
-- Неделя
wp_week."PERIOD_WEEK",
-- День
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY') AS "PERIOD_DAY",
-- Час (часовой период)
hp."PERIOD_HOUR",
-- Всего по услуге
COUNT(*) AS "RECS_COUNT",
-- Обслужено
SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS "SERVICED",
-- Не обслужено
COUNT(*) - SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS "NOT_SERVICED",
-- Среднее время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0 THEN
TO_CHAR(AVG(ts."SERV_TIME" - ts."CALL_TIME")::interval, 'HH24:MI:SS')
ELSE '00:00:00'
END AS "AVG_SERVE_TIME",
-- Среднее время ожидания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0 THEN
TO_CHAR(AVG(ts."CALL_TIME" - ts."REG_TIME")::interval, 'HH24:MI:SS')
ELSE '00:00:00'
END AS "AVG_WAITING_TIME",
-- Ожидающие менее
SUM(CASE
WHEN ts."CALL_TIME" IS NOT NULL AND (EXTRACT(EPOCH FROM ts."CALL_TIME" - ts."REG_TIME") / 60) < 0 THEN 1 ELSE 0
END) AS "WAITING_LESS",
-- Обслуживающиеся менее
SUM(CASE
WHEN ts."CALL_TIME" IS NOT NULL AND ts."SERVE_UP" = 2 AND (EXTRACT(EPOCH FROM ts."SERV_TIME" - ts."CALL_TIME") / 60) < 0 THEN 1 ELSE 0
END) AS "SERVING_LESS"
FROM "TICKETS" ts
LEFT JOIN "BRANCHES" br ON br."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "BRANCHES_GROUPS" brgr ON brgr."BRANCHES_GROUP_ID" = br."BRANCHES_GROUP_ID"
LEFT JOIN "WP_ROLES" wp ON wp."WP_ROLE_ID" = ts."WP_ROLE_ID" AND wp."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "SERVICES" sr ON sr."SERVICE_ID" = ts."SERVICE_ID" AND sr."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN weekly_periods wp_week ON wp_week."REG_TIME" = ts."REG_TIME"
LEFT JOIN hourly_periods hp ON hp."REG_TIME" = ts."REG_TIME"
WHERE
ts."QMS_DELETED" = false
AND ts."SERVICE_ID" > 0
AND ts."REG_TIME" BETWEEN :PDATE_FROM AND :PDATE_TO
AND EXTRACT(HOUR FROM ts."REG_TIME") BETWEEN :HOUR_FROM AND :HOUR_TO
AND ts."BRANCH_ID" IN (14)
AND ts."SOURCE_RECORD_KIND" IN (1, 2, 3, 5, 6)
AND EXISTS (
SELECT 1
FROM "WP_ROLES" r
INNER JOIN "WP_ROLES_ITEMS" ri ON ri."BRANCH_ID" = r."BRANCH_ID" AND ri."WP_ROLE_ID" = r."WP_ROLE_ID"
WHERE ts."BRANCH_ID" = r."BRANCH_ID" AND r."IS_USED" = true AND ri."SERVICE_ID" = ts."SERVICE_ID"
)
GROUP BY
brgr."BRANCHES_GROUP_NAME",
br."BRANCH_NAME",
sr."SERVICE_NAME",
wp."WP_ROLE_NAME",
wp_week."PERIOD_WEEK",
hp."PERIOD_HOUR",
EXTRACT(YEAR FROM ts."REG_TIME"),
TO_CHAR(ts."REG_TIME", 'Month'),
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY')
ORDER BY
"BGROUP_NAME",
"BRANCH_NAME",
"ROLE_NAME",
"SERV_NAME",
"PERIOD_YEAR",
"PERIOD_MONTH",
"PERIOD_WEEK",
"PERIOD_DAY",
"PERIOD_HOUR";
Praat это самая популярная и эффективная библиотека при работе с голосом. Все LLM ее знают и все равно галлюцинируют на ней часто обращаясь к тому чего нет. Как уже было сказано выше, да она правильная, так как использовал ее при изменении голоса.
Ниже пример, где также используется эта функция. Я прекрасно знаю что на все это пишут LLM, проблема в том, что они не могут не писать, даже там где имеют проблемные места.
Давайте так, если вы предлагаете решение, то не нужно просто брать и генерировать его и просить модель объяснить это решение. Стоит сначала взять и проверить его и затем уже предлагать. Если кратко то нет, в вашем случае на выходе вы услышите на фоне звука так же потрескивание или наоборот звуки скрежета.
В предложенном коде все кишит проблемами. 1) форманты содержат ширину, и ее надо учитывать. В коде выше, она считается примитивным образом как bw = -np.log(magnitudes[idx]) * sample_rate / np.pi и дальше просто идет проверка. 2) LPC очень плохо справляет на самом деле с голосом. 3) resample в описанном мной примере делается как компромисс, чтобы не потерять сильно в качестве звука. Это важное отличие, которое агенты просто не могут сделать. Нет такого понятие как компромисс, не могут они это оценить. 4) там еще не мало других проблем, вроде if 90 < f < 5000 and bw < 500 и множества других.
Синтетические тесты тут ни как не помогут. Что вы хотите в них анализировать? Как выстроите их, по какому критерию? Просто частоты сдвинулись или нет? В голосе форманты имеют обертоны, и если вы просто сдвинули какую то частоту то это не будет согласовываться например с ними.
Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
def change_formants_shifts(signal, sr, formant_shifts, formants=None):
"""
Изменяет частоты формант в аудиофайле на фиксированное значение для каждой форманты.
"""
if formants:
frequencies = formants["frequencies"]
times = formants["voiced_times"]
else:
frequencies, times, _, _ = formant_frequencies(signal, sr)
# Определение функции для получения новой частоты форманты
def get_new_formant_freq(original_freq, formant_num):
if original_freq <= 0:
return original_freq
return original_freq + formant_shifts[formant_num]
# Создание нового объекта звука для изменённого звука
modified_signal = np.copy(signal)
# Итерация по каждому временно́му шагу и изменение частот формант
for t_idx, t in enumerate(times):
for i in range(5): # Форманты F1 до F5
original_freq = frequencies[i][t_idx]
if original_freq > 0: # Убедиться, что частота форманты действительна
new_freq = get_new_formant_freq(original_freq, i)
# Расчёт коэффициента ресэмплинга
resample_ratio = new_freq / original_freq
# Регулировка значений звука вокруг частоты форманты
segment_start = max(0, int(t * sr) - int(sr / 50))
segment_end = min(len(signal), int(t * sr) + int(sr / 50))
segment = signal[segment_start:segment_end]
# Ресэмплинг сегмента для изменения частоты форманты
resampled_segment = resample(segment, int(len(segment) * resample_ratio))
# Регулировка длины для соответствия оригинальному сегменту
if len(resampled_segment) > (segment_end - segment_start):
resampled_segment = resampled_segment[:segment_end - segment_start]
elif len(resampled_segment) < (segment_end - segment_start):
pad_width = (segment_end - segment_start) - len(resampled_segment)
resampled_segment = np.pad(resampled_segment, (0, pad_width), mode='constant')
# Добавление ресэмплированного сегмента к изменённым значениям
modified_signal[segment_start:segment_end] = resampled_segment
modified_signal = np.clip(modified_signal, -1, 1)
return modified_signal, sr
Вы хоть обложитесь сотней агентов, они не сделают.
Напишут они код? Да напишут. Будет он делать то что нужно? Нет. Могут в этом помочь отладчики или консоль или что-то еще? Нет. Знают ли модели о проблемах, если начать разбирать их код? Конкретно о каждой проблеме они всегда что-то напишут. Могут ли они сразу перечислить все возможно проблемы, чтобы учесть их? Нет.
То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
У нее многие статьи это скорее рассуждающие, то есть теоретические (чем она и занимается по своей специальности). Сложно назвать их научными в плане исследований, а скорее научными в плане рассуждений. Это как если бы был специальный habr для физиков-математиков.
Насчет цитируемости, то она еще в 2019 году писала статью:
"В данной работе мы описываем и представляем результаты работы простой нейронной сети, которая прогнозирует будущие показатели цитирования отдельных исследователей на основе различных данных из их прошлой деятельности."
Они делали простую нейросеть и прогнозировали цитируемость. На научную работу это не тянет. На хабре многие пишут статью, как что-то спрогнозировали. На GitHub такого много тоже, но для исследования это как-то мелко сегодня. Но тема цитируемости, явно "близка" ей.
Но в остальном, у нее много интересных работ "A derivation of Born’s rule from symmetry", где есть предположение, что вероятности должны быть согласованы с юнитарной структурой гильберта. И из этого ее объяснение показывает, что правило Борна не является случайной догадкой, а математически единственный возможный вариант, совместимый с симметрией квантовой механики. И таких статей у нее много. Они о построении различных гипотез, связях и так далее.
Если обобщить это, то тема цитируемости ей очень близка + большинство ее это гипотезы и рассуждения, но безусловно очень интересные. Так что понятно почему ее лично волнуют LLM статьи:
1) написание большего кол-ва статей, приведет к тому, что ей будет сложнее конкурировать с ними
2) ее статьи как раз рассуждающие, с различными гипотезами, теоретические но под разным углом и разными предположениями. Такое очень удобно делать с помощью LLM.
Другое дело, что LLM сами ничего не сделают. Для этого надо понимать, что они пишут, что попросить проанализировать, разобрать что они написали и отсеять бред. Так что автор либо боится что будет завалено мусором (но мусорных научных статей и так большинство), либо что упростит порог входа и написание теоретически рассуждающих статей другими физиками либо это просто страх неопределенности.
Там скорее про AGI в математическом плане, так как тут два лагеря:
AGI как система, способная понять абсолютно всё
Такую трактовку использует Шлерет. AGI это универсальная система, способная охватить все возможные данные и концепты. Если мы следуем этому определению, то, как утверждает Шлерет, AGI невозможен: алгоритмические системы ограничены семантическим алфавитом и не могут индуктивно выйти за пределы своего (Semantic Closure), особенно в условиях тяжёлых хвостов (α ≤ 1), когда энтропия расходится.
AGI как выдающаяся обобщающая система (человеко-подобная)
Если AGI понимать как систему, способную разумно обобщать данные, учиться, адаптироваться в широком диапазоне задач (человеко‑подобный интеллект, но не всесильная модель), то такая AGI может быть теоретически достижима. Этот подход соответствует определению AGI как способности обобщения и адаптации в разнообразных средах, например, как способность учиться и адаптироваться к новым задачам.
Если AGI требует бесконечного символического охвата, то согласно Шлерету, это невозможно.
Если же AGI это скорее человеческий интеллект, способный обрабатывать широкий класс задач, тогда Шлерет лишь указывает, что алгоритмические модели имеют пределы, но уже такие системы могут приближаться к человеческой универсальности.
Поэтому если называть AGI в рамках теоремы Шлерет, то человек сам по себе не способен охватить абсолютно всё, значит человек тоже не является AGI в строгом смысле первой трактовки. Таким образом AGI невозможен если нужен абсолютный охват.
AGI возможен в практическом смысле человеческой универсальности и человек, и алгоритмы могут быть ограниченно универсальны.
Так что выводы Шлерета не оспаривают возможность создания систем, схожих с человеческим интеллектом, но ставят под сомнение концепт AGI как всемогущего оракула, который охватывает всё.
Но изначально была речь про интерпретацию теоремы в рамках галлюцинаций (в рамка поста выше), а она к ним не имеет отношения, об этом я и указал.
Там под AGI подразумевается немного другое. Условно говоря система, которая может описать все что только возможно, то есть любую сложность. Поэтому эту теорему критиковали, так как аргумент был что мозг это AGI. Но автор теоремы все таки говорил там о другом. То есть словами теоремы, наш мог тоже не может обобщать бесконечно и поэтому имеет ограничение по предсказанию/аппроксимации/описанию. Подозреваю, что в теореме фигурирует AGI в данной формулировке, по той причине, что было много обещаний, что появиться AGI и сможет объяснить все на свете.
Не знаю, на сколько Владимир Крылов силен в математике, думаю что достаточно хорошо. Но то что она написал это каша, и интерполировать некоторые субъективные представления без доказательств на LLM, как минимум не профессионально.
В реальности LLM никогда не аппроксимируют произвольные функции. Они работают внутри фиксированного класса параметризованных функций. Это конечномерные, вычислимые, гладкие отображения. Мы здесь не ищем произвольную функцию. Наша задача аппроксимировать условное распределение языка, а не функцию Z→Z. Аргумент про "меру ноль" ничего не говорит об обучаемости, аппроксимации, обобщении, вероятностных моделях.
Это просто неверно. Attention линейный по V, детерминированный, полностью вычислимый, не вводит ошибок сам по себе. Галлюцинации прекрасно возникают и без attention (RNN, n-gram), в байесовских моделях, в любом генеративном вероятностном процессе. Attention не причина, это формально "усилитель уверенности".
Частично верно, но сказано в неверной формулировке. Более правильно было бы сказать, что галлюцинации это следствие постановки задачи как вероятностного языкового моделирования, а не конкретно трансформеров или attention. Более того, есть множество видов галлюцинаций, которые имеют разные причины и проявляются схожим образом.
Скрытый текст
https://t.me/greenruff/2223
Для примера делал разбор, как это у мозга. Даже у краткого частичного описания этого явления, можно понять, что причин существует множество. А существующие архитектуры, не охватывают/учитывают многие моменты.
Это означает, что модель не оптимизируется на истинность, не оптимизируется на выполнимость, не оптимизируется на корректность логического вывода, а только на правдоподобие продолжения. В этом смысле галлюцинация это естественный режим работы модели, когда данных недостаточно, сигнал слабый, распределение неоднозначно, или запрос лежит вне обучающего распределения. Но это не имеет никакого отношения к невычислимым функциям, Тьюрингу и мерам множеств.
Это по сути переформулировка теоремы Райса, следствия неразрешимости. Формально верно, но логически вообще не связано с галлюцинациями.
Теорема говорит о точном вычислении функций. LLM не претендуют на точность, они оптимизируют ожидаемую правдоподобность, а не универсальную корректность. По этой логике любой калькулятор галлюцинирует, потому что есть входы вне его спецификации. Это подмена понятий.
Возможно он имел ввиду теорему AGI is Impossible. Here is the Proof. The Infinite Choice Barrier and a New Critique of Artificial Reason. Author: Max M. Schlereth. Не знаю как Крылов, но очень подробно изучал эту работу, так как она была связана с другими нужными мне математическими теоремами. Формально она говорит:
Формально это близко к неразрешимости, отсутствию эффективной процедуры выбора, или отсутствию вычислимого функционала оптимальности. Это своего рода вариация аргументов Гёделя, Райса и анти-формалистских аргументов Пенроуза. Но тут важно, что Schlereth говорит о принципиальной невозможности универсального разума, а не об ошибках в конкретных ответах. поэтому если упоминается она, то это натягивание совы на глобус и подмена понятий.
Потому что галлюцинация это уверенный вывод при недостаточной информации, в рамках вероятностного генератора. А ICB это невозможность алгоритмического выбора в бесконечном пространстве альтернатив, даже в идеальных условиях.
Если совсем кратко, то разница в том, что галлюцинации не следствие невозможности выбора, а следствие принуждения к выбору там, где оптимально было бы воздержаться.Про 33–48% галлюцинаций у reasoning-моделей, здесь он частично прав, но формулирует это как-то криво. Если описывать причину понятно и правильно, то reasoning это длинная цепочка. Она приводит к тому, что вероятность ошибки растёт экспоненциально. То есть по факту это накопление ошибки, а не парадокс рассуждений. Именно об этом я и писал в комментарии ранее:
https://habr.com/ru/articles/982494/comments/#comment_29332940
как об одном конкретном виде галлюцинаций, который приводит к накоплению ошибки и в итоге это проявляется как сдвиг. А так же почему он происходит и как его минимизировать.
Как математик он вроде говорит корректные вещи. Но как специалист по ИИ он явно путает вычислимость и обобщение, подменяет задачу, использует нерелевантные теоремы, не понимает оптимизационную природу LLM. То что я вижу, это ответ человека, который знает теорию вычислимости, но не понимает что именно оптимизируют LLM.
Если следовать его цепочке рассуждения, то AGI невозможно из-за Infinite Choice Barrier => LLM частичный AGI => Следовательно, ошибки LLM (галлюцинации) фундаментальны.
Но на основе ICB, мы можем говорит только о существовании нерешаемых задач, но галлюцинации возникают на решаемых, конечных задачах из-за того, что модель обязана генерировать ответ.
Это хороший вопрос. И ответа у меня на него нет. Надо проводить эксперименты и исследовать это, что в текущих классических архитектурах LLM более оптимально делать в этом случае: завершать генерацию как аналог токена EOS, выдавать признак что "не знаю" или какой-то маркер об этом, или добавлять текст как это делают при CoT вроде "но если подумать с другой стороны" или подобный или же еще что-то. Это надо собирать данные, смотреть на множестве текстов, которые имеют такое окончание. Но как минимум я бы такие места выделял маркеров, чтобы при чтении текста было понятно, что в этом месте модель выбрала ответ случайным образом и не может гарантировать его правильность. Так хотя бы будет понятно, стоит ли доверять данному ответу или нет и это не сложно реализовать на уровне классических LLM.
На самом деле описанную выше ситуацию получить очень легко. Я постоянно ее получаю, так как анализирую генерируемые тексты в процессе обучения моделей. В процессе обучения, тексты содержат много шума, так как модель еще не обучена, но оценить результат надо. Так вот, после того как отдаешь такой шумный текст на анализ, ChatGpt, Gemini, deepSeek, Qwen и другие начинают сыпаться. Они продолжают генерировать связанный текст, но в нем появляются "опечатки", английские буквы внутри русских слов, нарушается контекст и модель не может правильно связать более ранние части нормального текста. Так как когда мы добавляем шумный текст, то пытаемся продолжить генерировать шум. Вот тоже самое возникает в ситуации описанной выше, только по причине выбора шумного токена.
Где это следует из архитектуры трансформеров? Наоборот, из архитектуры трансформеров следует, что это иерархические цепи Маркова. вы понимаете что такое цепь Маркова? Это последовательность условных вероятностей, а ни какая то химера.
Иерархическая - это значит что цепочки условных вероятностей связаны цепочками верхнего уровня, тоже цепей условных вероятностей. Сам разрыв связан с ограниченностью системы интерпретации результата связанный с ее "точностью".
Откуда вы взяли это(?):
Разложите attention по блокам и получите связанную цепь Маркова, как на схеме выше.
Раз для понимания, судя по ответам вы используете LLM или не до конца понимает как устроены трансформеры. То вот прогоните теоремы в порядке их следования через LLM:
https://disk.yandex.ru/d/pNjCRp-hpS1ywg
если надо понять как https://t.me/greenruff/2472
Пусть LLM разжует вам подробно, как строиться эта иерархия и связи.
Вы внимательно читали ту стать. OpenAI?
Это во первых. На текущей архитектуре вы от этого не избавитесь. Во вторых в статье речь идет о другой форме проблемы галлюцинаций - это когда модель не знает. Это две разные проблемы галлюцинаций. Одна когда мы продолжаем генерацию шума, и другая когда встречаемся с ситуацией, что все варианты на уровне шума. В цитате из статьи выше, как раз об этом. Что в современных LLM нет механизма для разрешения галлюцинаций, в ситуации когда все варианты на уровне шума.
Кто вам такое сказал? Откуда вы это взяли?
Где они выяснили причину? Вы понимаете, что обучая модель на разных диалогах, где так же есть "не знаю", модель получает представление о таких ответах. О каких нулях баллах идет речь? Модель обучается по Loss. Если говорить о рассуждениях, так это дообучение модели, где может быть регуляризация. Модели без разницы, что она ответит. Что будет вероятно то и ответит. Вы путаете обучение с регуляризацией с жестко заточенным алгоритмом и неопределенностью. Если вы вводите регуляризацию, то можете выбрать любой критерий. Хоть частое вручающийся символ "А". Только это не имеет отношения к состоянию неопределённости. Вы смотрели ту работу, на чем она была построена.
Если бы все было так просто, то галлюцинаций в ChatGPT не было бы. И он умел отвечать "я не знаю" самостоятельно.
Вы в этом уверены? Можете привести не абстрактные аргументы, а конкретные?
Кто вам сказал, что иначе бы не работали. в большинстве случаев глобальная цепь Маркова не нарушается. Во вторых, небольшие шумы не приводят к неустойчивости иерархии.
У меня есть аргументы. Я смог доказать на примерах и в работах, что мы имеем дело с иерархической цепью Маркова. Одним из таких примеров является построение на основе этого токенизатора, который не является частотным как BPE, а именно основан на цепях Маркова. И при равных условиях при обучении одних и тех же LLM с нуля, мы получаем результат который просто "рвет" классические токенизаторы в процессе обучения, как по скорости обучения.
Так же модель по Loss при обучении заметно быстрее сходиться и дает гораздо более качественный результат. https://t.me/greenruff/2518
Поэтому если вы что-то утверждаете, то приводите аргументы. Я математически доказал, что является иерархическими цепями Маркова, подтвердил это эмпирически, получил предсказательную силу которую наглядно можно пощупать.
Вы не до конца видимо понимаете, как устроена LLM и как она предсказывает вероятности.
Что касается памяти, то вот интересное исследование с фреймворком от Google. Речь про исследование Google про архитектуру Titans + фреймворк MIRAS, где они используют Predict Coding в качестве "удивления"/"новизны" для выбора того. что запоминать.
Ниже видео. которое неплохо об этом рассказывает:
https://www.youtube.com/watch?v=MKHGE8yjsUM
Ссылка на само исследование:
https://arxiv.org/pdf/2504.13173
Ссылка на описание исследования:
https://research.google/blog/titans-miras-helping-ai-have-long-term-memory/
Я бы порекомендовал вам обратить внимание на такое понятие как Марковское одеяло.
Это будет полезно для тех, кто занимается агентскими системами или пытается сделать что то подобное.
Для тех кто не знаком, что такое Марковское одеяло и ли хочет лучше его понять, ниже неплохое видео объясняющее Марковское одеяло:
https://www.youtube.com/watch?v=RrqQ00TWSUE
И обратить внимание на FEP. Хотя у принципу свободной энергии Фристона много вопросов, но многие вещи из него можно почерпнуть.
Для ознакомления с Принципом свободной энергии Фристона:
https://www.youtube.com/watch?v=dcRC7ViIUHQ
Автор неплохо описал работу Фристона, другие различные лекции по FEP на русском языке мне показались более низкого качества.
В целом Марковское одеяло хорошо эмпирически себя зарекомендовало при описании различных биологических систем.
Недавно описывал в одном из комментариев причину одной из галлюцинаций LLM.
https://habr.com/ru/articles/982494/comments/#comment_29332940
Если коротко, то проблема в выборе вероятного токееа. Текст это цепь иерархическая цепь Маркова. LLM на выходе выдает условную вероятность с учётом всей иерархии. Но это не значит, что мы можем на каждом шаге выбрать любой токен по критерию top-p/top-k. Так как это ломает цепь, согласованность всех ее уровней. Высокая вероятность не значит, что она допустима в данной цепи. Мы должны учитывать вероятность всей текущей цепи Маркова.
https://telegra.ph/Rangovaya-model-veroyatnostej-i-bifurkacii-kak-utraty-asimmetrii-07-17
Мы должны учитывать вероятность цепи с учётом порога разрыва цепи Маркова. Сам порог разрыва связан с ограничением кол-ва возможных состояний. Его можно посчитать. Выше ссылке показано как. Только в этом случае мы не разрушаем цепь. Иначе, может возникнуть ситуацию, что мы пытаемся генерировать продолжение шума. Это приводит к тому, что теряется контекст. И это приводит к усилению галлюцинаций.
Особенно сильно это проявляется в том случае, когда сеть "не знает" ответ. В этом случае мы получаем на выходе множество условных вероятностей, которые будут близки по своему значению. И выбор неправильной, легко приводит к тому, что мы выбираем шум и пытаемся его продолжить. Тут два момента:
1) мы все таки можем выбрать правильный, только должны сильно сузить выбор допустимых, чтобы не разрушать контекст.
2) ни один не позволяет сделать выбор, итак чтобы цепь Маркова могла продолжится. То есть мы получаем состояние неопределенности. В случае мозга, запустился бы поиск альтернативного маршрута или это привело к ответу "я не знаю", так как не одна из предложенных вероятностей не допустима, при условии что она не разрушит цепь Маркова. Когда все варианты равновероятны и недопустимы это и есть условно состояние "я не знаю". Но у текущих архитектур LLM нет механизма для обработки такой ситуации. В мозге для этого есть область ACC, она отвечает за подобные конфликты. У LLM такого нет, и она не может прекратить регенерировать текст дальше, так как мы продолжаем выбирать "шум" как следующий токен, даже если мы достигли "неопределенности".
Что касается разрешения состояния неопределенности, то в мозге для этого есть специальный механизм:
https://t.me/greenruff/2561
Через ЭЭГ ничего не считает. И проблема не в объеме данных, а в том что есть не много способов:
МРТ - позволяет получить много информации но с сильной задержкой по времени и габариты оборудования.
Активные электроды при вживление, позволяет получить детальную информацию на отдельном фрагменте. Они подходят для обучения чему-то, но не для считывания глобальной информации, так как связаны с небольшим локальным участком.
ЭЭГ - тут мы просто получаем размазанное пятно сигнала, при чем с самых верхних слоев неокортекса. Там были ещё другие подходы, но они тоже более крупные и считают не сам сигнал.
В свое время писал небольшой пост об этом, так как много лет работал с ЭЭГ.
Вот что мы реально может считать через ЭЭГ. Это даже близко не мысли. Все остальные утверждения про использование ЭЭГ для чтения всего, это как минимум мошенничество.
Чтобы понять почему нельзя, ну нужно даже иметь огромного опыта с этим. Выше слайд, где описывал ЭЭГ. Это суммарная активность нейронов.
Ещё одна проблема, даже если мы игнорируем остальные, это само рефлексия. Мы не можем отличить это сейчас само рефлексия или это обработка внешнего сенсорного сигнала. То есть мы увидели кошку или представили кошку. Игнорируем это? Хорошо, но проблема в том что при саморефлексии сигнал более слабый. И считать его проблематично, для ЭЭГ его чтение это ближе к уровню шума или на грани. Если вы просто о чем то задумались, а не пытаетесь усиленно сконцентрировать на чем-то свое внимание.
То есть все что мы можем, это по сути считать только верхний слой 1. А это top-down модулирующий сигнал. А до самого исходного сигнала приступившего на вход bottom-up), мы добраться через ЭЭГ не можем, только до его суммарных активностей, когда в какой-то то момент где то был сильный всплеск активности группы нейронов в слое 2/3. То есть что можем зафиксировать всплеск, а может и нет, если он не такой сильный (сенсорный входной стимул был не настолько сильный).
То есть все что в "идеале" мы могли бы получить, это то что в обработанном предложении слово A связано со словом B. Но сами слова мы при этом не знаем (условный пример). При том, что эти слова могут быть не внешними услышанными, а результатом саморефлексии и тут у нас описанная выше проблема саморефлексии.
Как итог мы можем выделить абстрактный top-down модулирующий сигнал и отдельные суммарные проявления сильных сенсорных стимулов bottom-up сигнала.
Поэтому либо в статье журналист изнасиловал ученого либо это мошеннический маркетинг в духе AGI.
На самом деле Predict Coding в FEP правильное, но вот интерпретация не верная. FEP это концепция.
Как раз на днях опубликовал статью об этом. (Только vpn включить чтоб картинки грузились)
https://telegra.ph/Simmetriya-v-rangovoj-teorii-12-18
https://telegra.ph/Simmetriya-v-rangovoj-teorii-chast-2-12-21
https://telegra.ph/Simmetriya-v-rangovoj-teorii-chast-3-12-24
Сначала доказал теоремы, где в итоге выводится формула predict coding. Так вот, ошибка Predict Coding в FEP в том, что там она интерпретирует как ошибка. Это в корне не верно. Сама формула правильная в FEP. Predict coding это контекст, он вызван тем, что системе приходиться балансировать и решать проблему неопределенности. Например, у нас есть текст: Маша мыла - предсказали "раму". Но на самом деле мы предсказали распределение, а не конкретно "раму".
Пусть входной сигнал это распределение X. Тогда H (Predict Coding) = X - Y это распределение. Так вот, на следующем шаге X = X*H. В данном случае H это множество других вероятностей, которые могут привести к альтернативным маршрутам, которые могут быть более устойчивыми чем предсказанный Y. Поэтому входной сигнал усиливается, и альтернативный H сильный, то это переключает систему на другой альтернативный маршрут.
В данном случае, если маршрут Y сильнее, то он продолжается. Если H оказывает сильнее влияние, то происходит переключение на альтернативный маршрут, подобие "критического мышление" , точно ли "раму" или там важнее что "мыла утром".
Если же Y и H равны, это значит нет устойчивого маршрута, это аналог "не знаю". Так как ни один из вариантов не является устойчивым предсказанием.
Ну а сам predict coding, это следствие неопределенности. Он связан с тем, что есть ситуации, когда мы пытаемся предсказать следующий шаг, а условная вероятность соответствует сразу нескольким равнозначным вариантам.
То есть predict coding, это не минимизация свободной энергии. А механизм системы выхода из неопределенности и нахождения наиболее устойчивых цепей Маркова, то есть самого вероятного маршрута. Так как предсказание следующего токена не гарантирует, что этот маршрут (цепь Маркова) в целом более устойчивая/сильная.
Тут более понятно (там выложены сами теоремы, правда они опираются на другие): https://t.me/greenruff/2562
Но я могу ручаться что они правильные, так проверял их на практике.
В случае же классической интерпретации FEP predict coding это ошибка. Но это лишено смысла. Так как:
1) Predict coding (acc зона и слои 6 неокортекса) не вычитается в таламус, куда они идут, а модулируют входной сигнал, то есть умножаются, делая его слабее/сильнее.
2) Если мы считаем predict coding ошибкой и все таки вычитаем ее из входного сигнала, то ничего не будет. Модель и так предсказала сигнал, какой нам смысл вычитать из входного сигнала остаток. Это просто приведет к тому же устойчивому сигналу. Мы просто лишаем систему выбора альтернативы, говоря ей усилить текущий предсказанный маршрут, который она и так ранее уже предсказала. Считая, что остальной просто шум. Это лишено всякого смысла и не стыкуется с нейробиологией, если мы посмотрим куда идёт сигнал predict coding и как он влияет на входной сигнал.
Я в свое время рисовал маршрут рекуррентной петли. Он не совсем полный, но отражает смысл. На нем видно:
1) predict coding идёт в ассоциативные ядра таламуса и формирует альтернативный сигнал
2) predict coding модулирует сенсорный сигнал, а не вычитает. В FEP же если читать ее, predict coding это err. И затем X-err. Но мы такого в реальности не наблюдаем. А вот модуляция несёт совсем другой смысл.
Он написал чушь.
1) я написал что это компромиссное решение, которое по качеству лучшее. Ого как раз захватывает гармоники через ширину, в то время как в сетки в коде даже этого не делают.
2) LPC делает гораздо, гораздо хуже. Он не приспособлен идеально к речи. Естественно у меня есть код этого через librosa, но там звучание гораздо хуже. Так как librosa больше подходит для неречевых звуков. Что касается pydub, то и с ним у меня была реализация и там тоже что-то было не так. Из всех вариантов, был выбран наиболее лучший по качеству с учётом компромиссов. Остальные давали результат гораздо хуже или ломали что-то ещё.
Вместо того чтобы полагаться на сетки надо проверять, а уже затем утверждать. В этом и заключается проблема, если полагаться на то что утверждает сетка. Я прекрасно знаю, что они отвечают, так как использую их и они в этих моментах очень сильно тупят. И я молчу уже о том, что решая проблему они могут выкинуть что то уже рабочее в коде, какую то деталь, упростить расчет и так далее.
Paart очень известная библиотека. Там же дело не в библиотеке, а к логике реализации. Такие же проблемы возникают и с базами данных. Вот простой пример, который нормально не могут осилить LLM. Нужно перенести SQL с MS SQL на Postgres, это по-моему часть кода одного из отчетов. Ниже два примера MS SQL которые нужно перенести на Postgres. В данном случае есть некоторые участки, где синтаксис будет сильно отличаться или даже может не оказаться аналога. А если еще учесть, что надо динамический запрос, то все усложняется. Вот такие реальные задачи встречаются в жизни.
В первом, LLM постоянно что-то выкидывает, что-то теряет, упускает детали.
Скрытый текст
Во втором, просто тупо допускает ошибки не понимания в чем дело. LLM использует string_agg при конвертировании, и упускает некоторые моменты особенности Postgres при работе с string_agg. Из за этого код она пишет, код при выполнении иногда выдаст ошибку, LLM пытается ее исправить, но зациклено по кругу исправляет одно и тоже, не понимая некоторых нюансов работы string_agg.
Скрытый текст
Подобные вещи встречаются сплошь и рядом.
Praat это самая популярная и эффективная библиотека при работе с голосом. Все LLM ее знают и все равно галлюцинируют на ней часто обращаясь к тому чего нет. Как уже было сказано выше, да она правильная, так как использовал ее при изменении голоса.
Ниже пример, где также используется эта функция. Я прекрасно знаю что на все это пишут LLM, проблема в том, что они не могут не писать, даже там где имеют проблемные места.
Скрытый текст
https://t.me/greenruff/1895
https://t.me/greenruff/1947
https://t.me/greenruff/1868
Я использую LLM, просто у них есть границы применимости.
Давайте так, если вы предлагаете решение, то не нужно просто брать и генерировать его и просить модель объяснить это решение. Стоит сначала взять и проверить его и затем уже предлагать. Если кратко то нет, в вашем случае на выходе вы услышите на фоне звука так же потрескивание или наоборот звуки скрежета.
В предложенном коде все кишит проблемами.
1) форманты содержат ширину, и ее надо учитывать. В коде выше, она считается примитивным образом как bw = -np.log(magnitudes[idx]) * sample_rate / np.pi и дальше просто идет проверка.
2) LPC очень плохо справляет на самом деле с голосом.
3) resample в описанном мной примере делается как компромисс, чтобы не потерять сильно в качестве звука. Это важное отличие, которое агенты просто не могут сделать. Нет такого понятие как компромисс, не могут они это оценить.
4) там еще не мало других проблем, вроде if 90 < f < 5000 and bw < 500 и множества других.
Синтетические тесты тут ни как не помогут. Что вы хотите в них анализировать? Как выстроите их, по какому критерию? Просто частоты сдвинулись или нет? В голосе форманты имеют обертоны, и если вы просто сдвинули какую то частоту то это не будет согласовываться например с ними.
Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
Вы хоть обложитесь сотней агентов, они не сделают.
То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
У нее многие статьи это скорее рассуждающие, то есть теоретические (чем она и занимается по своей специальности). Сложно назвать их научными в плане исследований, а скорее научными в плане рассуждений. Это как если бы был специальный habr для физиков-математиков.
Насчет цитируемости, то она еще в 2019 году писала статью:
https://www.researchgate.net/publication/332884179_Predicting_authors'_citation_counts_and_h-indices_with_a_neural_network
"В данной работе мы описываем и представляем результаты работы простой нейронной сети, которая прогнозирует будущие показатели цитирования отдельных исследователей на основе различных данных из их прошлой деятельности."
Они делали простую нейросеть и прогнозировали цитируемость. На научную работу это не тянет. На хабре многие пишут статью, как что-то спрогнозировали. На GitHub такого много тоже, но для исследования это как-то мелко сегодня. Но тема цитируемости, явно "близка" ей.
Но в остальном, у нее много интересных работ "A derivation of Born’s rule from symmetry", где есть предположение, что вероятности должны быть согласованы с юнитарной структурой гильберта. И из этого ее объяснение показывает, что правило Борна не является случайной догадкой, а математически единственный возможный вариант, совместимый с симметрией квантовой механики. И таких статей у нее много. Они о построении различных гипотез, связях и так далее.
Если обобщить это, то тема цитируемости ей очень близка + большинство ее это гипотезы и рассуждения, но безусловно очень интересные. Так что понятно почему ее лично волнуют LLM статьи:
1) написание большего кол-ва статей, приведет к тому, что ей будет сложнее конкурировать с ними
2) ее статьи как раз рассуждающие, с различными гипотезами, теоретические но под разным углом и разными предположениями. Такое очень удобно делать с помощью LLM.
Другое дело, что LLM сами ничего не сделают. Для этого надо понимать, что они пишут, что попросить проанализировать, разобрать что они написали и отсеять бред. Так что автор либо боится что будет завалено мусором (но мусорных научных статей и так большинство), либо что упростит порог входа и написание теоретически рассуждающих статей другими физиками либо это просто страх неопределенности.