Я специально не вношу это внутрь LLM потому, что внешняя детерминированная система не должна смешиваться с вероятностной LLM, она говорит ей “да/нет/не знаю” вот только от этого можно прямо сказать корректный вывод или нет.
А когда вы смешиваете определенный ответ с вероятностным у вас получится всё равно вероятностный ответ, таким образом вы маскируете проблему, а не явно её отслеживаете.
Вы снова спорите не с тем, что написано у меня, а с более удобной для вас версией тезиса.
Я нигде не утверждаю, что можно “формализовать весь реальный мир”; в статье прямо сказано обратное: я беру маленький логический язык и строю намеренно узкий проверяемый слой.
Мой тезис не в том, что LLM надо запретить быть LLM(тавтология здесь уместна :) ), а в том, что её ответ нельзя принимать на доверии там, где нужна корректность.
Поэтому система у меня не говорит “наверное правильно”, а говорит: “прошло проверку / не прошло / недостаточно данных”. Меняющийся бизнес-контекст — это проблема обновления входных данных и правил, а не аргумент против самой верификации.
Вы, переносите инженерные проблемы на математическую логику и объявляете это её недостатком.
Перечитайте статью: вы сейчас возражаете не моей статье, а своему пересказу статьи.
Цель данного исследования была для того, чтобы модель не шла по заданной грамматике, а то чтобы модель должна следовать логической последовательности
В моём примере cases‑V2E01 явно указан, что модели сложно перенести логическое утверждение, как раз таки гарантия проверяется внутри детерминированного ядра(hilbert system), который проверяет не семантику, а формулы выведения и проверяет ответ, в вашем предложении вы только исправляете текст нейронной сети, но то как она последовательно логически придёт к выводу вы не решите, за вас это должна сделать детерминированная строгая математическая модель, а внутри github исследования есть данные, что чем больше вы загружаете логических цепочек тем сильнее ваша LLM модель будет путаться в логических переходах.
Ваш аргумент "заставить давать осмысленный результат" вашим способом вы получите, только формальность, ответ который будет устраивать вас визуально и семантически в этом и заключается это иллюзия правдоподобности, а не создание логически верного ответа, таким образом можно замаскировать проблему, а не её решать (а решают её только детерминированные строгие системы).
P.S. Вы сколько угодно можете чинить своими сложными промтами, внешними инструментами, добавлять туда RAG, делать LLM-as-judge и т.д. на эти LLM модели, но вы не почините их логику работы, повторюсь из исследования природа LLM моделей вероятностная, в начале статьи прямо написано даже при безошибочных обучающих данных данных приведет к языковой модели, генерирующей ошибки.
Я специально не вношу это внутрь LLM потому, что внешняя детерминированная система не должна смешиваться с вероятностной LLM, она говорит ей “да/нет/не знаю” вот только от этого можно прямо сказать корректный вывод или нет.
А когда вы смешиваете определенный ответ с вероятностным у вас получится всё равно вероятностный ответ, таким образом вы маскируете проблему, а не явно её отслеживаете.
Вы снова спорите не с тем, что написано у меня, а с более удобной для вас версией тезиса.
Я нигде не утверждаю, что можно “формализовать весь реальный мир”; в статье прямо сказано обратное: я беру маленький логический язык и строю намеренно узкий проверяемый слой.
Мой тезис не в том, что LLM надо запретить быть LLM(тавтология здесь уместна :) ), а в том, что её ответ нельзя принимать на доверии там, где нужна корректность.
Поэтому система у меня не говорит “наверное правильно”, а говорит: “прошло проверку / не прошло / недостаточно данных”. Меняющийся бизнес-контекст — это проблема обновления входных данных и правил, а не аргумент против самой верификации.
Вы, переносите инженерные проблемы на математическую логику и объявляете это её недостатком.
Перечитайте статью: вы сейчас возражаете не моей статье, а своему пересказу статьи.
Цель данного исследования была для того, чтобы модель не шла по заданной грамматике, а то чтобы модель должна следовать логической последовательности
В моём примере cases‑V2E01 явно указан, что модели сложно перенести логическое утверждение, как раз таки гарантия проверяется внутри детерминированного ядра(hilbert system), который проверяет не семантику, а формулы выведения и проверяет ответ, в вашем предложении вы только исправляете текст нейронной сети, но то как она последовательно логически придёт к выводу вы не решите, за вас это должна сделать детерминированная строгая математическая модель, а внутри github исследования есть данные, что чем больше вы загружаете логических цепочек тем сильнее ваша LLM модель будет путаться в логических переходах.
Ваш аргумент "заставить давать осмысленный результат" вашим способом вы получите, только формальность, ответ который будет устраивать вас визуально и семантически в этом и заключается это иллюзия правдоподобности, а не создание логически верного ответа, таким образом можно замаскировать проблему, а не её решать (а решают её только детерминированные строгие системы).
P.S. Вы сколько угодно можете чинить своими сложными промтами, внешними инструментами, добавлять туда RAG, делать LLM-as-judge и т.д. на эти LLM модели, но вы не почините их логику работы, повторюсь из исследования природа LLM моделей вероятностная, в начале статьи прямо написано даже при безошибочных обучающих данных данных приведет к языковой модели, генерирующей ошибки.