Lift, da Datalab: 90,2% de precisão, 3x mais rápido... e o número que ficou de fora

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Lift by Datalab: 90.2% Accuracy, 3x Faster… and the Number They Left Out · Canal: Prompt Engineer 48 · 09:52 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Governança e regulação de IA, Modelos multimodais

Resumo

O vídeo apresenta o Lift, modelo de visão de 9 bilhões de parâmetros da Datalab que extrai dados de PDFs e imagens diretamente para JSON conforme um schema, sem uma etapa separada de OCR. O benchmark divulgado mostra 90,2% de precisão por campo e processamento cerca de três vezes mais rápido que o Gemini Flash 3.5, mas apenas 20,9% de precisão em documentos inteiros, abaixo do Gemini Flash e até do modelo Qwen citado. O vídeo também explica como instalar e usar a ferramenta, comenta limitações dos schemas, requisitos de GPU não documentados e os termos da licença dos pesos. A recomendação é testar o modelo nos próprios documentos e usar validação ou revisão humana quando cada campo precisa estar correto.

Pontos-chave

O Lift recebe um PDF ou uma imagem e um schema JSON, e produz um objeto JSON no formato especificado.
O modelo processa documentos de várias páginas em uma única passagem e pode deixar campos como null quando a informação está ausente.
O decoder com restrições de schema tem limitações: schemas com enum, oneOf, ref ou additionalProperties podem não ser compilados.
No benchmark da Datalab, o Lift alcançou 90,2% de precisão por campo, contra 91,3% do Gemini Flash 3.5.
O tempo mediano informado foi de 9,5 segundos por documento para o Lift e 28,1 segundos para o Gemini Flash; a comparação foi feita com oito solicitações concorrentes.
Na precisão em documentos inteiros, em que todos os campos precisam estar corretos, o Lift marcou 20,9%, contra 40% do Gemini Flash.
O requisito mínimo de memória da GPU não foi encontrado na documentação analisada pelo apresentador; o servidor oferece suporte a GPUs a partir da T4.
O código usa licença Apache 2.0, mas os pesos têm uma licença OpenRAIL modificada, com restrições comerciais e de concorrência com a API da Datalab.
O apresentador recomenda testar o Lift nos próprios documentos e adicionar validação ou revisão humana para casos em que erros de campo sejam críticos.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o Lift e como funciona	O vídeo apresenta a extração de dados de documentos, o funcionamento do Lift e a saída JSON baseada em schema.
02:33	Schemas, instalação e uso	O apresentador explica as limitações de schemas, as opções de instalação e execução e o uso do Schema Studio.
05:10	Benchmark: precisão e velocidade	A comparação destaca a precisão por campo e a velocidade, mas também a diferença na precisão em documentos inteiros.
07:45	Licença, limitações e recomendações	O vídeo detalha as restrições dos pesos, a oferta hospedada da Datalab e os casos em que vale testar o Lift.

Citações

Um modelo, uma etapa, sem OCR nem código de reparo. — 01:32

E, sinceramente, esse é o recurso que mais importa para mim. — 02:03

No entanto, nessa métrica o Lift não está na frente. — 06:43

Se você está criando um fluxo em que cada campo precisa estar correto, esse número importa mais do que o destaque da manchete. — 07:15

Se você precisa que todos os campos de um documento longo estejam corretos, sem intervenção humana, eu começaria pela API hospedada ou adicionaria uma etapa de verificação. — 09:21

Conceitos e entidades

Lift (modelo): Modelo de visão da Datalab que extrai informações de documentos para JSON guiado por um schema.
Datalab (empresa): Empresa responsável pelo Lift, por ferramentas de OCR e pelo benchmark apresentado no vídeo.
Gemini Flash 3.5 (modelo): Modelo comparado ao Lift no benchmark de precisão por campo, precisão em documentos inteiros e velocidade.
Qwen3.5 9B (modelo): Modelo de base citado na comparação de precisão em documentos inteiros e precisão por campo.
Schema Studio (ferramenta): Aplicativo Streamlit para criar, salvar e testar schemas com documentos próprios.
Marker (ferramenta): Ferramenta de OCR associada à equipe da Datalab.
Surya (ferramenta): Ferramenta de OCR mencionada como parte do trabalho da equipe da Datalab.
Chandra (ferramenta): Ferramenta de OCR mencionada como parte do trabalho da equipe da Datalab.
JSON Schema (conceito): Formato usado para definir os campos e tipos de dados esperados na extração.
Schema constraint decoding (conceito): Método que restringe a geração para que o resultado siga o schema fornecido.
OpenRAIL (conceito): Família de licenças mencionada para os pesos do Lift, que usam uma versão modificada com restrições.
Apache License 2.0 (conceito): Licença indicada para o código do Lift.

