Лол, чел, в БД дубли не появлялись. Ошибка просто выдавалась в эндпоинтах. А почему внезапно приходили дубли? Почти наверняка из-за таймаута. Хоть POST запрос неидемпотентен (его НЕЛЬЗЯ ретраить), некоторые "хорошие" сервисы всё равно делают это. Отсюда и дубли при таймауте. Так что Ваше замечание некорректно. Просто автор, скорее всего, забыл это упомянуть, или даже не задумался о том, куда исчезли дубли)
просто для base64, мне кажется, эндпоинт всё-таки избыточен... В доке (в том же сваггере) можно написать, что "это поле принимает base64". Можно даже в названии параметра это указать: "searchQueryBase64". Вам же по-любому нужно будет это указать)) всё равно есть промежуток между сериализацией и отправкой итогового запроса
В любом случае, очень круто, что столько внимания уделяется документации
А также есть утилиты статического анализа уязвимостей по типу trivy, которые справляются с этим лучше человека и ИИ вместе взятых :) и ещё наборы для проверки безопасности в живых тестах по типу xspider. Эта тема не нова, и уже есть куча решений, о которых на фоне ИИ-бума просто забыли
Да, наверняка какой-нибудь use-after-free эти инструменты не увидят. Ответственность за это целиком и полностью ложится на плечи программиста. Вот тут ИИшка действительно может быть полезна
А почему просто не сериализовать на клиенте? Сериализация намного проще шифрования. Шифрование вообще избыточно в этом случае, ведь данные в любом случае передаются "в открытую" вначале. На мой взгляд, это уже сильный оверхед только ради красивой документации. При медленном интернете (что особенно актуально сейчас) это будет боль...
Вы серьезно? Человек говорит о том, что ВСЕ нейронки так или иначе галлюцинируют. Это особенность из архитектуры. Они же просто предсказывают токены, даже не понимая сути вопроса и своего ответа
Ещё странно, что автор делает str(some_bytes.decode()). Ведь decode возвращает строку)) это, конечно, с парсингом тайтла для получения никнейма вообще не сравнится по странности, но тоже не заметку: так делать не надо
Кстати, а чем хорош iTerm? У меня недолгое время был довольно старый мак эир, 13-го года. Я довольно часто пользовался терминалом, но никаких прелестей не почувствовал. Вот теперь сижу думаю, что я что-то важное упустил))
Так я говорю: создайте свой cat. У него будет идентичное название и идентичный способ использования. Когда ИИ будет вызывать "bash -c cat filename.txt", он на самом деле будет вызывать не встроенный cat, а вашу реализацию. И теперь смотрите, какая магия. Если файл превышает заданное ограничение на размер, команда, которая выглядит и вызывается точно так же, как падает с вашей кастомный ошибкой: "file too large. Please use 'cat filename.txt START:END'". То есть код ошибки сразу же подсказывает ИИшке правильное использование команды. Второй пример: ИИ пытается использовать sed. Но для sed у вас своя реализация, который на любой вызов говорит: "sed is not supported. Please use git patch". ИИ сразу вспоминает, что нужно использовать. А для docker/npm/etc. так же будет своя реализация, которая просто является алиасом: она перехватывает все аргументы, переданные ИИ, и вызывает реальную команду. Таким образом, у вас будет собственный клиентский шелл для ИИ, изменяющий поведение УЖЕ СУЩЕСТВУЮЩИХ команд, с ПОЧТИ ИДЕНТИЧНЫМ API. Вот что я имел ввиду. Если нужны подробности, предлагаю перейти в ЛС, а то эта ветка совсем разбухнет))
Да не потому, что ИИ сгенерировано. А потому, что сгенерировано бездумно. Нет нормальных раскрытых примеров, нет подробностей, нет КОНКРЕТИКИ. ИИ никогда конкретику не сгенерирует. Это отличительная черта таких бездумных статей. Когда конкретика будет, будут плюсы
Не совсем)) Вы же говорите, что ИИ читает текст через cat вместо вашего инструмента. Так что мешает подменить реализацию самого cat? Просто сделайте его своим инструментом) тогда даже инструкций для ИИ не нужно будет писать
Так же можно сделать и с остальными командами. Запретить ей писать в файлы в обход патчей на уровне middleware шелла - и все проблемы, описанные в статье, решатся (на мой взгляд)
Я бы не давал полный доступ ИИшке к шеллу. Вместо этого создал бы обёртку над bash. В этой обёртке есть разрешенные команды-алиасы. На некоторые требуется подтверждение, на некоторые - нет. Это и будет набором инструментов, только которые интуитивно понятны системе. Если ИИ пытается выполнить `cat largefile.txt` - выдаётся ошибка "файл слишком большой. Укажите диапазон в формате старт:стоп", или что-то подобное. Команд для записи просто не должно быть - всё через патчи. На npm/TS/RS/PHP/docker/yarn и т.д. будут "прозрачные" алиасы без подтверждений. Или с подтверждением. На остальные команды писать "permission denied" или "unsupported in this project"
Получится как middleware для шелла. Полная изоляция, абсолютно интуитивное управление. Можно будет сколько угодно инструментов впихнуть. Попробуйте :)
Не согласен. LLM читает быстро, но поверхностно. Если Вы про контекстное окно, то оно забивается очень быстро, после чего LLM забывает всё больше фактов и путается. Если же Вы про обучение, то тут механизм другой. LLM предсказывает наиболее вероятные токены. Так как на просторах гитхаба и в статьях очень много довольно старого материала, логично, что старые фичи будут казаться LLM более вероятными в использовании. А информации по новым фичами действительно недостаточно, т.к. для обучения нужно большое количество примеров
Когда человек читает, он ассоциирует текст со своим опытом. У LLM, увы, нет опыта. В этом принципиальная разница. Поэтому человеку так сложно запомнить что-то большое. И поэтому человек может разобраться в чем-то по-настоящему глубоко
Почему люди создали SPA? Потому что глупо загружать каждый раз одни и те же элементы: хедер, футер, меню и т.д. Кэширование страдает от того, что всё в едином HTML. Но зачем всё так переусложнять, если можно:
Рендерить базовый Layout с шапкой и футером
Внутрь Layout добавить банальный iframe
Менять src у iframe в зависимости от нажатой кнопки в меню
При этом страницы можно писать на любом фреймворке. Они абсолютно независимы. Основная страница в браузере лишний раз не перезагружается, перезагружается только iframe. В чем проблема такого подхода?))
P.S. я конечно немного утрирую. Но ведь помимо этого существует ещё море более лёгких решений, чем SSR с гидратацией и тому подобное
Скажем так, в СССР с "пятилеткой за 1 год" это было выражено наиболее ярко
Это очень радует)
Было бы интересно увидеть комментарии людей из стартапов типа OpenAI)) после речей Альтмана складывается ощущение, что там люди 24/7 работают
Искал этот коммент :)
Хочу дополнить, что FastAPI вполне неплохо работает с синхронным кодом, запуская обработчики в отдельных потоках
А почему RESTful - плохо? Да, всё, что Вы перечислили до этого, имеет место быть. Но это не мешает существовать корректному RESTful)
P.S. у GET методов нет body (или тут имеется ввиду не метод, а "суть" - получение данных?)
Лол, чел, в БД дубли не появлялись. Ошибка просто выдавалась в эндпоинтах. А почему внезапно приходили дубли? Почти наверняка из-за таймаута. Хоть POST запрос неидемпотентен (его НЕЛЬЗЯ ретраить), некоторые "хорошие" сервисы всё равно делают это. Отсюда и дубли при таймауте. Так что Ваше замечание некорректно. Просто автор, скорее всего, забыл это упомянуть, или даже не задумался о том, куда исчезли дубли)
просто для base64, мне кажется, эндпоинт всё-таки избыточен... В доке (в том же сваггере) можно написать, что "это поле принимает base64". Можно даже в названии параметра это указать: "searchQueryBase64". Вам же по-любому нужно будет это указать)) всё равно есть промежуток между сериализацией и отправкой итогового запроса
В любом случае, очень круто, что столько внимания уделяется документации
А также есть утилиты статического анализа уязвимостей по типу trivy, которые справляются с этим лучше человека и ИИ вместе взятых :) и ещё наборы для проверки безопасности в живых тестах по типу xspider. Эта тема не нова, и уже есть куча решений, о которых на фоне ИИ-бума просто забыли
Да, наверняка какой-нибудь use-after-free эти инструменты не увидят. Ответственность за это целиком и полностью ложится на плечи программиста. Вот тут ИИшка действительно может быть полезна
А почему просто не сериализовать на клиенте? Сериализация намного проще шифрования. Шифрование вообще избыточно в этом случае, ведь данные в любом случае передаются "в открытую" вначале. На мой взгляд, это уже сильный оверхед только ради красивой документации. При медленном интернете (что особенно актуально сейчас) это будет боль...
А в чём смысл писать "клонируй проект ..., установи через ...", если в консоли есть автокомплит?))
Вы серьезно? Человек говорит о том, что ВСЕ нейронки так или иначе галлюцинируют. Это особенность из архитектуры. Они же просто предсказывают токены, даже не понимая сути вопроса и своего ответа
Согласен, это жесть какая-то
Ещё странно, что автор делает str(some_bytes.decode()). Ведь decode возвращает строку)) это, конечно, с парсингом тайтла для получения никнейма вообще не сравнится по странности, но тоже не заметку: так делать не надо
Кстати, а чем хорош iTerm? У меня недолгое время был довольно старый мак эир, 13-го года. Я довольно часто пользовался терминалом, но никаких прелестей не почувствовал. Вот теперь сижу думаю, что я что-то важное упустил))
Так я говорю: создайте свой cat. У него будет идентичное название и идентичный способ использования. Когда ИИ будет вызывать "bash -c cat filename.txt", он на самом деле будет вызывать не встроенный cat, а вашу реализацию. И теперь смотрите, какая магия. Если файл превышает заданное ограничение на размер, команда, которая выглядит и вызывается точно так же, как падает с вашей кастомный ошибкой: "file too large. Please use 'cat filename.txt START:END'". То есть код ошибки сразу же подсказывает ИИшке правильное использование команды. Второй пример: ИИ пытается использовать sed. Но для sed у вас своя реализация, который на любой вызов говорит: "sed is not supported. Please use git patch". ИИ сразу вспоминает, что нужно использовать. А для docker/npm/etc. так же будет своя реализация, которая просто является алиасом: она перехватывает все аргументы, переданные ИИ, и вызывает реальную команду. Таким образом, у вас будет собственный клиентский шелл для ИИ, изменяющий поведение УЖЕ СУЩЕСТВУЮЩИХ команд, с ПОЧТИ ИДЕНТИЧНЫМ API. Вот что я имел ввиду. Если нужны подробности, предлагаю перейти в ЛС, а то эта ветка совсем разбухнет))
Вы не понимаете)) запрет на уровне шелла. Я предлагаю вам написать свой шелл
Да не потому, что ИИ сгенерировано. А потому, что сгенерировано бездумно. Нет нормальных раскрытых примеров, нет подробностей, нет КОНКРЕТИКИ. ИИ никогда конкретику не сгенерирует. Это отличительная черта таких бездумных статей. Когда конкретика будет, будут плюсы
Не совсем)) Вы же говорите, что ИИ читает текст через cat вместо вашего инструмента. Так что мешает подменить реализацию самого cat? Просто сделайте его своим инструментом) тогда даже инструкций для ИИ не нужно будет писать
Так же можно сделать и с остальными командами. Запретить ей писать в файлы в обход патчей на уровне middleware шелла - и все проблемы, описанные в статье, решатся (на мой взгляд)
Я бы не давал полный доступ ИИшке к шеллу. Вместо этого создал бы обёртку над bash. В этой обёртке есть разрешенные команды-алиасы. На некоторые требуется подтверждение, на некоторые - нет. Это и будет набором инструментов, только которые интуитивно понятны системе. Если ИИ пытается выполнить `cat largefile.txt` - выдаётся ошибка "файл слишком большой. Укажите диапазон в формате старт:стоп", или что-то подобное. Команд для записи просто не должно быть - всё через патчи. На npm/TS/RS/PHP/docker/yarn и т.д. будут "прозрачные" алиасы без подтверждений. Или с подтверждением. На остальные команды писать "permission denied" или "unsupported in this project"
Получится как middleware для шелла. Полная изоляция, абсолютно интуитивное управление. Можно будет сколько угодно инструментов впихнуть. Попробуйте :)
А теперь попросите исправить код)))
Не согласен. LLM читает быстро, но поверхностно. Если Вы про контекстное окно, то оно забивается очень быстро, после чего LLM забывает всё больше фактов и путается. Если же Вы про обучение, то тут механизм другой. LLM предсказывает наиболее вероятные токены. Так как на просторах гитхаба и в статьях очень много довольно старого материала, логично, что старые фичи будут казаться LLM более вероятными в использовании. А информации по новым фичами действительно недостаточно, т.к. для обучения нужно большое количество примеров
Когда человек читает, он ассоциирует текст со своим опытом. У LLM, увы, нет опыта. В этом принципиальная разница. Поэтому человеку так сложно запомнить что-то большое. И поэтому человек может разобраться в чем-то по-настоящему глубоко
У меня внезапно возникла интересная мысль
Почему люди создали SPA? Потому что глупо загружать каждый раз одни и те же элементы: хедер, футер, меню и т.д. Кэширование страдает от того, что всё в едином HTML. Но зачем всё так переусложнять, если можно:
Рендерить базовый Layout с шапкой и футером
Внутрь Layout добавить банальный iframe
Менять src у iframe в зависимости от нажатой кнопки в меню
При этом страницы можно писать на любом фреймворке. Они абсолютно независимы. Основная страница в браузере лишний раз не перезагружается, перезагружается только iframe. В чем проблема такого подхода?))
P.S. я конечно немного утрирую. Но ведь помимо этого существует ещё море более лёгких решений, чем SSR с гидратацией и тому подобное
P.S.S. даже нашел статью на тему iframe: https://habr.com/ru/companies/oleg-bunin/articles/716084/?ysclid=mmb3pe6bbn488742420 оказывается, всё уже придумали 30 лет назад)) тема с postmessage звучит очень многообещающе