Мысли о Chain‑of‑Thought

[LOG-AI]

Автор прав, попытка заставить ИИ «думать вслух» и строить длинные логические цепочки — это дикий перерасход памяти и времени сервера. Стоит модели ошибиться в одном слове в начале — и весь дальнейший результат летит в мусор.

В реальной b2b-разработке мы уже давно пришли ровно к гибридной схеме, о которой вы пишете. ИИ принципиально нельзя отдавать принятие решений. Нейросеть идеальна только на входе — как переводчик из человеческого хаоса (кривой текст, голосовые с опечатками) в жесткий, чистый JSON. На этом всё.

Как только мы получили этот JSON, нейросеть отключается, а управление перехватывает классический надежный бэкэнд (код на Python, сценарии n8n и база Postgres). Проверка остатков, сверка артикулов и отправка данных в CRM идут по строгим правилам кода, а не по теории вероятности. Такой подход полностью убирает выдумки ИИ и позволяет запускать быстрые закрытые системы на обычном железе клиента, не переплачивая за аренду дорогущих видеокарт.

[MaximKovalev]

Согласен почти со всем. Кроме "полностью". Классический бэкенд - как, по сути, переход к символьной логике, снимает много вопросов. Согласен. На счет учета НСИ - тут сложнее. Во многом зависит от домена и задачи. LLM считать не умеет и остатки лучше вычислять "классическими" методами. Ваш пример - отличная демонстрация гибридного подхода.

Другое дело - семантика. Например, в задачах дедубликации или анализа рекламных объявлений -data mining. По моей практике вероятность ложно положительных и ложно отрицательных выбросов велика. Да, все тот же вероятностный подход может подпортить результат. И тут, конечно, еще от домена зависит. Одно дело, металлургия, где главное не полениться и сделать описания классов. Другое текстиль, где много описательных позиций типа "красное платье в мелкий горошек". Сам занимаюсь этой проблематикой. Python и Postgres - это инструменты, где логику надо реализовывать.