Tradução completa (pt-BR)

00:00 Certo, neste vídeo vamos analisar o Lift, um novo modelo open source que transforma um PDF em JSON limpo. Mas atenção: alguns dos números que estão circulando sobre ele não contam a história toda. Aqui está uma publicação no X que diz: “Todo mundo está ignorando este novo modelo de extração de JSON. Ele tem pesos abertos. Igualou o Gemini Flash 3.5 e é três vezes mais rápido.” Parte disso é verdade, e parte merece uma análise mais cuidadosa. Então, examinei o repo no GitHub, a publicação no blog da Datalab e a tabela completa do benchmark, e vou mostrar o que realmente

00:30 há lá. Este é o plano: primeiro, o que é o Lift; depois, como usá-lo. Em seguida, o benchmark, em que vou mostrar o número bom e depois o número não tão bom; e, no final, quem realmente deveria usá-lo. Vamos começar pelo problema. Você tem uma pilha de PDFs — notas fiscais, contratos, artigos de pesquisa — e quer extrair os dados deles como campos limpos, como número da nota fiscal, total e itens. O jeito habitual de fazer isso é montar uma cadeia. Você executa OCR para obter o texto. Passa esse texto para um LLM e, depois, escreve código extra para corrigir o JSON quando o modelo o

01:01 quebra. E cada etapa dessa cadeia pode falhar. O OCR pode distorcer uma tabela. O LLM pode inventar um valor, e o JSON pode voltar sem um colchete. Três pontos para depurar. E há um quarto problema que as pessoas esquecem: quando um campo não está no documento, muitos modelos ainda assim preenchem alguma coisa — um número de identificação fiscal inventado ou uma data de vencimento inventada — e ninguém percebe. Então, o que é o Lift? É um modelo de visão de 9 bilhões de parâmetros da Datalab. Você fornece um PDF ou uma imagem junto com um schema JSON, e recebe de volta um objeto JSON que corresponde a esse

01:32 schema. Um modelo, uma etapa, sem fase de OCR e sem código de correção. O modelo analisa diretamente as imagens das páginas e lê cada campo direto da página. A Datalab diz que a saída é sempre um JSON válido no formato correto porque o modelo decodifica de acordo com o seu schema. Isso se chama decodificação com restrições de schema. Ele também processa documentos com várias páginas de uma só vez. Então, se um valor se estende por duas páginas, o modelo vê o documento inteiro ao mesmo tempo. Isso é muito útil, e o modelo foi treinado para deixar um campo como null quando a resposta não está no documento. A publicação chama isso de

02:03 abstenção por padrão e, sinceramente, esse é o recurso que mais importa para mim. A Datalab é a equipe por trás das ferramentas de OCR Marker, Surya e Chandra, e diz que o Lift é seu primeiro modelo criado exclusivamente para extração. Aqui está a lista rápida do blog: 9 bilhões de parâmetros, passagem única, várias páginas. O código está sob a licença Apache 2.0, e os pesos estão no Hugging Face. Então, você pode baixá-los. Agora vamos ver o schema, porque essa é a parte que você vai escrever por conta própria. Um schema é apenas um schema JSON padrão. Aqui temos o número da nota fiscal como uma

02:33 string, o total como número e os itens como um array. E você pode ver que cada campo tem uma descrição. Escreva uma para qualquer campo cujo nome não seja óbvio. Esse é o único trabalho de engenharia de prompt que você realmente faz com o Lift. Depois, há o campo required. Marque um campo como obrigatório somente quando ele precisar aparecer. Campos que realmente não estão no documento voltam como null. Então, não force todos os campos a serem obrigatórios. Agora, uma coisa importante: mantenha o schema simples. Strings, números, inteiros, booleanos, arrays e objetos aninhados funcionam. Mas evite enum, anyOf, oneOf, ref e additionalProperties.

