Construir um assistente de IA que realmente se lembra do que falou há cinco minutos pode ser uma verdadeira dor de cabeça. Os utilizadores esperam que as conversas fluam naturalmente, mas a maioria das APIs de chat é sem estado (stateless), o que significa que têm a memória de um peixe dourado. Esquecem-se de tudo no segundo em que uma interação termina.
Este é exatamente o problema que a API de Threads da OpenAI foi criada para resolver. Dá-lhe uma forma de criar sessões de conversa contínuas. Mas será esta a solução mágica para construir um agente de suporte pronto para produção? Embora seja uma ferramenta poderosa, a API de Threads traz o seu próprio conjunto de dores de cabeça no que diz respeito à gestão, custo e escalabilidade.
Este guia irá explicar-lhe o que é a API de Threads da OpenAI, como funciona e onde fica aquém. Veremos também como uma plataforma construída sobre esta tecnologia pode permitir-lhe evitar o trabalho pesado e lançar um agente de IA inteligente em questão de minutos.
O que é a API de Threads da OpenAI?
Primeiro, a API de Threads da OpenAI não é um produto separado que se pode comprar. É uma peça-chave da API de Assistentes, que é maior. A sua principal função é gerir o histórico da conversa. Pode pensar numa thread como uma única sessão de chat contínua.
Quando um utilizador começa a falar com o seu bot, cria uma thread. Cada mensagem que enviam e cada resposta que o assistente dá são adicionadas a essa thread. Isto permite que o assistente acompanhe o contexto ao longo de uma conversa longa, para que não tenha de inserir manualmente todo o histórico da conversa em cada chamada à API. É uma grande melhoria em relação à API de Chat Completions, que é básica e sem estado.
Basicamente, a API de Threads é a "memória" do seu assistente de IA. Cria uma thread para cada conversa e continua a adicionar mensagens a ela. Quando precisa que o assistente responda, aciona uma "Execução" (Run) nessa thread, e ele tem automaticamente todo o histórico de que precisa para dar uma resposta inteligente.
Soa bem, certo? E é, mas como verá, acompanhar todas estas threads quando tem centenas ou milhares de utilizadores é onde as coisas se complicam.
Como funciona a API de Threads da OpenAI: Conceitos centrais
Para perceber realmente como a API de Threads funciona, precisa de compreender o seu lugar na família da API de Assistentes. Existem quatro partes principais que têm de trabalhar em conjunto para que uma conversa aconteça: Assistentes, Threads, Mensagens e Execuções (Runs).
-
Assistentes: Esta é a personalidade de IA que configura. Dá-lhe instruções (como, "És um agente de suporte prestável para uma empresa de sapatos"), escolhe um modelo (como o GPT-4o) e ativa ferramentas como "code_interpreter" ou "file_search". Normalmente, cria apenas um assistente e depois reutiliza-o para todas as suas diferentes conversas com utilizadores.
-
Threads: Uma thread é apenas uma conversa. Quando um novo utilizador inicia um chat, dá início a uma nova thread para ele. Esta thread irá armazenar todas as suas perguntas e todas as respostas do assistente, mantendo todo o contexto dessa conversa devidamente organizado.
-
Mensagens: São apenas os textos individuais de vaivém dentro de uma thread. Quando um utilizador faz uma pergunta, adiciona-a como uma mensagem à sua thread. A resposta do assistente também é adicionada como uma nova mensagem à mesma thread.
-
Execuções (Runs): Uma execução acontece quando diz ao assistente para realmente fazer algo. Quando quer que ele responda a um utilizador, inicia uma execução na sua thread. Isto diz ao assistente para ler as mensagens recentes, usar as suas ferramentas se necessário, e depois publicar a sua resposta de volta na thread.
Toda a configuração é com estado (stateful), o que é fantástico porque significa que não tem de gerir o histórico da conversa. O reverso da medalha é que agora a responsabilidade de criar, armazenar e obter o ID da thread correta para cada utilizador, sempre que interagem com o seu bot, recai sobre si.
Principais funcionalidades e casos de uso da API de Threads da OpenAI
A melhor coisa sobre a API de Threads é a forma como lida com o contexto da conversa por si. Isto torna-a uma escolha sólida para construir alguns tipos diferentes de aplicações:
-
Chatbots de suporte ao cliente: Se criar uma thread única para cada cliente, pode construir um chatbot que se lembra de todo o seu histórico. Isso significa que o suporte parece mais pessoal e consciente do contexto, e os clientes não precisam de repetir os seus problemas.
-
Assistentes de conhecimento interno: Poderia configurar um assistente com a ferramenta "file_search", ligá-lo aos seus documentos internos no Confluence ou Google Docs, e deixar a sua equipa fazer-lhe perguntas. O assistente pode até usar perguntas anteriores na thread para fornecer melhores respostas ao longo do tempo.
-
Tutores interativos: Um bot educacional pode usar uma thread para acompanhar o progresso de um aluno. Lembra-se do que já cobriram e pode identificar onde podem estar a ter dificuldades.
-
Ajudantes de tarefas com múltiplos passos: Para qualquer tarefa que envolva alguma troca de informações, uma thread garante que o assistente consegue manter todos os detalhes necessários organizados do início ao fim.
Em cada um destes casos, a thread atua como a memória de longo prazo necessária para uma conversa real. A API até trata da tarefa complicada de cortar a conversa para caber na janela de contexto do modelo, o que é um bónus agradável para os programadores.
Mas aqui está o senão: enquanto a API lhe dá os ingredientes brutos, fica com a tarefa de construir a interface de utilizador, o sistema de gestão de threads e quaisquer análises por sua conta.
Limitações e desafios da API de Threads da OpenAI
A API de Threads da OpenAI é uma ótima ferramenta de baixo nível, mas vem com algumas dores de cabeça operacionais sérias, especialmente se estiver a tentar construir um produto do mundo real.
-
Não existe uma API para listar threads. Isto é um grande problema. Não pode simplesmente pedir à API uma lista de todas as threads que criou. Como os programadores no Stack Overflow e nos fóruns da comunidade da OpenAI apontaram, uma vez que cria uma thread, tem de guardar o "thread_id" na sua própria base de dados e ligá-lo ao seu utilizador. Se perder esse ID, a conversa desaparece para sempre. Isto força-o a construir e manter um sistema de gestão de threads completamente do zero.
-
Não há uma UI para gerir conversas. Por ser uma API, não há um painel de controlo onde possa ver, gerir ou depurar chats. Se um cliente se queixar de uma resposta estranha da IA, não pode simplesmente procurar o histórico da sua conversa para descobrir o que aconteceu. Teria de construir a sua própria ferramenta interna só para ver os registos.
-
É complicado de configurar e escalar. Um assistente funcional requer que lide com Assistentes, Threads, Mensagens e Execuções (Runs). Também tem de escrever código que verifica constantemente o estado de cada execução, lida com diferentes estados como "requires_action" para chamadas de ferramentas, e depois processa o resultado final. É muita engenharia só para pôr um chatbot simples a funcionar.
-
Os custos podem ser imprevisíveis. É cobrado pelos tokens e por quaisquer ferramentas que use. Como as threads podem ficar bastante longas, o número de tokens de entrada que envia com cada nova mensagem continua a crescer. Isto pode levar a algumas contas surpreendentemente altas no final do mês.
É aqui que uma plataforma gerida pode ser uma salvação. Por exemplo, a eesel AI trata de toda essa gestão de threads e estados por si, automaticamente. Obtém um painel de controlo limpo e de autoatendimento para construir os seus agentes de IA, ligar fontes de conhecimento com um único clique e ver todas as suas conversas com utilizadores num só lugar. Não precisa de construir uma base de dados de IDs de threads ou preocupar-se com a infraestrutura de backend, pode ter um poderoso agente de IA a funcionar em minutos, não em meses.
Uma captura de ecrã do painel de controlo da eesel AI, que fornece uma interface de utilizador para gerir e rever conversas, uma funcionalidade chave que falta na API nativa de Threads da OpenAI.Como funciona a faturação com a API de Threads da OpenAI
Não paga nada extra apenas por usar a API de Threads em si, mas paga pelos serviços da OpenAI em que ela se baseia. Os custos geralmente dividem-se em algumas partes:
| Serviço | Como é faturado |
|---|---|
| Tokens do Modelo | É cobrado pelos tokens de entrada (o histórico de chat que envia) e pelos tokens de saída (a resposta do assistente). À medida que as threads crescem, os seus custos com tokens de entrada aumentam. |
| Uso de Ferramentas | Se o seu assistente usar ferramentas como "code_interpreter" ou "file_search", paga por esse uso. "file_search", por exemplo, tem um custo diário de armazenamento por gigabyte. |
| Armazenamento de Dados | Quaisquer ficheiros que carregue para os seus assistentes usarem também têm taxas de armazenamento. |
Este modelo baseado em tokens pode dificultar a previsão dos seus gastos, uma vez que conversas mais longas e ativas custarão mais. Em comparação, plataformas como a eesel AI oferecem preços transparentes e previsíveis com base no número de interações de IA, não em quantos tokens são usados. Isto significa que não terá uma surpresa desagradável na sua fatura após um mês movimentado, o que torna o orçamento e a escalabilidade muito mais fáceis.
API de Threads da OpenAI: Poderosa mas complexa
A API de Threads da OpenAI é uma excelente ferramenta para construir IA que consegue manter uma conversa real. Resolve o enorme desafio da gestão de contexto, dando aos programadores a base para criar assistentes que se conseguem lembrar de coisas a longo prazo.
Mas, no final de contas, é apenas uma base. É necessária muita engenharia para construir uma aplicação polida e pronta para produção em torno dela. Terá de construir o seu próprio sistema para gerir IDs de threads, uma interface de utilizador para monitorizar tudo e uma forma de evitar que os seus custos disparem.
Para equipas que querem lançar um agente de suporte de IA inteligente sem passar meses em desenvolvimento, uma plataforma totalmente gerida é o caminho a seguir. Com a eesel AI, pode ligar o seu help desk e bases de conhecimento em minutos, testar como o seu agente responderá a tickets passados e entrar em funcionamento com um agente de IA totalmente personalizável. Dá-lhe todo o poder da API de Assistentes, mas envolvido numa interface simples e de autoatendimento que é construída para equipas de suporte, não apenas para programadores.
Perguntas frequentes
A API de Threads da OpenAI é um componente chave da API de Assistentes, mais abrangente, projetada especificamente para gerir o histórico de conversas. Ao contrário das APIs sem estado (stateless), como a API de Chat Completions, ela permite sessões de chat persistentes e contínuas, onde o contexto é mantido automaticamente.
Ela armazena cada mensagem enviada e recebida dentro de uma "thread" ou sessão contínua. Isto significa que o assistente de IA tem automaticamente acesso ao histórico completo da conversa ao processar uma "Execução" (Run), eliminando a necessidade de os programadores passarem manualmente o contexto em cada chamada à API.
Um desafio significativo é a falta de uma API para listar threads; os programadores devem armazenar e gerir manualmente os "thread_id"s nas suas próprias bases de dados. Também não há uma UI integrada para monitorizar ou depurar conversas, o que exige sistemas de gestão construídos à medida.
A faturação é feita com base nos tokens do modelo (entrada e saída), no uso de ferramentas e no armazenamento de dados, e não diretamente pela própria API de Threads. À medida que as threads de conversa se tornam mais longas, os custos dos tokens de entrada aumentam, o que pode tornar os gastos gerais difíceis de prever e potencialmente imprevisíveis.
Sim, configurar e escalar um assistente pronto para produção com a API de Threads da OpenAI envolve um esforço de engenharia significativo. É necessário gerir Assistentes, Threads, Mensagens e Execuções (Runs), e implementar uma lógica complexa para verificar os estados das execuções e lidar com vários estados.
Como uma API de baixo nível, a API de Threads da OpenAI não fornece qualquer interface de utilizador ou painel de controlo integrado para gerir conversas. Os programadores precisam de construir ferramentas personalizadas para visualizar registos, monitorizar históricos de chat ou depurar interações do assistente.
