Latest / Entre Chaves / #286 TOON ou JSON: qual realmente economiza no seu caso?

Transcript

#286 TOON ou JSON: qual realmente economiza no seu caso? · Entre Chaves

0:00
E está começando mais um entre chaves, o seu podcast de
0:03
desenvolvimento de software. Eu sou o Luiz Fernando e já
0:06
começo com uma pergunta pra você que nos ouve, você é time toon
0:10
ou time Jason? Se você não faz ideia do que eu
0:13
estou falando, cola aqui com a gente.
0:15
Não estamos falando de desenhos animados, estamos falando de um
0:19
de uma nova ferramenta que tem sido amplamente utilizado.
0:23
Mais umas ferramentas visando a otimização de tokens de IAE.
0:29
Pra gente começar essa conversa, tem aqui a nossa famosa e eterna
0:33
host, Fernanda. Isso aí.
0:36
Bora lá. Tô curiosa com esse com esse
0:40
assunto de hoje. Vamos embora?
0:41
E hoje nós temos aqui nossos 2 convidados, Jordan.
0:45
Pessoal. E temos amigo Gustavo aqui com a
0:47
gente, e aí? Gente, tudo bem?
0:49
Então pessoal, a gente tem esse esse termo toon né, que é
0:52
utilizado pra desenhos animados, né?
0:54
Inglês, que na verdade é um acrônimo.
0:56
Né? EE, aí eu vou deixar vocês mesmo
0:58
apresentarem o acrônimo, né? E já dando o spoiler, ele já
1:02
começa a primeira letra, né? Que já mencionando pra que ele
1:05
veio, com qual objetivo essa ferramenta foi criada?
1:08
E vou deixar vocês já dar muita introduzida no assunto, porque
1:11
tem muito ouvinte que nunca deve ter ouvido falar e deve ter
1:14
ouvinte que já tem um lado escolhido, tum ou Jason.
1:18
Que também vale a pena ficar aqui com a gente, porque quem
1:21
sabe nós, a gente promete que nós vamos apresentar aqui a
1:23
verdade nua e crua sobre os 2, o as vantagens e vantagens, onde
1:28
usar cada um. Quem sabe a pessoa que às vezes
1:30
até até acaba mudando de opinião, né?
1:32
Depois desse episódio? Então vamos lá, pessoal, passo a
1:34
bola pra vocês. Então é o tum.
1:36
Ele basicamente é o token oriented objetor tation.
1:39
É uma serialização do mesmo modelo de dados do Jason e ele é
1:43
feito para entrar em prompt, né? Ele é feito com o intuito de
1:46
gastar menos tokens e fazer com que o trabalho da IA custe menos
1:51
tanto tempo quanto dinheiro para uma empresa ou para quem está
1:54
usando. Mas como é que ele promete?
1:56
O que que é, onde que ele atua exatamente?
1:59
Que ele promete essa economia de tokens?
2:00
O tum, ele basicamente faz uma reformatação ali de um Jason
2:05
identitado, então ele ele tem uma identitação parecida com o
2:09
estilo yen para os objetos alinhados.
2:12
Ele tem um layout tabular, então ele diminui em muitas linhas.
2:16
A quantidade é de dados assim que é necessário para que a
2:20
gente represente a os dados que o Jason traz, um ponto
2:24
interessante que ele traz. É que ele consegue trazer todos
2:28
os dados. Ele não exclui nada, é.
2:30
Ele traz exatamente todos os dados que tem no Jason
2:32
inventado, mas de uma forma muito mais comprimida pra fazer
2:35
com que a inteligência artificial ela consiga entender
2:38
aquilo de forma mais rápida e menos custosa.
2:41
E também ela tem 11 certo alto nível, então faz com que o
2:44
desenvolvedor que olhe e também consegue entender o que está
2:46
acontecendo ali. Legal.
2:47
Uma coisa que eu quando estava lendo sobre tum, eu achei bem
2:49
curioso, foi o jeito que ele nasceu, né?
2:52
Que ele nasceu? A partir de um deve autodidata
2:56
que ele precisava entregar uns feeds RSS, né?
3:00
Para editores que não eram técnicos num podcast.
3:03
Curiosamente, para um podcast nessa implementação, o CSV não
3:08
era suficiente, porque apesar de ser muito bom, muito bom para
3:12
dados tabulares, ele não é muito bom para dados que não são
3:16
tabulares. E o Jason também não era bom
3:19
justamente porque ele acabava. É consumindo mais, né?
3:24
Mais tokens do que ele precisava, né?
3:28
E acabava ficando caro. E aí ele criou esse formato, que
3:32
é a partir, né, como se como o Gustavo falou, né, que é criado
3:35
a partir do Jason, mas que tem uma característica tabular
3:38
assim, né? Inclusive nos benchmarks, esse
3:41
esse formato, ele funciona muito bem pra os dados são
3:45
principalmente tabulares, né? E aí ele criou esse, esse, esse.
3:50
Esse formato em cima do Jason, mas pra tirar algumas coisas,
3:54
né, que o Jason traz, como as chaves, né?
3:57
Algumas formatações que o Jason traz, né?
4:01
Ele acabou tirando pra economia de token mesmo.
4:04
Achei bem interessante assim que foi um negócio meio meio,
4:08
parecia um pouco despretensioso a origem que foi pra resolver um
4:11
problema real, mas que também explodiu mesmo.
4:15
Como para variar, né? Em um tuíte como a gente sempre
4:19
ama aqui nos mundos da ya, mas esse cara que chama Johan aí, eu
4:24
não vou. Me não vou?
4:25
Não vou, Johan, não. Vou, gente.
4:30
É esse cara? Ele fez um tweet em em 2025, no
4:35
final de 2025, falando que o Jason ele é.
4:38
Ele é caro, né? para as LLMSE que o tum.
4:43
Ele justamente prometia aí de 40 a 60% menos tokens do que o
4:47
Jason. E ele tinha essa característica
4:50
de ser ridable, né? E tokenizer.
4:52
Awhere, né? Então, bem interessante.
4:55
E olha que interessante, né? A gente lá nos primor.
4:58
Na época dos maias a gente usava XML para comunicação de serviços
5:03
e o Jason já foi uma evolução. Que já pra já pra economizar e
5:09
só que assim já foi algo menos verboso, menos houverhead, muito
5:15
superior ao ao ao XML. Mas o Jason também foi feito pra
5:21
ter uma legibilidade humana, né? Serviços humanos numa era onde o
5:28
leitor seja nesta fazer uma comunicação entre serviços ou
5:32
back end. É quem tá enviando os dados, que
5:35
tá recebendo os dados. Não cobra por palavra, por
5:38
token, por nada disso, porque assim você manda blocão de dado,
5:41
quebra aqueles objetos, processa e devolve a resposta, né?
5:44
E agora a gente entra esse outro interlocutor na jogada, QIA que
5:49
tokeniza tudo e cobra por token, né?
5:52
Então de repente algo que veio, que já veio pra uma pra
5:56
melhorar, pra resolver a questão do XML, passa a já não mais
6:00
resolver esse novo paradigma que a gente tá vivendo.
6:03
Né? Que já já é interessante de a
6:05
gente já pegar. Como é que é uma coisa que que
6:07
que foi tão assim? Nossa, que maravilha.
6:09
Agora vou usar isso para o resto da vida e veio aí.
6:12
Aí quebra isso tudo, né? Eu acho que o Jason ele quando o
6:16
crock for, desenhou, né? Lá em 2001.
6:18
A intenção era que ele fosse auto descritivo, é, fosse sem
6:21
ambiguidade, fosse funcionar para qualquer linguagem ali, sem
6:25
necessariamente precisar de um esquema externo.
6:28
O que acontece agora não é que, sei lá, o Jason ficou pior, mas
6:30
sem que o consumidor dele mudou. E aí esse formato mudou.
6:34
A forma que a gente consome mudou.
6:36
Então, como agora o principal consumidor é seriam os modelos
6:39
de inteligência artificial. A intenção é que um novo modelo
6:42
apareça para facilitar para que esse consumidor consiga entender
6:46
melhor. Uma coisa que eu vi, né é e que
6:48
foi até voltando lá nos tweets do do Johann, né?
6:54
Que que é o criador? Depois que ele anunciou o tum
6:57
pra comunidade, ele começou a falar sobre.
7:00
Sobre a acurácia, né? Porque uma das coisas é a
7:03
beleza, eu vou reduzir seus tokens aí de entrada, mas também
7:07
vou te dar uma resposta pior, aí não adianta nada, né?
7:10
Porque aí no nas interações, no final das contas, se a resposta
7:13
é pior, talvez eu vou consumir mais tokens no meu End To End,
7:17
vamos falar assim, só que aí, né?
7:19
O benchmark aí da do tum é justamente quando você lê até a
7:24
página, a página oficial lá do tum, ele fala aí que eles.
7:28
Encontram, né? 72.2% de acurácia versus 71% do
7:33
Jason consumindo 42% 42.6% menos tokens.
7:40
Então de fato ele coloca, né? No tweet dele, o que ele fala é,
7:43
mas será que a gente a gente está reduzindo token,
7:46
comprometendo a acurácia? EE, ele responde que não, né.
7:49
Então assim, como que que vocês veem isso em relação à acurácia,
7:53
a qualidade? É quando a gente tá usando esse
7:56
formato diferente, então? Vale lembrar que durante o
8:00
treinamento, né, que ocorreu das LLN lá atrás, até hoje, a grande
8:05
parte dos documentos que a gente tem disponível pra LLM poder
8:09
aprender foi foram né, baseados em formatação Jason, né?
8:12
As que tinham um tipo de formatação aí que a gente usa na
8:16
programação. Então a grande maioria dos dados
8:20
são dados estruturados em Jason. O que tum, né?
8:24
É um componente novo que a gente tá adicionando e que
8:28
recorrentemente a gente tem que explicar no prompt ali.
8:33
Então vai gastar um pouco de tokens também pra explicar a
8:36
formatação. Como lidar com esse novo formato
8:39
que vai chegar, né? Além disso, outro ponto
8:42
importante pra gente trazer é que o tum, por ele ser um
8:46
formato novo. E aderência dele está sendo, aos
8:50
poucos, muitos dos serviços que já existem e que hoje são
8:54
ferramentas de a que a gente pode disponibilizar, como atum.
8:58
Elas disponibilizam respostas no tradicional Jason, então fazer
9:03
todo OA refaturação em cima pra colocar o tum é tem que ser
9:10
muito bem avaliado pelo esforço versus a qualidade.
9:15
De redução de tokes que a gente vai ter?
9:18
Pergunta é pra gente discutir exatamente isso aí que você
9:20
falou é porque hoje nós temos outras ferramentas que são
9:24
usadas justamente na otimização de tokes, né?
9:27
Tem ORTK, tem o cavemman, tem o Red room, cada um tem uma parte
9:31
ali do que ele vai conseguindo otimizar.
9:34
Se a gente encaixa o tum num ponto desse do modelo, a gente
9:39
consegue isso de uma maneira fácil.
9:41
Isso é uma maneira fácil de se trabalhar.
9:44
É, já tem disponível aí SDK para as diversas linguagens, onde,
9:49
por exemplo, é, eu já tenho algo que vai é é reduzir a leitura do
9:55
da janela de contexto e de volta, né?
9:57
Pro pro meu modelo, eu já tenho o cavemer, por exemplo, que ele
10:01
obriga o modelo a me dar as respostas mais simplificadas
10:04
possíveis. Aí eu quando por exemplo, eu
10:06
tenho Oo headroom, por exemplo, né?
10:08
Que ele ele também vai compactar AA mensagem que a gente vai
10:11
enviar pro modelo. Nesse meio do caminho, antes do
10:15
Red room compactava, por exemplo, eu já tenho de maneira
10:18
fácil algo que eu consigo utilizar, que eu pego um Jason
10:22
no meio do caminho, já converto aquilo pro formato e envio
10:26
junto, e aí já atravesso pelo Red room e já compacto e manda.
10:29
Sim, hoje a gente consegue fazer, né?
10:32
Meio que um pipeline ali de redução de tokens é, a gente
10:37
consegue usar o cagman junto com o hedrow.
10:40
ORTK até ORTKO próprio RTK é usado dentro do hedroum, é.
10:45
Então a gente consegue antes de utilizar alguma outra ferramenta
10:50
para também promover essa redução de tokens.
10:53
Só que existem alguns pontos, a lei que a gente pode entrar mais
10:57
a fundo aqui primeiro, né? Se a gente for olhar a redução
11:03
real dessas ferramentas, vão ter muitos que vão dizer que.
11:08
É todas as páginas, né? Que divulgam essas ferramentas,
11:12
os regimes dos mid hubs dessas ferramentas, elas colocam
11:16
números um pouco inflados ali sobre o resultado, porque eles
11:20
pegam um determinado cenário em que a ferramenta é bom, roda
11:24
essa ferramenta, faz a redução do token e divulga o resultado.
11:28
Mas não necessariamente a gente vai ter esse nível de redução
11:32
divulgado para qualquer cenário. Pegando o tum, por exemplo, a
11:36
redução que ele faz comparando com o Jason, que a gente chama
11:41
aquele Jason pearty, né? Que é o Jason que o ser humano
11:44
consegue ver bonitinho ali, com seus espaçamentos quebras de
11:49
linhas, ele acaba sendo bem útil.
11:52
Só que se a gente comparar com o Jason minificado.
11:56
Que a gente recorta do, do, do Jason, né?
11:59
Toda essa parte de espaçamento, de quebras de Lins, a gente já
12:02
não tem uma redução significativa.
12:04
E em muitos casos, o Jason unificado ganha do tum em
12:08
questão de redução. O tum.
12:10
Ele vai ser muito bom, por exemplo, em cenários volumosos
12:14
que a gente tem OA rei de objetos e esses objetos são
12:18
uniformes, ou seja, eles têm as mesmas propriedades dentro de
12:22
cada um, né? Se eu tiver essas propriedades
12:25
alguma modificada, eu já dentro do a gente já tem que se
12:28
especificar cada um desses objetos, então a gente perde um
12:31
pouco dessa eficácia dele. Mais uma dúvida até nessa
12:35
pergunta, né, que o Luiz trouxe na sua resposta, joda, é esses
12:39
framors tipo ORTKO, redrom, né e et cetera.
12:43
Eles são muito framors de harner, né, que é assim, eu
12:46
estou programando, eu quero reduzir meu consumo de tokens
12:49
via LM pra produzir o meu software.
12:52
Eu uso esse tipo de frêmio o tum, eu entendi que ele era um
12:55
pouco mais voltado pra utilização em agentes, né?
12:59
Então assim, respostas em agentes de a né, que aí sei lá,
13:04
eu posso usar o tum como resposta da minha API que vai
13:07
ser consumida via MCP ou alguma coisa, ou utilizar o tum pra
13:12
melhorar o meu, o meu rag, né? Os meus dados retornados pra um
13:16
rag, alguma coisa mais voltada aos agentes de a no negócio.
13:22
Sabe menos a ver com harners. Eu entendo que talvez possa ter
13:25
a né interseção entre eles, mas queria ouvir de vocês assim como
13:30
que é é isso mesmo que eu acabei de explicar ou existe existe
13:34
esses essa diferenciação muito clara assim entre quando eu uso
13:38
esses trêmwork de compactação, de contexto, né, de de economia
13:42
de tokens e quando eu uso o tum. É, na minha visão, o tum seria o
13:47
mais indicado pra. Fluxos de negócios mesmo porque
13:51
quando a gente está falando do arms, a gente tem várias
13:54
ferramentas ali que compõe, né, o nosso partes e pode ser que
13:59
muitas dessas ferramentas. É, não consigam lidar com a
14:03
formatação do tum diretamente. Às vezes eu tenho que a partir
14:07
de uma resposta gerada, chamar uma próxima é ferramenta, então
14:13
eu teria que essa ferramenta só aceita.
14:15
Por exemplo, o Jason, eu teria que fazer essa conversão de
14:18
volta e isso está no escopo da lln.
14:21
Então possivelmente ela vai gastar tokens de fliking, né?
14:25
Que no caso são outputs pra gerar essa conversão, o que vai
14:29
encarecer muito mais. Ali o meu custo final, então eu
14:33
diria que seria o mais para onde a gente tem um fluxo realmente
14:37
controlado, que seria o um agente que a gente desenvolveu,
14:41
por exemplo, né? E nós controlamos totalmente as
14:45
regras ali, que vão ser aplicadas no agente.
14:47
Mas, Jordan, quando você falou sobre o pipeline em que você
14:50
poderia usar o RT KO queima e o tum No No final das contas, você
14:55
também estava falando de agente de a ou você estava falando de
14:58
harners? Então é na interação com o
15:01
modelo de LLM, né? A gente pode ter um harners
15:05
completo ou a gente pode ter essas ferramentas iniciais ali,
15:10
né? De redução de token, que são que
15:13
são voltadas pra esse é tema, né, que são aplicadas como um
15:18
proxy entre, por exemplo, o caso do hedrow, né?
15:22
É um proxy entre o meu terminal com o que tá indo pro copo de
15:26
fato, né? Então é não necessariamente elas
15:32
vão diretamente interagir com o que eu tenho de harner.
15:35
Isso vai ser delegado ali pelo modelo.
15:38
Né? Então assim eu consigo fazer a
15:40
compressão. Mas como o tum, por exemplo, é
15:43
um é uma formatação de uma resposta que que veio, por
15:49
exemplo, de um Jason, né? Ou ou que seria um Jason, é,
15:52
pode ser que a gente tenha um consumo depois de converter isso
15:57
de volta pra poder jogar pra uma outra ferrada ali que não tem
16:01
suporte, atum, por exemplo, né? O que não aconteceria se fosse
16:04
um Jason unificado? Então por isso que você tá
16:06
falando, né? Que ele?
16:08
O mais indicado, na verdade o melhor caso de uso talvez é no
16:11
agente e a, porque você tem o controle do fluxo todo que você
16:14
manda de fato no pra. LLM é aquilo e pronto, né?
16:18
É claro que ela tem as suas otimizações por dentro, mas como
16:20
você falou, ela é steakles ela. Enfim, né?
16:23
Tem muita coisa que você tá é criando por fora mesmo, né?
16:27
Agora, quando você tem realmente dentro a zele, principalmente, a
16:29
gente pega. Pegar os LLMS, os os modelos
16:32
maiores, né? Então nós estamos falando aqui
16:34
de de de cloud, de GPT, de minae assim, né?
16:38
Vão pegar os os os maiores players de mercado.
16:41
Estou assumindo que todos eles trabalham muito bem com o tum,
16:44
obviamente, né? Senão o tum nunca nem teria
16:46
decolado. Só que então, né, você está
16:49
falando é basicamente quando eu tenho um workflow completo, né,
16:54
que eu tenho uma entrada, uma entrada.
16:56
Tem vai pra um agente e um agente, muitas vezes com
16:59
múltiplas esquilos, que vai processar o coisa, vai gerar uma
17:02
saída que vai ser um input de outro agente EEE.
17:06
Eles vão vai passando por esses fluxos e no meio do caminho,
17:09
acessa, OMCP, acessa outras Fontes de dados, processa,
17:13
analisa, passa pro outro agente, até que chega uma resposta final
17:16
pra esse tipo de fluxo padrão, onde você tem diversos agentes
17:20
com as suas skills acessando as Fontes ali, MCP, et cetera, ali
17:24
nesse tipo de. De fluxo, o tum é mais indicado,
17:28
então eu diria que o. Tum de forma geral, tá?
17:32
Eu vejo ele indicado uns cenários muito específicos,
17:35
mesmo quando a gente tem dados informes e volumosos que
17:39
justificaria o uso dele, porque se for falar somente compressão
17:43
de dados e em cenários gerais, a gente trabalhando com Jason
17:48
midificado, ele já vai ter essa redução e algumas vezes até mais
17:53
significante do que o próprio tum, tá.
17:55
Tem um blog é de o do Chase evers, que ele fez um
18:02
comparativo ali entre os diversos modelos que a gente tem
18:06
hoje de formatação de dados, né? Tem CSB, tom e emmo, Jason
18:10
unificado, tem o tson, que é um outro formato que inclusive ele
18:15
compre mais do que o tom. Então é nessa plataforma ali a
18:20
gente consegue ver uma comparação de vários tipos.
18:23
De objetos, né? Que são simples objetos grandes,
18:28
objetos que são formes a uniformes.
18:30
E a gente consegue ver os resultados ali de cada
18:33
formatação relacionado ao custo de topo.
18:38
E na tabelinha aqui comparando, a gente vê que o tum ganha, por
18:42
exemplo, do Jason midficar em apenas 3 cenários dos quase 20
18:47
que tem aqui. Então é pra alguns cenários
18:50
específicos mesmo. Que eu recomendaria utilizar o
18:54
tuner de fato? Se não eu iria pra uma.
18:57
Se for só pra comprimir o dado eu iria pro Jason unificado, que
19:00
é mais fácil da gente fazer a unificação.
19:04
Ele continua não quebrando a integração com outras
19:06
ferramentas de AE. Ele causa reduções até mais
19:11
cientificadas que o próprio. Tun e acho que não só isso, mas
19:14
também a comparação entre o tun e o Jason unificado, ele traz
19:18
resultados quando ele ganha que não são.
19:21
É consideráveis suficientes pra que haja essa troca.
19:25
É é custoso de mais ter essa troca a ponto dessa diferença de
19:29
resultado. Então é sempre de um ponto
19:31
percentual, 2 pontos percentuais.
19:32
Isso talvez não valha tanto a pena.
19:34
Além disso, na comparação que acontece entre os modelos, que
19:38
inclusive no geminai 3, ele ele ganha, o Jason, ganha dele
19:41
também. Trocar de modelo se mostra como
19:44
uma alavanca muito maior do que trocar de formato.
19:47
Então se por exemplo AA curasse, ela está em 58%, né?
19:51
Daquele Jason, o problema não é serialização.
19:54
Então trocar pro tum, por exemplo, não serviria como algo
19:57
a ser consertado, eSIM, nesse caso, talvez trocar de modelo é
20:01
fosse o mais adequado. Então realmente o tum ele se
20:03
encaixa em em situações muito específicas e até em algumas que
20:07
ele encaixa talvez tenham uma abordagem melhor do que trocar
20:10
Pra Ele. Eu vi no próprio site do tum, é
20:14
o benchmark que eles fazem lá. Mostra um pouco isso que você
20:18
falou Jordan do do da comparação entre ele e o Jason unificado,
20:22
né? Ele perde em vários cenários.
20:25
Mesmo assim, o que ele começa a ganhar é como eu falei no
20:29
início, são situações em que o dado ele é mais tabular.
20:33
Ele é, percentualmente falando, mais próximo de um dado tabular.
20:38
Só que aí, se o dado é totalmente tabular, ele pede
20:41
para o CSV. Que aí ganha 100% em todos os
20:45
casos quando Oo dado é totalmente flat, né?
20:49
Que eles chamam aí que são dados totalmente né tabulares que você
20:52
consegue resolver com svs ou seja, né?
20:55
Assim me parece pela nossa conversa aqui né, que o tum tem
21:00
casos muito específicos, né? Que talvez não valha a troca do
21:06
Jason para eles. E se tratando de.
21:10
Otimização de custo tem várias e várias outras estratégias que
21:16
ganham do tum em relação à economia mesmo, né?
21:19
Então está me parecendo, não, não é um cenário muito favorável
21:25
para o tum aqui hoje? É eu.
21:26
Eu consigo imaginar o cenário realmente para o tum é assim,
21:29
igual você. Você está falando se eu tenho um
21:31
objeto muito grande e complexo e que não tem nada de repetitivo
21:36
nele. O tum não vai fazer
21:37
absolutamente nada, ele vai ser basicamente um Jason igual.
21:41
Se você tem uma grande tabela, o CSV vai ser mais indicado.
21:44
Agora quando você mistura os 2, né?
21:46
Vou dando um exemplo aqui, eu tenho uma lista de
21:48
concessionárias e dentro de casa da concessionária eu tenho uma
21:51
lista dos carros que dentro daquela concessionária, então é,
21:55
eu coloco uma concessionária e para que a concessionária lista
21:58
de carros, aí eu tenho lá marca do carro, nome do carro, anda do
22:02
carro, cor do carro e tal, e aí para cada carro tem isso aí.
22:06
Esse tipo de cenário é um que eu imagino que o tum.
22:09
É aí que ele vai ganhar, porque aí você realmente não vai ter a
22:13
questão de ficar repetindo os nomes das propriedades pra cada
22:15
um dos carros. Você vai colocar ali em cima
22:19
realmente a parte que é única daquela daquela concessionária.
22:22
Depois a lista de carros vai ser diminuída tremendamente.
22:24
Esse tipo de cenário, onde você tem objetos e lista de objetos
22:28
encadeados, principalmente, eu acho que é o cenário que o tum
22:31
vai brilhar. Agora, quando você tem objetos
22:35
que não são meramente listas, não são meramente não tem nada
22:39
de repetitivo, ou se você tem puramente dados repetitivos no
22:44
formato de uma tabela, não vejo utilidade do do sim, o tum.
22:48
Se for uma tabela simples, também uma tabela única, o tum
22:50
também vai conseguir uma redução boa, mas não tão boa quanto CSV.
22:53
Então nesse caso vai CSV. Mas é é essa mistura aí dos 2
22:58
mundos. Aqui eu acho que é onde o tum se
23:00
aplica melhor, fora isso. Eu realmente não consigo
23:03
imaginar o tum tendo uma performance melhor do que os
23:06
outros que já são feitos. Para isso exatamente, né?
23:08
E sem contar com esse formato de ação amplamente, né?
23:10
Adotados e como vocês falaram no início, as viagens já foram
23:13
treinadas com com esses dados, né?
23:15
Então elas tendem a performar melhor com esses dados também.
23:19
E olhando para 11 benchmark aí eu acho que esse foi da
23:22
comunidade, não foi não foi oficial do tum, é olhando para
23:25
modelos menores, eles tendem a performar pior, com o tum, a
23:29
curaça deles cai. Quando se utiliza tuning em
23:33
relação ao Jason, então é outra coisa aí também contando
23:38
negativamente pro tom, né? E eu acho uma discussão
23:41
interessante a gente trazer é que assim, por trás disso tudo,
23:45
é a necessidade Extrema de de economia de tokens, né?
23:49
Que é um cenário muito engraçado, você parar pra pensar
23:52
que os tokens têm caído de preço tremendamente e até pouco tempo
23:56
atrás você via empresas assim. Fazendo lay off.
24:00
E um dos. Critérios de lay off é quem
24:02
estava consumindo pouco token, né?
24:04
Tipo assim, é o foi chamado de token maxing.
24:07
Vamos fazer um lay off, eu vou mandar 500 pessoas embora, pega
24:10
as 500 pessoas que menos usaram token e vão mandar embora porque
24:12
elas não estão usando. E é do jeito que a gente.
24:14
Quer e de repente? Agora virou essa loucura da
24:16
corrida da economia do token, né?
24:19
As empresas antes faziam, né? Ranking de quem usava mais
24:22
token, né? Mais token e agora a gente
24:26
encadeando uma pipeline dessa. E discutindo ferramenta atrás de
24:30
ferramenta na ali, No No, na economia esse ano eu consigo 10%
24:35
dessa aqui, +5% dessa aqui, +10% dessa aqui, né?
24:38
E aí assim, até onde é que vale a pena e até onde a gente está
24:41
introduzindo mais complexidade e mais chance de erro, até onde é
24:46
que vale a pena, né? O tom, a gente conversou aqui
24:48
que ele não vai alterar nada, ele não, ele teoricamente é uma,
24:52
ele é ileso né? Ele não tem, ele é uma conversão
24:55
sem perdas nenhuma determinística e tal.
24:58
Mas é esse encadeamento de de ferramentas e framor na busca do
25:04
menor token. Isso vale a pena?
25:05
A gente. Pode considerar também, né?
25:07
Que apesar de recortar pedaços da resposta, a gente também tá
25:12
fazendo a manutenção da janela de contexto.
25:15
E é algo que também influencia muito na resposta final do
25:20
agente de IA, se nós temos uma janela de contexto muito grande.
25:25
A tendência é que o modelo de LN ele ele só vai manter ali pra
25:31
resposta final o início da janela de contexto e o final da
25:34
janela de contexto. O que está no medo ali?
25:38
Possivelmente ele vai descartar por si próprio como a janela de
25:41
contexto. Ela tem uma limitação de tamanho
25:44
de tokens que ela consegue suportar a maioria dos modelos
25:47
entre 200000 tokens e 1000000 de tokens, um pouco mais aí,
25:51
devendo a modelo, o próprio modelo começa a fazer a
25:53
compressão da janela de contexto, então ele mesmo vai
25:56
retirar dados do que a gente tem ali no contexto para resposta e
26:02
vai também fazer essa compressão.
26:04
Outro ponto. Bacana da gente ver.
26:08
Tem um artigo feito pela Microsoft em 2023.
26:12
Eles fizeram uma implementação, eles chamaram Jeremy linguay,
26:16
esse cara. Ele nada mais é do que também 11
26:20
intermediário entre o usuário e a lelen que faz a compressão do
26:25
texto. Ou seja, eles fornecem um texto,
26:28
faz a compressão dele com um modelo menor local treinado ali
26:33
pra isso. E fornece pra ln e a grande
26:37
maioria dos resultados OA resposta se mantém com a mesma
26:40
qualidade, porque pra lln é um pouco irrelevante.
26:45
Tudo que a gente usa nossa linguagem e bom conectores de
26:48
frases é dados ali que não são relevantes pra estrutura da
26:53
minha frase. Eu simplesmente posso recortar
26:55
isso e mandar pra lline. E na maioria dos casos, ela vai
26:59
sim, conseguindo dar uma resposta com a mesma curácia do
27:01
que eu tinha antes. Você falando aí, Joana, eu
27:03
lembrei de um negócio até que tá no episódio que a gente falou,
27:06
né, do das previsões para 2027, né, que era OAI to taus and Tony
27:11
seven, né? Eu acho que é, né, que é Oo
27:13
report. E eles falam, né, que algum
27:15
momento aí entre esse ano e ano que vem as LLMS vão otimizar
27:19
esse essa parte da linguagem que vai se transformar realmente
27:23
numa linguagem não entendível por nós, mas entendível pela
27:26
máquina, né? Pelas LLMS, justamente por causa
27:29
disso que você falou, porque tem muita construção ali que ainda é
27:32
linguagem natural por nossa causa, né?
27:34
Pra gente conseguir ler, se comunicar e ter 11 bom trânsito
27:38
entre o que a gente quer e o que a gente, né, está transmitindo
27:40
pra LLM em algum momento isso não vai precisar existir, né?
27:43
Que é pra mim é tudo essas coisas.
27:45
Elas vão sendo criadas nesse caminho.
27:48
Né? De ficar transformando cada vez
27:49
mais essa linguagem natural, que é o que a gente conhece em algo
27:53
que é totalmente entendido pela máquina.
27:55
E tá tudo bem também, né? E é e é isso que ela precisa.
27:57
Então tá bom. É, nós vamos cortar só o
27:59
intermediário, né? Porque hoje a gente escreve
28:01
código de maneira legível, uns mais que outros, né?
28:05
EE assim, e de qualquer forma, tem a necessidade do compilador
28:09
ali no meio que vai transformar aquele código em linguagem de
28:12
máquina. A máquina não entende o nosso
28:14
código. Muitos desenvolvedores não
28:16
entendem o próprio código, mas a máquina ela né?
28:20
Vai entender o que foi compilado.
28:23
Então eu acho que nós agora estamos evoluindo para isso para
28:27
AIA, né? Nessa conversa com AIAAAA, esse
28:32
ao fazendo um paralelo ao compilador no meio.
28:34
E futuro, gente, vocês veem assim alguma perspectiva desse
28:39
formato no futuro dele ter mais relevância do que o que a gente
28:42
tá vendo agora? Porque a conclusão do nosso
28:45
episódio aqui é que existem outras técnicas que são mais
28:48
relevantes. Ele talvez faça muito sentido em
28:51
cenários bem específicos, né? Mas vocês veem esse esse formato
28:55
crescendo ou ganhando mais relevância no futuro?
28:59
Então o tom, ele saiu há quase um ano aí, né?
29:04
Ao menos o último ano, 8 meses que que começou a surgir as
29:09
conversas e de lá para cá a gente não vê muito.
29:13
Muitos casos de uso divulgados, né?
29:16
O pessoal amplamente utilizando, até porque os concorrentes do
29:21
tum se mostram em vários cenários melhores do que AO que
29:26
o tum consegue entregar hoje. E no caso de um Jason, é
29:31
danificado. A gente consegue manter a
29:34
comunicação geral de tudo. Pensando né?
29:38
Que a maioria das ferramentas de AE.
29:41
E tudo que a gente usa ali, que necessita de uma formatação, vai
29:46
estar prioritariamente. Jason, então acaba que o tum,
29:50
ele traz uma complexidade de manutenção em tudo que a gente
29:54
tem para adequar essa resposta ali nesse formato para pouco
30:00
ganho. No geral, seriam para cenários
30:03
muito específicos. E mesmo assim, talvez pode ser
30:08
que ele não seja. A melhor solução, porque a gente
30:11
tem OCSB pra dados, tabulares, enfim.
30:14
Então, no geral, eu acho que o tum não deve alemão cá.
30:18
Eu concordo também acho que o tum não vai muito pra frente,
30:22
mas acho que ele foi quase um pioneiro, né?
30:25
Pelo menos o que foi mais falado em relação a essa preocupação
30:28
maior com os token existe, talvez.
30:30
Traga uma vontade maior, uma faísca pra gente talvez otimizar
30:35
o Jason. Otimizar é as formas que a gente
30:37
trabalha na dentro da pipeline pra garantir que gaste menos
30:41
tokens. Mas eu enxergo ele mais como uma
30:43
faísca do que de fato como 11. Ferramenta que a gente vai
30:46
conseguir utilizar daqui pra frente.
30:48
Com certeza. E esse tema, né?
30:50
Assim de economia de tokens, é um tema finops de Ah, é um tema
30:54
que tá aí batendo na nossa foto o tempo inteiro.
30:57
E a gente vai ter um episódio em breve sobre isso.
30:59
Então, se você, ouvinte, está curioso em mais estratégias, o
31:03
que fazer? E o finops de a no final das
31:06
contas, né? Que é como controlar o custo,
31:09
reduzir o custo e ter transparência do custo com AIAA
31:13
gente, vai ter um episódio sobre finops de a em breve.
31:16
E até mesmo já puxando esse gancho, né?
31:18
Porque nós estamos aqui falando economia de to, economia de
31:21
tour, quem vai fazer isso melhor?
31:22
Aquilo. Mais importante de tudo, antes
31:25
de decidir se eu vou pro tum, mantenho Jason, vou usar CSV.
31:29
Você sabe o quanto de token você está gastando, porque nós
31:33
estamos aqui nessa de economia, economia e economia.
31:36
Quantos de nós realmente sabem o quanto que a empresa, o projeto
31:41
eu estou gastando de token? Porque às vezes a gente fica
31:45
nessa de seguir moda, seguir benchmark, não, agora a moda é
31:48
tum, eu vou, vou colocar o tum ali que vai ficar melhor, mas
31:52
será que vai mesmo? Você sabe, antes de antes, antes
31:55
de adotar, antes de pensar, você sabe quanto você está gastando e
31:58
você sabe onde está o gargalo? Então assim, até mesmo eu acho
32:01
que um primeiro passo antes da gente ficar discutindo, vou usar
32:04
tum, não vou é qual o ralo que seus tokens estão escorrendo é
32:08
OOO tum, tampa esse ralo porque se não for, esquece, não é não é
32:12
esse o caminho. E inclusive, gente, quem quiser
32:15
saber mais sobre isso tem um episódio no entre chaves muito
32:18
bacana sobre gestão de tokens. Não perca, volta lá agora.
32:22
Agora não, acaba o episódio com calma e vai lá já ouvir esse
32:25
episódio. É isso aí, assim, então a gente
32:27
viu que realmente existem muitas e muitas estratégias para, né?
32:32
Gestão de custo de token. O tum é uma delas, mas é uma,
32:37
como eu gostei do que o Gustavo falou ali, é uma faísca que
32:39
talvez não pegou fogo. Mas é um formato que pode ser
32:44
usado em casos específicos, né? Que a gente foi descrevendo aqui
32:47
ao longo do episódio. Mas aparentemente não é um
32:49
formato que vai pegar para todo mundo, que a gente vai precisar
32:53
mudar as nossas APIs para não retornar a Jason mais, para
32:56
retornar tum e tal, porque isso é provavelmente não é isso que
32:59
vai acontecer. Em relação à economia de custo,
33:02
existem várias e várias outras opções alternativas, trocar o
33:06
Thinking, trocar o modelo e várias outras que a gente falou
33:09
no episódio de gestão de tokens. E várias outras que vamos falar
33:12
no episódio de finops de a também.
33:15
Bom, com tudo isso, acho que hoje o nosso embate, o tum saiu
33:20
perdendo, infelizmente de lavada, de lavada, mas é isso
33:25
aí, eu gostei muito da conversa, espero que todos os nossos
33:28
ouvintes tenham gostado. Deixa a sua opinião aí, se você
33:31
já usou o tum ou não e qual foi a sua experiência com isso?
33:34
Curta e compartilhe entre as chaves com seus amigos e até a
33:39
próxima. Tchau, tchau.
33:40
Até a próxima, pessoal. Ligou.
33:42
Até mais gente, obrigado.