03:04 Por quê? Porque o decodificador com restrições ignora schemas que não consegue compilar. E, então, a garantia de uma saída válida fica mais fraca. Isso é uma limitação real e mais uma coisa que você precisa saber. Agora, como executar? Vamos ver a instalação. É uma única linha: pip install Lift PDF. Isso instala a versão leve, que espera um servidor VLM. Depois, você inicia o servidor com Lift VLM. Nos bastidores, isso inicia um contêiner Docker e ajusta o tamanho do lote à memória da sua GPU. Há suporte para H100, A100, L40S,

03:36 A10, L4, 4090, 3090 e até T4. Então, não é só para placas de data center. Depois, você executa lift extract. Em seguida, informa o PDF de entrada, a pasta de saída e o parâmetro –schema apontando para o arquivo do seu schema. Bem simples. Você também pode passar o schema diretamente como uma string JSON, usar o nome de um schema salvo ou limitar as páginas com page range — por exemplo, da página 0 à 5 e a página 8. Aponte para uma pasta em vez de um arquivo, e ele processa o diretório inteiro. Para cada

04:07 arquivo, você recebe o JSON e um segundo arquivo de metadados com a contagem de páginas, a contagem de tokens e qualquer erro. Se não quiser usar um servidor, há um modo Hugging Face: pip install lift PDF com o extra hf, seguido do método hf, e os pesos são carregados na sua própria máquina. Ele precisa de storage e torch, e a recomendação é usar flash attention. Em Python, você importa extract de Lift, passa o documento e o schema e lê result.extraction. Se a extração falhar, esse valor será None, e os metadados manterão a saída bruta para depuração. Há mais uma ferramenta:

04:38 o Schema Studio. É um pequeno app do Streamlit. Você executa Lift app e pode criar, salvar e testar seus schemas com os seus próprios documentos. É um ótimo lugar para começar. Agora, a pergunta que todo mundo faz: de quanta memória de GPU você precisa? E preciso ser sincero: não encontrei um valor mínimo em lugar algum no README ou no blog. O que sabemos é que se trata de um modelo de 9 bilhões de parâmetros, e o servidor se ajusta sozinho para placas a partir de uma T4. Então, não vou prometer um número aqui. Vou medir isso no próximo vídeo. Agora, vamos ao benchmark, porque é aqui que a

05:10 história fica interessante. A Datalab testou o modelo em 225 documentos, com 6 a 64 páginas cada, e cerca de 11 mil campos avaliados. Eles incluíram casos difíceis de propósito: valores distribuídos entre páginas, listas exaustivas, campos que devem ficar como null, distratores parecidos com a resposta e valores que é preciso somar a partir de vários lugares. A avaliação usa correspondência exata com os dados de referência, com uma tolerância para números. E todos os modelos receberam as mesmas imagens das páginas e precisaram extrair cada documento em uma única passagem. Então, essa parte é justa. Aqui está a tabela

05:40 no topo. A API hospedada da própria Datalab: 95,9% de precisão por campo. Depois, Gemini Flash 3.5, com 91,3%, e então Lift, com 90,2%. Abaixo do Lift, temos Azure Content Understanding, com 83,4%; New Extract 3, com 81,5%; e Qwen 3.5 9B, com 76,3%. Então, entre os modelos que você pode hospedar por conta própria, o Lift está claramente na frente. Ele está 13,9 pontos acima do modelo Qwen básico de mesmo tamanho e quase 9 pontos acima do New Extract. Agora, vamos comparar

06:11 o Lift com o Gemini Flash. Ele fica em 90,2 contra 91,3, uma diferença de 1,1. Então, dizer que quase iguala é justo; dizer que iguala é um pouco generoso. Quanto à velocidade, a mediana é de 9,5 segundos por documento para o Lift. O Gemini Flash leva 28,1, e a API da Datalab, 30,8. Ou seja, aproximadamente três vezes mais rápido, e essa afirmação é verdadeira. Uma observação da própria Datalab: essas latências foram medidas com oito solicitações simultâneas. Os modelos locais foram executados em uma única GPU com vLLM, e os outros, por meio de uma API. Eles dizem

