UPD: …а одного «журналиста» (самозванца вроде) астронавт уже накормил «лунными тумаками», говорят, было невкусно. Лунные тумаки — это вам не лунный рис :-D
когда запускаются проекты, требующие логирования, то всегда говорят о гибкости системы логирования, подобной Graylog, но забывают, что эта гибкость потребует от вас колоссальных ресурсов,
А вы логируете health check ручки? А то иногда открываешь логи а там проверки здоровья каждые 10 секунд.
По дороге он конкретно так проливает секреты. Наши секреты теперь повсюду, но только не там, где ими можно удобно пользоваться.
У нас настроили интеграцию Волта и Куба через external-secrets.io/v1beta1. С точки зрения пользователя, прописывашешь пути в Волту и в каком секрете его хранить. Это удобно.
Сервис акаунт Кубера добавлятеся во владение нужной частью секретов в Волте и лишнее просто не видит.
Вот и тут так же будет - поставить тупую первую линию(скажем, на локальной сетке) будет дешевле, чем сразу все запросы в более умный ИИ (какому-то поставщику) отправлять.
Не уверен, что там будет такая разница. Топовые модели стоят не настолько дороже, чтобы заморачиваться с двумя моделями.
На паре тысяч запросов в день такие операции не окупятся.
Наверно в том как агенты правильно использовать надо. Он не должен быть первым уровнем техподдержки, он должен быть всё техподдержкой. Часть его щупалец это ИИ который отвечает на первый уровень, часть АПИ к разным системам данных (проверить если пинг до вашего роутера в случае телекома). Часть АПИ к человеку второго уровня: Переслать вопрос на второй уровень и ждать ответа.
При этом в отличии от человека на первом уровне он может быстро собрать и агрегировать все данные об обращении и предоставить к ним доступ. Люди не смогут так быстро агрегировать и передавать информацию, а после 100 звонка на день не думаю, что качество передачи информации от человека будет сильно превышать AI. Да и будем честны, на первом уровне техподдержки платят плохо, поэтому умные там не задерживаются долго.
Конечно на каждом шаге можно сделать фигню, и даже многие интеграторы так и сделают.
Алиасы нужны для решения конфликта имён и только для этого. Добавление промежуточных имён редко делает код чище. Практики принятые в датасаенсе часто не являются примерам хорошего дизайна.
Мои инструменты это автоматизация. Форматер + линтер + статический анализ задают нижнюю планку качества кода на хорошем уровне. Мой личный шаблон https://github.com/Cjkjvfnby/project_template, давно не обновлялся, но всё еще актуальный.
Я именно про радикальность, что это ошибки джунов. Проверить, что все вызовы не возвращают налл это зона ответственности человека и человек ошибается. Ну и то что сегодня не может быть, завтра станет его возвращать. Да линторами и практиками можно значительно улучшить ситуацию.
микросервисы - это спорное архитектурное решение, гарантирующее в первую очередь job security архитектору (ни чего другого микросервисы не могут предложить, чего другая архитектура не может).
Всё-же что-то могут. Просто таких ситуаций значительно меньше, чем проектов с микросервисами.
Про отсутствие тулинга вокруг люто плюсую. Минимальный уровень инфраструктуры необходимый для них - это высокий уровень для обычных проектов.
Тут баланс между работами по улучшению надёжность и стоимости инцидентов. Теперь у них есть данные, чтобы принять решение.
Зато всем хватило.
А вы логируете health check ручки? А то иногда открываешь логи а там проверки здоровья каждые 10 секунд.
У нас настроили интеграцию Волта и Куба через external-secrets.io/v1beta1. С точки зрения пользователя, прописывашешь пути в Волту и в каком секрете его хранить. Это удобно.
Сервис акаунт Кубера добавлятеся во владение нужной частью секретов в Волте и лишнее просто не видит.
number is incorrect: number is incorrect: number is incorrect
Монетку будет надёжднее подбросить, чем спрашивать нуансы у AI. Он этого не знает, он подберёт похожий ответ.
Не уверен, что там будет такая разница. Топовые модели стоят не настолько дороже, чтобы заморачиваться с двумя моделями.
На паре тысяч запросов в день такие операции не окупятся.
Наверно в том как агенты правильно использовать надо. Он не должен быть первым уровнем техподдержки, он должен быть всё техподдержкой. Часть его щупалец это ИИ который отвечает на первый уровень, часть АПИ к разным системам данных (проверить если пинг до вашего роутера в случае телекома). Часть АПИ к человеку второго уровня: Переслать вопрос на второй уровень и ждать ответа.
При этом в отличии от человека на первом уровне он может быстро собрать и агрегировать все данные об обращении и предоставить к ним доступ. Люди не смогут так быстро агрегировать и передавать информацию, а после 100 звонка на день не думаю, что качество передачи информации от человека будет сильно превышать AI. Да и будем честны, на первом уровне техподдержки платят плохо, поэтому умные там не задерживаются долго.
Конечно на каждом шаге можно сделать фигню, и даже многие интеграторы так и сделают.
Сейчас на хайпе ИИ агенты, а у них иже есть память.
Выкидывать только свои исключения это очень хорошая практика.
Что за
перьёд? Товаришь Chat J'ai peté постарался?Можно просто в отдельную функцию вынести.
Алиасы нужны для решения конфликта имён и только для этого. Добавление промежуточных имён редко делает код чище. Практики принятые в датасаенсе часто не являются примерам хорошего дизайна.
Мои инструменты это автоматизация. Форматер + линтер + статический анализ задают нижнюю планку качества кода на хорошем уровне. Мой личный шаблон https://github.com/Cjkjvfnby/project_template, давно не обновлялся, но всё еще актуальный.
@transactional, а также try with resources позволяет одной строкой сделать два действия, открыть и закрыть.
Разбиение этого кода на две строки даёт возможность совершить ошибку.
Такие ошибки может быть сложно поймать, так как многие вещи всё же закроются самостоятельно при выходе из программы.
Мне такой подход в go не нравится.
В современной разработке эту будет отсеяно на стадии CI и никто кроме автора об этом не узнает.
И не пихать не связанные вещи в один файл.
Я именно про радикальность, что это ошибки джунов. Проверить, что все вызовы не возвращают налл это зона ответственности человека и человек ошибается. Ну и то что сегодня не может быть, завтра станет его возвращать. Да линторами и практиками можно значительно улучшить ситуацию.
Всё-же что-то могут. Просто таких ситуаций значительно меньше, чем проектов с микросервисами.
Про отсутствие тулинга вокруг люто плюсую. Минимальный уровень инфраструктуры необходимый для них - это высокий уровень для обычных проектов.
Вы наверно очень внимательный и дотошный. Или дальше hello word не заходили.
GDPR то здесь при чём?
С тем же микросовтом, заключается контракт, и запросы в нейронки не идут на обучение.
Да и свои модельки тренировать пока не заметили.
Похвалил свой продукт.