Algumas perguntas não lhe pertencem
Depois de o usar, as perguntas que não pertencem são explicações, respostas para uma pessoa ler, inventar um nome num conjunto aberto, e guardar um rasto de raciocínio. O que pertence continua a ser um sim-não fechado, uma categoria, um nível, e se se deve escalar.
Coautor: folkbench.com (Folkbench é uma plataforma de avaliação e seleção que se pode rever, para APIs de IA, serviços de modelos e sites relacionados. Apoia-se em informação publicada sobre o serviço, preços, disponibilidade, latência e janelas de evidência para ajudar os utilizadores a comparar e a escolher um caminho.)
Dez textos nesta série:
- JEV - Uma articulação não precisa de um cérebro
- JEV - Porque é que um Jev que não conversa serve um Agent
- JEV - Até onde chega, afinal, «não pode alucinar»
- JEV - Sim-não, escolha e nível chegam para uma linguagem?
- JEV - Um laboratório conseguiria construir isto. Porque é que ainda pode não o fazer.
- JEV - As duas demos que eu fiz
- JEV - As pessoas recuam do meio do ciclo para a margem
- JEV - Passada essa linha, eu já não distingo quem é mais inteligente
- JEV - Algumas perguntas não lhe pertencem
- JEV - Um modelo reduzido ao essencial, uma suite e um que não fala
Depois de o usar, aquilo de que eu estou mais certo não é o que o Jev sabe fazer. É que géneros de fala eu não lhe devia pedir.
Eu tomo-o como articulação, não como boca. O instinto só consegue responder a perguntas que o instinto consegue responder. O que tem de ser desdobrado, ou o que tem de pôr o raciocínio à vista para uma pessoa ver, é o objeto errado se você pergunta ao Jev. Dizer algo até ao fim a uma pessoa também é o pedido errado. Não tem strings. Pergunte, e não há onde pôr a resposta.
O que eu não devia perguntar
Se você também vem de um modelo de chat, as coisas mais fáceis de perguntar mal são os géneros abaixo.
Eu não lhe devia pedir que explicasse porquê. O hábito que eu trouxe do chat é abrir a pedir que explique. Esse hábito não funciona nele. Quando eu lhe peço que explique, o que chega é só um juízo. Uma razão tem de ser escrita em frases. Não as consegue escrever. O que é devolvido não tem um «porque». Se alguém precisa de ver como a causa chegou, não o consegue dar. Se eu preciso mesmo de um trecho de razões, eu escrevo-o eu próprio, ou eu peço a um modelo que sabe falar, e mando-o escrever a partir do juízo já feito.
Eu já lhe pedi, mal, que escrevesse uma resposta para uma pessoa ler. O que tem de ser enviado é uma passagem. Que frase vem primeiro, e quão pesado é o tom, vive nas palavras. O que ele dá são opções e probabilidades. Isso não bate com a passagem que tem de ser enviada. Por mais alta que seja a probabilidade, o que é devolvido é um dos itens que eu dei de antemão, não uma passagem que ele escreva agora. Eu mais tarde inverti a ordem. Ele só julga a que género esta coisa pertence, e se este passo deve escalar. As frases vão para um modelo de chat, ou eu escrevo-as eu próprio.
Eu já lhe pedi que inventasse um nome por si dentro de um conjunto aberto. Os nomes utilizáveis são muitos, e só uma fatia pequena está escrita na pergunta. Só consegue escolher entre os itens que eu dei. O que não está entre os itens, não consegue produzir. Se eu próprio não consigo nomear os candidatos, ainda não é a vez dele. Eu estreito primeiro com regras, ou eu tiro um pequeno punhado com recuperação, e depois eu fecho a pergunta. Mais tarde eu mudei o dar nomes para isto: eu próprio fixo uns poucos candidatos, e depois deixo-o escolher. Um completamente novo, fora da lista, eu deixo ao passo que sabe falar.
Há outro género que parece trabalho pesado que se devia dar a um modelo. A prova tem de ser virada para trás e para a frente, e o raciocínio tem de ser guardado. Os materiais empurram-se uns aos outros. Você quer que escolha um lado, e também quer que guarde como a correspondência foi feita. Não tem essa ida e volta. Um pedido é um juízo rápido a partir do que eu meto no state. O processo não se torna texto que se possa folhear. A ida e volta de que eu falo é muitas vezes uma conclusão que depende da página seguinte, e essa página ainda não está no state. Eu ponho essa dependência no código. Pergunte primeiro um juízo fechado, depois eu vou buscar a prova, e quando volta eu mudo o state e pergunto outra vez. A sequência de que página foi vista primeiro, e o que foi excluído, não a consegue escrever. Se um rasto tem de ser guardado, eu dou-o a um modelo que sabe falar.
O que eu devia perguntar
O que eu devia perguntar, eu agora só reconheço umas poucas formas. Se é deste género, eu pergunto diretamente. As categorias têm de ser as que eu fixei de antemão, e ele só tem de apontar uma. Gravidade, eu não deixo que reporte um número fino. Eu desenho os níveis, e deixo-o dizer em que nível cai. Escalar, se este passo deve ser entregue a uma pessoa, também é uma pergunta fechada, e eu pergunto-a na mesma passagem. Uma forma fora destas, eu não a enfio nele.
Eu também guardo uma régua grosseira. Se uma pessoa que percebe o assunto consegue apontar, por instinto, a olhar para este state, então parece a pergunta dele. Se apontar ainda exige uma dedução longa, eu entrego-a direta a um modelo que sabe falar.
Eu preparo o state. Eu fecho a pergunta. Eu escolho os campos que entram no contexto, e eu não trago o que é irrelevante para esta pergunta. Os limites das opções e dos níveis estão escritos na pergunta, não num sítio em que eu espere que ele improvise. Não é responsável por arredondar uma pergunta aberta, e não vira por mim a página seguinte do material. Vire uma página, e o state mudou. Esse é o pedido seguinte, e eu ainda o tenho de preparar.
Eu já pisei uma pergunta que não estava bem fechada. A distribuição achata-se. Várias opções apertam-se umas contra as outras, e nenhuma fica uma cabeça acima. Eu tomei isso primeiro como ele estar lento. Não era. Eu tinha dado a uma articulação o pistão de uma boca. As opções sobrepõem-se, ou uma situação que de facto vai ocorrer não foi escrita na lista, e a probabilidade só se pode espalhar. Então mude a pergunta, ou devolva o passo a um modelo que sabe falar. Mudar a pergunta quer dizer fundir os itens que se sobrepõem, e dar ao caso não coberto um «nenhum destes». Devolvê-lo quer dizer deixar o modelo que sabe falar dizer primeiro a situação com clareza, e depois eu decido se a fecho outra vez. Não continue a afiná-lo. Enquanto a pergunta continua aberta, a distribuição continua espalhada.
Choice e Score
Eu tento não encher o Choice até 255. O teto oficial é 255. Para lá disso, eles próprios têm de pontuar primeiro e só depois escolher, e também fica mais lento. 255 não é um número que eu esteja aqui para encher. Quanto mais casos de margem eu listo como opções, mais a pergunta parece uma lista que nunca foi fechada. Se a minha pergunta tem naturalmente centenas de saídas, eu pergunto primeiro se as regras conseguem cortar os candidatos, e se a recuperação os consegue cortar. Um pequeno punhado não tem uma contagem fixa. Eu ainda consigo dizer, numa olhadela, em que estes itens diferem, e só então o corte foi longe o bastante. Se uma olhadela não os distingue, eu estou a enviar o pedido cedo demais. Corte-o até um pequeno punhado, e depois eu levo-o a escolher.
Eu trato o Score como níveis ordenados, não como um decimal contínuo e exato. Quando eu escrevo a pergunta, eu normalmente desenho os níveis de 2 a 10. O que eu quero é um nível, não uma falsa precisão como 7.63. Eu escrevo os níveis em palavras simples. Se este nível e o seguinte seriam tratados de maneira diferente, eu penso primeiro. Se seriam, eu separo-os. Se os dois níveis acabam por disparar o mesmo código, eu fundo-os num só nível. Nenhum ramo no código está à espera de dois algarismos depois da vírgula. Às vezes cai um número entre dois níveis, e eu mesmo assim leio-o como um nível, com o limiar escrito no código. Se o sentido de um nível não se pode escrever com clareza, eu mudo a descrição do nível. Eu não ando a beliscar o decimal.
Enquanto eu via as demos
Eu vi a demo oficial do Doom e a corrida da Wikipédia, e eu não as usei para concluir as minhas próprias perguntas. A ver o Doom, eu deixo-me levar com facilidade pelo ecrã. O ecrã parece um jogo a ser jogado. O que entra é state estruturado, não a imagem. Do lado do Doom a escala é cerca de 10 consultas por segundo, cerca de $7 por hora. Essa escala só mostra que uma articulação em tempo real se aguenta, e que um ciclo consegue rodar a essa densidade. Não mostra que saiba jogar o jogo. A imagem não foi comida. O passo seguinte é código de fora, a perguntar com o state.
A corrida da Wikipédia mostra que escolher ligações com cardinalidade alta é útil. Não mostra que navegue na web melhor do que um modelo que sabe raciocinar. Na comparação sem raciocínio, dá menos passos. Isso é porque o outro lado não ligou o raciocínio, e por isso a demonstração fica melhor. Ligue o raciocínio, e a demonstração fica menos boa. A contagem de passos muda, e quem é mais rápido muda. Eu não vou trazer «menos passos» de volta para a minha própria tarefa e tratá-lo como melhor a encontrar um caminho. Se o caminho continua, e onde para, continua a ser decidido pelo programa de fora. Eu tomo isto como: não julgue tudo a partir de um brinquedo. Se uma demonstração é agradável de ver não decide, para mim, que frase eu devo perguntar a seguir.
Quando eu próprio o uso, a divisão é bastante dura. O que se pode esgotar, e cujas condições são estáveis, eu ainda escrevo como regras. Eu não vou perguntar-lho. O que o instinto consegue responder num só apontar, é aí que eu lhe pergunto. Antes de eu perguntar, a pergunta tem de estar fechada, e eu tenho de ser capaz de preparar o state. Quando é altura de abrir e dizer o conteúdo, eu dou-o a um modelo de chat. Pergunte a coisa errada, e a lentidão e o custo são problema meu.
Fontes
- https://typesafe.ai/blog/introducing-system-one-models-and-jev
- https://evals.typesafe.ai/
- https://docs.typesafe.ai/primitives