06:43 para considerar esses valores relativos, não absolutos. Mas agora veja a outra coluna: precisão do documento completo. Essa é a proporção de documentos em que todos os campos estão corretos. O Gemini Flash chega a 40%, a API da Datalab, a 44,4%, e o Lift, a 20,9%. Então, o resultado é cerca de metade do Gemini Flash. E veja o Qwen 3.5 9B: o modelo básico chega a 24%, mais do que o Lift, e o Azure chega a 22,2%. Então, nessa métrica, o Lift não está na frente. Agora, para ser justo, avaliar o documento completo é um teste bem rigoroso.

07:15 Esses documentos chegam a 64 páginas, com muitos campos, e um único campo incorreto reprova o documento inteiro. Mas, se você está montando um pipeline em que todos os campos precisam estar corretos, esse número importa mais do que o resultado em destaque. Na prática, você vai querer uma etapa de validação ou uma revisão humana dos campos importantes. Então, o que a publicação afirma corretamente? Pesos abertos, sim. Três vezes mais rápido, sim. Quase iguala o Gemini Flash em precisão por campo, sim. O que ela deixa de fora é que, em documentos completos, o resultado é cerca de metade. E mais uma coisa: esse benchmark é da Datalab

07:45 próprio, criado pelas pessoas que fizeram o Lift. Isso não significa que esteja errado, mas eu testaria com seus documentos antes de confiar nele. Além disso, todos os modelos foram executados com as configurações padrão ou recomendadas. Portanto, uma configuração de fine-tuning pode alterar um pouco esses números. Agora, sobre a licença: pesos abertos nem sempre significam uso gratuito para qualquer finalidade. O código está sob a licença Apache 2.0, que é a mais simples. Os pesos usam uma licença OpenRAIL-M modificada. O uso é gratuito para pesquisa ou uso pessoal e para startups com menos de US$ 5 milhões em financiamento ou receita. E a ressalva é que você não pode usá-lo

08:17 em concorrência com a própria API da Datalab. Se quiser remover essas limitações, você precisa de uma licença comercial, disponível na página de preços deles. Para muitos de vocês que estão assistindo e têm projetos pessoais ou startups pequenas, tudo bem. Mas, se sua empresa for maior, leia a licença antes de desenvolver algo com base nele. Também há a opção hospedada. A Datalab diz que a plataforma gerenciada deles executa uma pilha de extração aprimorada, com maior precisão do que os pesos abertos, além de verificação por campo, citações e pontuações de confiança. Essa é a linha de 95,9% na tabela, e você recebe US$ 20 em créditos gratuitos

08:49 todo mês ou pode experimentar o playground público sem configurar nada. Então, essa é uma história típica de núcleo aberto. O modelo aberto permite que você comece, e a API hospedada é para onde eles querem que você vá em busca da melhor precisão. Não há nada de errado nisso, mas é bom saber desde o início. Então, aqui vai minha opinião. O que eu gosto é que é um modelo para uma tarefa que antes exigia três etapas. A saída é um JSON válido. Ele deixa os campos como null quando os dados estão ausentes e é rápido. O que eu observaria: a precisão em documentos completos é baixa. O schema tem limitações. O requisito de GPU

09:21 não está documentado. E o benchmark vem da equipe que criou o modelo. Para quem ele é? Se você processa muitos documentos, como faturas, formulários e relatórios, e quer hospedar o modelo por conta própria, vale a pena testar o Lift. Principalmente quando velocidade e custo são importantes. Se você precisa que todos os campos estejam corretos em um documento longo, sem nenhuma pessoa no processo, eu começaria pela API hospedada ou acrescentaria uma etapa de verificação ao Lift. Essa é minha avaliação sincera. E, se você só quiser experimentar, o jeito mais simples é usar o playground ou o Schema Studio com alguns documentos seus. Confira primeiro os valores null

09:52 porque é aí que os modelos costumam falhar. No próximo vídeo, vou alugar uma GPU, executar o Lift em faturas reais e em um artigo de pesquisa e contar quanta memória ele realmente usa e quantos campos acerta de verdade. Então, neste vídeo, vimos o que é o Lift, como usá-lo e o que o benchmark realmente indica. Os links estão na descrição. Contem para mim como foi, e vejo vocês no próximo.

