chaturanga

Повторюсь-таки.
Сервис определения AI-текстов на основе AI изначально обречён - недетерминированная гадалка не исполнит роль детерминированного судьи...

внешняя связанность каналов BY завязана на RU на 80%+

как запасной вариант, ДА, как решение НЕТ

как и никогда не удастся добиться детерменированного результата

ну и просто гултранслейт :)

Ну и просто "лобовой" первод gemini, с сохранением спцифичных кавычек и тире.

что собственно и подтвердилось

Покидал куски своих статей с хабра.
То что проиндексировано считает живым текстом (соотвественно выдаёт ссылку).
То что давно в черновиках и остутствует в поиске считает генерёнкой.
Учитывая, что стилистика/авторство текстов неизменно, то как будто основывается на критерии нахождения в поиске...

Ну тут я как раз полность согласен - отдебажить openresty без AI способен только Ичун Чжан :)

убыстряют лишь в случае, когда promt-оператор способен корректно составить запрос. И если вернуться к моему предыдущему ответу master32, то сложность составления prompt для limit_req стороннего модуля такова, что мне будет проще и быстрее сделать это всё вручную, чем перепроверять условную 1000 строк сгенерированного агентом когда.

пример с return - это очень упрощённая ситуация, в реальности мы же работаем не с просто return 200 "bu", а делаем append модуля (например для прямых запросов к БД), который работает минуя http фазу, где после append() вся обработка уходит в nginx event loop, что очень дёшево. Но здесь, если мы хотим всё-же иметь возможность делать limit_req, нам придётся пожертвовать дешевизной и делать append() аж в CONTENT_PHASE, что может свести на ноль саму идею прямых запросов.