Um concierge que leu tudo o que alguma vez publicámos

Há uma pequena pílula no canto desta página que diz pergunte ao estúdio. Atrás dela está aquilo que todos os sites de consultoria prometem desde 2016 e quase nenhum entregou: uma caixa de chat que conhece de facto a empresa que representa. Pergunte-lhe o que inclui um projeto de plataforma web e ela recita os entregáveis reais. Pergunte-lhe o que pensamos de código gerado e ela cita o ensaio. Pergunte-lhe onde vive o Edward e ela recusa com educação, porque lhe ensinámos maneiras junto com os factos.

Podíamos ter colado um widget de terceiros por cima do rodapé e seguido em frente. Mas imprimimos conjuramos cada linha de código & pixel em nosso próprio nome, e uma bolha de chat alugada, a transmitir a marca de outra pessoa no nosso canto, teria argumentado contra cada página sobre a qual flutuasse. Por isso o concierge é nosso de ponta a ponta: uma Edge Function do Supabase, um modelo da OpenAI, um cliente do tamanho de um cartão de visita e uma camada de conhecimento com uma história que não esperávamos contar.

Identidade sem conta

A primeira decisão de desenho foi quem o visitante é. O histórico do chat deve sobreviver a um recarregamento da página — perder a conversa por ter ido ver a página de preços é coisa de amadores — mas ninguém quer criar uma conta para fazer uma pergunta, e não queríamos manter autenticação anónima para aquilo que é, estruturalmente, um livro de visitas com opiniões.

Por isso a identidade é um token: o widget cunha um id de conversa aleatório e um segredo no armazenamento do seu navegador, e o servidor guarda apenas um hash do segredo. Apresente o par e a conversa continua; perca-os e simplesmente começa de novo. As tabelas das conversas estão trancadas ao service role — não existe política de leitura pública nenhuma, portanto não há nada para configurar mal. É a mesma forma dos tokens de partilha que as nossas páginas de orçamento usam desde o primeiro dia, e é exatamente por isso que confiámos nela.

Sempre 200

As respostas fluem token a token por server-sent events, e o transporte tem uma regra herdada do gerador do /blueprint: a resposta é sempre um fluxo de eventos HTTP 200, mesmo quando traz más notícias. Limite de pedidos atingido? É um evento error. Token de conversa inválido? Um evento error. A alternativa — um 4xx seco depois de o preflight de CORS já ter passado — é uma falha que o navegador consegue ver mas que o seu JavaScript não consegue ler, o que é o pior dos dois mundos.

O fluxo também transporta mais do que texto. Quando o modelo termina, um evento done entrega o id da resposta guardada, que é o que faz funcionar os pequenos polegares por baixo da resposta. Quando um lead é capturado a meio da conversa, um evento lead avisa a página para que as nossas métricas o possam contar. O protocolo tem três verbos de largura e tencionamos mantê-lo assim.

O abuso é limitado por aritmética e não por otimismo: dez pedidos por minuto por endereço através do mesmo limitador durável que os formulários de contacto usam, dois mil caracteres por mensagem, uma janela de contexto de vinte mensagens, mil tokens de resposta. Um bot que queira gastar o nosso orçamento de inferência tem de fazer fila atrás do curl de toda a gente.

O ficheiro que escrevemos para os outros robôs

O problema interessante era o conhecimento. Um concierge que responde a partir do treino geral de um modelo é um passivo num fato bonito: vai inventar serviços que não vendemos e preços que nunca demos. Tudo o que ele diz sobre o estúdio tem de vir do estúdio.

Eis a parte que não planeámos. Há meses publicámos o /llms-full.txt — um resumo legível por máquinas do site inteiro, mantido automaticamente a partir do mesmo conteúdo que as páginas apresentam, para que os assistentes de IA dos outros nos descrevessem com precisão. Quando fomos à procura de um corpus de fundamentação para o nosso próprio concierge, ele já lá estava: atual, completo e testado pelos robôs de estranhos durante meio ano. A função vai buscá-lo, guarda-o em cache por pouco tempo e entrega-o ao modelo com cada pergunta. O ficheiro que escrevemos para os outros robôs acabou por ser o cérebro do nosso.