Transcrição original

[00:00] All right, in this video we will look at Lyft, a new open model that turns a PDF into clean JSON. Now, mind you, some of the numbers going around about it are not the full story. So, here is a post on X that says, “Everyone is sleeping on this new JSON extraction model. It says open weights. It matches Gemini Flash 3.5 and it is three times faster.” Some of that is true and some of it needs a closer look. So what I’ve done is I’ve gone through the GitHub repo, the data lab blog post and the full benchmark table and I’ll show you what is really

[00:30] in there. Here is the plan. First what Lyft is, then how you use it. Then the benchmark where I’ll show you the good number and then not so good number and at the end who should actually use it. Let’s start with the problem. You have a stack of PDFs, invoices, contracts, research papers and you want the data inside them as clean fields like invoice number, total and the line items. The usual way to do this is a chain. You run OCR to get text. You hand that text to an LLM and then you write extra code to repair the JSON when the model breaks

[01:01] it. And every link in that chain can fail. OCR can mangle a table. The LLM can invent a value and the JSON can come back with a missing bracket. Three places to debug. And there is a fourth problem that people forget. When a field is not in the document, a lot of models will still fill something in. a madeup tax ID or a madeup due date and nobody notices. So what is lift? It is a 9 billion parameter vision model from datal lab. You give it a PDF or an image along with a JSON schema and you get back a JSON object that matches that

[01:32] schema. One model, one step, no OCR stage, no repair code. The model looks at the page images directly and reads each field straight from the page. Datal lab says the output is always valid JSON of the right shape because the model decodes against your schema. This is called schema constraint decoding. It also handles multi-page documents in one pass. So if a value spans two pages, the model sees the whole document at once. That is really useful and it is trained to leave a field null when the answer is not there. The block calls this

[02:03] abstension by default and honestly this is the feature that matters most to me. Data lab is the team behind the OCR tools marker. Surya and Chandra and they say Lyft is their first model built purely for extraction. Here is the quick list from the blog 9 billion parameters single pass multi-page. The code is Apache 2.0 and the weights are on hugging face. So you can download them. Now let’s look at the schema because this is the part you will write yourself. A schema is just standard JSON schema. Here we have invoice number as a

[02:33] string, total as a number and line items as an array. And you can see here each field has a description. Write one for any field whose name is not obvious. This is the only prompt engineering you really do with lift. Then there’s required. Mark a field required only when it must appear. Fields that really are not in the document come back null. So don’t force everything to be required. Now one important thing. Keep the schema simple. Strings, numbers, integers, booleans, arrays, and nested objects are all fine. But avoid enum any of one of ref and additional properties.

[03:04] Why? Because the constraint decoder skips schemas. It cannot compile. and then the guarantee of valid output gets weaker. So this is a real limit and it is one extra thing you need to know. Now how do you run it? Let’s go ahead and look at the install. It is a single line pip install Lyft PDF that gives you the light install which expects a VLM server. Then you start the server with Lyft VLM. Behind the scenes this launches a docker container and it scales the batch size to the memory of your GPU. It supports H100, A100, L4DS,

[03:36] A10, L4, 409,309 and even the T4. So this is not only for data center cards. And then you extract lift extract. Then the input PDF and output folder and d- schema pointing to your schema file. Really simple. You can also pass the schema in line as a JSON string or use the name of a save schema and limit the pages with page range for example 0 to 5 and page 8. Point it at a folder instead of a file and it processes the whole directory. For each

[04:07] file you get the JSON and a second metadata file with the page count token count and any error. If you don’t want a server there is a hugging face mode pip install lift PDF with the hf extra add- method hf and the weights load on your own machine. It needs storage torch and they recommend flash attention. And for Python, you import extract from Lyft, pass the document and the schema and read result.extraction. If extraction fails, that value is none and the metadata keeps the raw output for debugging. There is one more tool,

[04:38] schema studio. It is a small streamlit app. You run Lyft app and you can build, save and test your schemas against your own documents. It is a really good place to start. Now the question everyone asks, how much GPU memory do you need? And I have to be honest, I could not find a minimum anywhere in the readme or the blog. What we know is that it is a 9 billion parameter model and the server tunes itself for cards from a T4 up. So I won’t promise you a number here. I will measure it in the next video. Now the benchmark because this is where the

