Em qualquer livro ou frase que você veja,
quando falam do item 3, sempre escrevem desse jeito,
mas, na prática,
por que está perguntando isso
por que só foi mencionar isso agora
até isso vai perguntar
existe a possibilidade do combo de 3 etapas fazer com que te vejam como um parceiro de baixa qualidade
Neste texto, em vez de dicas realmente práticas, ele aborda mais só uma visão geral em alto nível, então se eu fosse acrescentar mais algumas dicas para desenvolver agents/fluxos agentic baseados em LLM, no fim das contas LLMs são baseados em transformers (isto é, inferência probabilística; com base no token/state atual, eles não “entendem” contextual ou semanticamente a próxima palavra para então produzi-la, mas geram o output de forma probabilística), então por melhor que seja o sys prompt, com frequência eles não dão a resposta desejada (por exemplo, você pede uma resposta em formato JSON e às vezes ele esquece um } etc.). Por isso, é essencial sempre adicionar várias funções de fallback baseadas em regex.
E quando você escreve um sys prompt para obter structured output, normalmente usa um modelo non-reasoning, e quanto maior o contexto, mais frequentemente ocorrem alucinações, então muitas vezes é melhor criar vários sys prompts e encadear eles.
Ao desenvolver um serviço, vários erros podem acontecer, então o ponto-chave é projetar a arquitetura do serviço de forma modular e fault-tolerant (por exemplo, deixar o supervisor agent assíncrono e os demais agents síncronos), especialmente no caso de sistemas agentic e agents, onde outputs inesperados acontecem com frequência.
Por isso, desde o início, ao escrever o código, é bom seguir SRP e escrever de forma declarativa; quero dizer que vale a pena adotar uma abordagem funcional (= sem side effects e com fluxo intuitivo).
E isso pode variar dependendo de você usar LLM via API ou servir o modelo diretamente, mas se for servir um SLM ou LLM por conta própria, é melhor não fazer model serving no mesmo servidor que hospeda o backend; separar IO bound tasks e CPU bound tasks (isto é, tasks que exigem GPU, multiplicação de matrizes e coisas do tipo) em servidores diferentes é melhor para fault tolerance (por exemplo, hospedar CPU bound tasks no Runpod).
Além disso, há várias outras dicas de desenvolvimento, mas vou parar por aqui para não ficar longo demais.
Colocaram uma tradução automática porca pra estragar a tradução em coreano, e pelo visto isso evoluiu ainda mais. Não conseguiram nem barrar a tradução automática, então agora vamos todos provar também essa IA porca enfiada goela abaixo!
Odeio muito recursos de IA, especialmente serviços que ficam em espera em segundo plano dizendo que vão me ajudar.
Se eles rodam remotamente, há o problema de meus dados serem fornecidos; se rodam localmente, há o problema de consumirem os recursos do meu computador (CPU, memória, bateria, ...).
Concordo totalmente com você!
kkkkkkkk
Desenvolvimento guiado por alucinação... talvez seja assim que dá para chamar;;
> Parecia ideal para assumir a liderança, mas recusou esses papéis adicionais.
> Quando o autor propunha novos desafios para o crescimento ...
Do ponto de vista de um profissional técnico, não seria crescimento se tornar ainda melhor naquilo que já faz bem?
Muito obrigado pelas gentis palavras!!
Talvez o problema tenha sido pensar no nível de salário e nas condições, que não acompanharam o aumento de responsabilidades e de trabalho.
Isso é muito comum
Claro, se for um bom líder, ele vai ouvir com gentileza e
resolver o problema com precisão
Em qualquer livro ou frase que você veja,
quando falam do item 3, sempre escrevem desse jeito,
mas, na prática,
por que está perguntando isso
por que só foi mencionar isso agora
até isso vai perguntar
existe a possibilidade do combo de 3 etapas fazer com que te vejam como um parceiro de baixa qualidade
Eu também estou atualmente criando um Computer-use Agent chamado UseDesktop.
https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
Concordo com a maior parte do que foi dito.
Neste texto, em vez de dicas realmente práticas, ele aborda mais só uma visão geral em alto nível, então se eu fosse acrescentar mais algumas dicas para desenvolver agents/fluxos agentic baseados em LLM, no fim das contas LLMs são baseados em transformers (isto é, inferência probabilística; com base no token/state atual, eles não “entendem” contextual ou semanticamente a próxima palavra para então produzi-la, mas geram o output de forma probabilística), então por melhor que seja o
sys prompt, com frequência eles não dão a resposta desejada (por exemplo, você pede uma resposta em formato JSON e às vezes ele esquece um}etc.). Por isso, é essencial sempre adicionar várias funções de fallback baseadas em regex.E quando você escreve um
sys promptpara obter structured output, normalmente usa um modelo non-reasoning, e quanto maior o contexto, mais frequentemente ocorrem alucinações, então muitas vezes é melhor criar váriossys promptse encadear eles.Ao desenvolver um serviço, vários erros podem acontecer, então o ponto-chave é projetar a arquitetura do serviço de forma modular e fault-tolerant (por exemplo, deixar o supervisor agent assíncrono e os demais agents síncronos), especialmente no caso de sistemas agentic e agents, onde outputs inesperados acontecem com frequência.
Por isso, desde o início, ao escrever o código, é bom seguir SRP e escrever de forma declarativa; quero dizer que vale a pena adotar uma abordagem funcional (= sem side effects e com fluxo intuitivo).
E isso pode variar dependendo de você usar LLM via API ou servir o modelo diretamente, mas se for servir um SLM ou LLM por conta própria, é melhor não fazer model serving no mesmo servidor que hospeda o backend; separar IO bound tasks e CPU bound tasks (isto é, tasks que exigem GPU, multiplicação de matrizes e coisas do tipo) em servidores diferentes é melhor para fault tolerance (por exemplo, hospedar CPU bound tasks no Runpod).
Além disso, há várias outras dicas de desenvolvimento, mas vou parar por aqui para não ficar longo demais.
Espero que isso ajude alguém.
Que tal um serviço instalado em um servidor remoto privado?
Colocaram uma tradução automática porca pra estragar a tradução em coreano, e pelo visto isso evoluiu ainda mais. Não conseguiram nem barrar a tradução automática, então agora vamos todos provar também essa IA porca enfiada goela abaixo!
Até CGI tudo bem, mas a reação ao JSP é surpreendente mesmo kkk
Será que o JSP já virou uma relíquia tão antiga assim?
Odeio muito recursos de IA, especialmente serviços que ficam em espera em segundo plano dizendo que vão me ajudar.
Se eles rodam remotamente, há o problema de meus dados serem fornecidos; se rodam localmente, há o problema de consumirem os recursos do meu computador (CPU, memória, bateria, ...).
Parece que vai ser uma boa referência.
Como desenvolvedor de origem russa, ele passou da Yandex para a Riot e agora se mudou para a JPMorganChase.
kkkkkkkkkk muito engraçado
Parece muito que só estão mudando o nome.
https://x.com/soham_btw/status/1940952786491027886
Vendo o tweet, é um espetáculo lamentável...
Estou usando um N100 e um AMD 4825U, e estou satisfeito.
Instalei o Proxmox no N100 e estou usando muito bem. Na hora de comparar com o Pi 5, o preço fica elas por elas, mas a diferença é grande haha