Por cima do resumo assentam mais duas camadas. Um cânone curto, escrito à mão, transporta as regras que nunca podem derivar: as palavras banidas da marca, a recusa de inventar números e um perfil do fundador com um limite explícito — tudo o que o concierge pode dizer sobre o Edward pessoalmente cabe em seis pontos, e está instruído a recusar o sétimo. Não porque o modelo fosse de outro modo dar à língua, mas porque os limites de um bot público devem ser uma decisão de desenho, escrita, e não uma propriedade emergente.

Ensinar-lhe o Journal

A terceira camada é este Journal. Vinte e um ensaios sobre como construímos as coisas são exatamente o material que as perguntas mais difíceis de um visitante pedem — como é que tornaram o Safari rápido, o que se partiu no museu, porquê publicar preços sequer — mas, com as suas cerca de sessenta mil palavras, não pode viajar em cada pedido.

Por isso os ensaios são cortados em passagens e transformados em vetores, e cada pergunta que chega é vetorizada da mesma forma e comparada com eles. As quatro passagens mais próximas, acima de um piso de semelhança, viajam com o prompt; o modelo está instruído a citar à vontade e a ligar a fonte. Pergunte como tornámos o Mobile Safari rápido e o concierge responde com os números reais de /articles/making-mobile-safari-fast — o TTFB de 250 a 950 milissegundos que passou a um dígito, os 91 kilobytes de JavaScript que saíram do bundle inicial — porque está a ler os mesmos parágrafos que também leria.

O índice reconstrói-se automaticamente a cada deploy. O que produz uma frase que gostamos de escrever: quando estiver a ler isto, o concierge já o leu também. Os artigos sobre a máquina passam a fazer parte da máquina — pergunte-lhe como funciona e ele cita-lhe esta mesma página.

Quando alguém nos quer contratar

Uma caixa de chat de estúdio tem um único trabalho comercial: perceber quando uma conversa deixa de ser curiosidade e passa a ser um projeto. O modelo transporta uma única ferramenta para isso — pode registar um lead com um nome, um email e um brief de uma linha, e está instruído a usá-la no máximo uma vez, apenas com dados que o visitante realmente escreveu, e a nunca perguntar duas vezes. O lead cai na mesma tabela que os do formulário de contacto, o estúdio recebe um toque e o visitante recebe uma frase de confirmação em vez de uma sequência de follow-ups.

Mecanicamente esta é a parte menos glamorosa da construção e a mais instrutiva: a meio do fluxo, o modelo pausa a sua própria resposta, chama a ferramenta, recebe o resultado e continua a falar — dois pedidos a montante cosidos sobre uma única ligação ao navegador, invisíveis a menos que se esteja a olhar para o fio. O visitante experimenta uma frase. Essa assimetria é a maior parte do que a engenharia é.

Números que podemos imprimir

Cada resposta escreve os seus próprios recibos de tokens na base de dados, portanto o custo mensal do concierge é uma query, não um palpite. Também conseguimos ver que respostas ganham o polegar para cima por baixo delas e quais não — as avaliações caem ao lado dos recibos. Uma funcionalidade que não se consegue medir é uma funcionalidade que não se consegue defender; esta sai com o seu próprio livro-razão.

Limites, ditos em voz alta

• O índice do Journal é, para já, só em inglês. A correspondência entre línguas funciona mais vezes do que devia, mas uma pergunta em russo encontra passagens em inglês; vetorizar os ensaios traduzidos é a correção honesta e está na lista.
• O modelo vê as últimas vinte mensagens de uma conversa. A abertura de uma conversa longa acaba por sair de vista; um resumo contínuo está desenhado mas não construído.
• O limite de pedidos é por endereço, portanto um escritório atrás de um router partilha a mesma mesada. Ainda ninguém lhe bateu; no dia em que alguém bater, a chave fica mais esperta.
• O concierge fala pelo estúdio mas continua a ser um modelo de linguagem. Está fundamentado, delimitado e medido — e se alguma vez disser algo que o site não diz, ganha o site.

Se uma caixa de chat pertence sequer a um site de estúdio é uma pergunta justa — escrevemos um ensaio inteiro sobre ferramentas que nos respeitam, e um mau concierge é o oposto disso. A nossa resposta foi exigir-lhe a mesma fasquia de tudo o resto por aqui: transmite em fluxo porque esperar é falta de educação, recusa porque os limites são conteúdo, cita porque leu as fontes, e sai de cena quando está numa página que tem a sua própria mobília. O museu mantém o seu próprio chat; o nosso fica fora do enquadramento.