[05:10] story gets interesting. Data lab tested on 225 documents, 6 to 64 pages each with about 11,000 scored fields. And they planted hard cases on purpose. Values across pages, exhaustive lists, fields that must be left null, near miss distractors, and values you have to add up from several places. Scoring is exact match against ground truth with a tolerance for numbers. And every model got the same page images and had to extract each document in a single pass. So that part is fair. Here’s the table

[05:40] at the top. Datalab’s own hosted API 95.9% field accuracy. Then Gemini Flash 3.5 at 91.3 and then Lyft at 90.2. Below Lyft we have Azure Content Understanding at 83.4, New Extract 3 at 81.5 and QN 3.59B at 76.3. So among the models you can host yourself. Lyft is clearly on top. It is 13.9 points ahead of the base QN model of the same size and almost 9 points ahead of new extract. Now compare

[06:11] Lyft with Gemini Flash. It is 90.2 2 against 91.3 that is a gap of 1.1 so nearly matches is fair matches is a little generous and speed the median is 9.5 seconds per document for lift Gemini flash takes 28.1 and the datal lab API 30.8 eight. So roughly three times faster and that claim is true. One note from data lab itself, those latencies are with eight concurrent requests. The local models on a single GPU with V LLM and the others over an API. They say

[06:43] treat it as relative, not absolute. But now look at the other column. Full document accuracy. This is the share of documents where every single field is correct. Gemini Flash gets 40%, the data lab API gets 44.4 4 and Lyft gets 20.9%. So that is about half of Gemini Flash. And look at this Quinn 3.59B the base model gets 24% which is higher than Lyft and Azure gets 22.2. So on this metric Lyft is not ahead. Now let me be fair. Full document is a really harsh test.

[07:15] These documents run up to 64 pages with a lot of fields and one wrong field fails the whole document. But if you’re building a pipeline where every field has to be right, this number matters more than the headline. In practice, you will want a validation step or a human check on the fields that count. So what does the post get right? Open weights, yes. Three times faster, yes. Nearly matches Gemini Flash on field accuracy, yes. What it leaves out is that on whole documents, it is about half. And one more thing, this benchmark is data labs

[07:45] own built by the people who made Lyft. That does not make it wrong, but I would test it on your documents before you trust it. Also, all the models were served with their default or recommended settings. So, a tune setup could shift these numbers a little. Now, the license because open weights does not always mean free for everything. The code is Apache 2.0, which is the easy one. The weights use a modified open rail m license. It is free for research or personal use and for startups under $5 million in funding or revenue. And the catch is that you cannot use it

[08:17] competitively with Datalab’s own API. If you want to remove those limits, you need a commercial license from their pricing page. For a lot of you watching personal projects and small startups, that is fine. But if you are bigger company, read the license before you build on it. There’s also the hosted side. Datalab says their managed platform runs an improved extraction stack with higher accuracy than the open weights plus per field verification, citations, and confidence scores. That is the 95.9% row in the table and you get $20 of free

[08:49] credits every month or you can try the public playground without setting anything up. So this is a normal open core story. The open model gets you started and the hosted API is where they want you to go for the best accuracy. Nothing wrong with that, but know it going in. So here’s my take. What I like it is one model for a job that used to be three steps. The output is valid Jon. It leaves fields null when the data is missing and it is fast. What I would watch full document accuracy is low. The schema has limits. The GPU requirement

[09:21] is not documented. And the benchmark comes from the team that built the model. Who is this for? If you process lots of documents like invoices, forms, and reports and you want to host it yourself, then Lyft is worth a test. Especially when speed and cost matter. If you need every field right on a long document with no human in the loop, I would start with the hosted API or add a verification step on top of lift. That is my honest read. And if you just want to try it, the simplest way is the playground or schema studio with a few of your own documents. Look at the nulls

[09:52] first because that is where models usually fail. In the next video, I will rent a GPU, run Lyft on real invoices and a research paper and tell you how much memory it actually uses and how many fields it really gets right. So, in this video, we have seen what Lyft is, how to use it, and what the benchmark really says. Links are in the description. Let me know how it goes, and I’ll see you in the next one.