Crie RAG com JEV

Autoria: Prompt Engineering · 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: Build RAG with JEV · Canal: Prompt Engineering · 11:05 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, RAG, busca e recuperação de informação

Resumo

O vídeo demonstra como usar JEV em pontos de decisão de um pipeline de RAG, com foco em reordenar documentos segundo critérios e políticas específicas. O apresentador compara esse método com cross-encoders e com um LLM usado para reordenamento, destacando a capacidade de seguir instruções, o custo e a velocidade. Também mostra como aplicar critérios como classificadores e relata um teste em que JEV elevou a acurácia top-1 de 21% para 54%.

Pontos-chave

JEV pode ser usado para tomar decisões em diferentes etapas de um pipeline de RAG.
O vídeo apresenta três primitivas: decisão binária, escolha entre opções e atribuição de pontuações.
Critérios explícitos permitem orientar o reordenamento de documentos conforme políticas ou necessidades distintas.
Distâncias vetoriais medem proximidade semântica, mas não garantem que um trecho esteja correto segundo a lógica do negócio.
Cross-encoders não seguem instruções sobre os critérios de reordenamento, enquanto JEV pode ser direcionado por elas.
Usar um LLM para reordenar pode seguir instruções, mas tende a ser mais caro e lento.
O apresentador relata que a execução concorrente de decisões reduziu o tempo de cerca de 40 segundos para 7,6 segundos no teste descrito.
Em um teste com busca textual BM25, adicionar JEV como reordenador elevou a acurácia top-1 de 21% para 54%.

Capítulos

Início	Capítulo	Resumo
00:00	JEV aplicado a pipelines de RAG	O apresentador introduz JEV e explica por que decisões como filtragem, reordenamento e citações podem ser bons usos da ferramenta.
02:39	Exemplo de recuperação e critérios de decisão	É apresentado um exemplo de recuperação de documentos em que mudanças de política podem não ser refletidas pela similaridade vetorial.
05:18	Critérios como política executável	O vídeo mostra como usar critérios para distinguir trechos que respondem diretamente à consulta daqueles que apenas compartilham palavras ou temas.
07:26	Comparação de métodos de reordenamento	O apresentador compara JEV com cross-encoders e LLMs usados para reordenar, considerando instruções, velocidade e custo.
10:03	Resultados e aplicação em workflows	O vídeo relata o aumento de acurácia top-1 com JEV e conclui que a ferramenta pode substituir pontos de decisão em workflows existentes.

Citações

JEV acaba sendo um candidato perfeito para esses pontos de decisão. — 00:32

As distâncias vetoriais só conseguem medir proximidade semântica, não a correção segundo a lógica do negócio. — 03:39

As instruções que você fornece podem impactar bastante o tipo de ordenação que recebe dos documentos. — 08:27

Se você adicionar JEV como reordenador, a acurácia sobe de 21% para 54%. — 10:03

Conceitos e entidades

Jev (ferramenta): Ferramenta apresentada para tomar decisões orientadas por critérios e reordenar resultados em workflows como pipelines de RAG.
RAG (conceito): Abordagem de geração que recupera documentos para fornecer contexto às respostas de um LLM.
reranking (conceito): Reordenação dos documentos recuperados segundo sua relevância para a consulta e critérios adicionais.
cross-encoder (conceito): Modelo usado para classificar a relevância de pares de consulta e documento, sem seguir instruções personalizadas de reordenamento no exemplo discutido.
BM25 (conceito): Método de busca textual usado como baseline no teste de recuperação apresentado.
Gemini (modelo): Modelo mencionado na comparação de custos e desempenho com JEV.

Tradução completa (pt-BR)

00:00 Jev parece ser a única coisa de que as pessoas estão falando agora, mas eu queria criar um vídeo mostrando exemplos práticos de onde exatamente você pode usar isso, porque, para ser sincero, não há muito conteúdo sobre o assunto. Então, decidi combiná-lo com um dos meus temas favoritos, que é a geração aumentada por recuperação. Isso é extremamente entediante, mas, se você olhar para as diferentes etapas de um verdadeiro pipeline de geração aumentada, verá que há vários pontos em que você

00:32 precisa tomar uma decisão, como reranqueamento, filtragem ou citação, e Jev acaba sendo uma opção perfeita para esses pontos de decisão. Então, neste vídeo, vamos ver como combinar Jev com a geração aumentada por recuperação para tomar essas decisões e, nesse processo, quero mostrar como pensar de fato em combinar isso com seus próprios workflows, além das demonstrações que você tem visto na internet. Agora, Jev vem basicamente com

01:05 três primitivas diferentes que você pode usar. Uma delas é a tomada de decisão binária. Você pode criar um classificador de verdadeiro ou falso. A segunda é um ranqueador de escolhas. Assim, você pode ter várias opções diferentes, definir um critério e, com base nele, selecionar uma opção específica. E então há uma lista, ou basicamente uma escala de pontuação, na qual você atribui pontuações diferentes a opções diferentes. Neste vídeo, vamos nos concentrar principalmente no reranqueamento

01:37 que, na minha opinião, é um exemplo muito interessante e que mostra as diferentes capacidades de Jev. Uma questão muito interessante que venho analisando é: e se a política de uma organização mudar, mas o contexto real ou a lógica de negócios permanecerem os mesmos? É nesse caso que a maioria dos cross-encoders falha. Agora, você pode usar algo como um reranqueador com LLM, mas o custo é proibitivo, e

02:09 descobri que Jev oferece uma combinação muito boa de estabilidade e custo extremamente baixo. Há outros exemplos: se você estiver criando algo como Graph RAG, em que precisa extrair conhecimento de um corpus, pode usar Jev para validar as entidades extraídas. Provavelmente vou abordar isso em outro vídeo. Agora, se você é novo no Jev e quer entender o que ele faz exatamente, para além

02:39 da empolgação em torno dele, recomendo muito assistir a este vídeo. Certo. O link para o notebook estará na descrição do vídeo. O exemplo que vamos tentar resolver aqui é o seguinte: há um sistema de geração aumentada por recuperação com documentos; em vez de apenas extrair trechos ou documentos, pode haver várias políticas concorrentes, em versões diferentes, e o sistema precisa lidar com elas. Quando você executar este bloco, ele vai pedir a chave de API.

03:09 É muito barato. Você recebe, na verdade, US$ 5 em crédito grátis ao se cadastrar. Aqui, estou usando o SDK oficial para Python. Você também pode usar a API REST, se preferir. Depois, temos várias funções auxiliares. Você consulta, recupera documentos e, então, o LLM gera uma resposta com base nesses documentos. No entanto, pode haver mudanças nas políticas ou atualizações na documentação que talvez não sejam refletidas

03:39 na forma como as respostas são geradas, porque as distâncias entre vetores só conseguem medir proximidade semântica, não a correção de acordo com a lógica de negócios. Em alguns exemplos, como mencionei, pode haver mudanças na documentação oficial da API, ou talvez você esteja procurando uma explicação arquitetural aprofundada, em vez de trechos rápidos para copiar e colar. Certo. Então, no restante do vídeo, vamos usar um benchmark. Há uma consulta com vários pontos candidatos diferentes e, depois,

04:12 há duas versões oficiais diferentes da política, que vão mudar com o tempo, e vamos testar várias opções. Uma é o cross-encoder, depois o reranqueador com LLM e, por fim, Jev com o critério nulo. No processo, você vai ver a eficácia de um classificador como Jev, que é capaz de seguir instruções. Neste exemplo, a consulta será: como corrijo o erro 401 de não autorizado nas APIs? E, para

04:46 simplificar, tenho vários trechos diferentes que suponho que seriam retornados pela busca vetorial ou pela busca de texto completo, junto com vários metadados. É isso que você esperaria de um pipeline simples de geração aumentada por recuperação. Agora, queremos criar um reranqueador que basicamente os classifique não apenas com base na consulta do usuário, mas também em instruções adicionais. Certo, mas primeiro precisamos entender as primitivas, especificamente como

05:18 usar critérios como uma política executável. Como eu disse, há três primitivas diferentes. Vamos usar o modo nulo, que atribui probabilidades calibradas, com duas saídas possíveis: verdadeiro ou falso. Neste caso, vamos usar critérios como uma política. Em vez de instruções no prompt, os critérios definem limites de decisão rígidos. Aqui está um conjunto de instruções que diz: o trecho responde diretamente à pergunta?

05:50 Agora, há dois critérios diferentes. Verdadeiro significa que responde especificamente à pergunta, e falso significa que compartilha palavras ou tópicos, mas não responde a ela. Portanto, não se trata apenas de verdadeiro ou falso. Você pode encontrar o critério específico que quiser. E, só para mostrar como funciona, aqui tenho um dicionário com várias chaves diferentes. Por exemplo, uma resposta direta seria algo como: “Os reembolsos são enviados para a forma de pagamento original em até 14 dias.” Certo? E então poderia haver

06:22 outro exemplo que se sobrepõe ao tema, mas não responde de fato à pergunta. Também pode haver outro com correspondências baseadas em palavras-chave, certo? E, depois, algo completamente fora do assunto e sem relação. Agora, se executarmos as quatro consultas com nosso critério nulo, Jev atribui a maior probabilidade à resposta direta. Nas outras, você pode ver que a confiança é bem baixa. Certo? Então, isso pode ser usado como um classificador. Você pode definir um limiar

06:54 abaixo do qual rejeita a resposta. Certo. Antes de mostrar meus experimentos, testei algumas ideias para ver se poderíamos executar várias consultas simultâneas com esse sistema, e ele parece funcionar muito bem com concorrência. Por exemplo, se você executasse várias consultas em sequência, neste caso, com 17 decisões diferentes por segundo, levaria cerca de 40 segundos. Porém, se você executasse

07:26 essas consultas em sequência. No entanto, se você usar os 64 pools que ele oferece, consegue obter todas as decisões em 7,6 segundos, o que é incrível. Certo, no restante do vídeo vamos usar Jev como reranqueador, e quero compará-lo diretamente com um cross-encoder e com um LLM como reranqueador para ver quão eficaz ele pode ser. Neste caso, estamos fornecendo especificamente um critério com base no qual ele precisa

07:57 classificá-los, e há dois critérios diferentes. O primeiro é, digamos, uma política chamada “versão autoritativa 2”, e vamos usar a primitiva nula, o que significa que há duas opções diferentes. Depois, há uma segunda, “solução alternativa rápida”, que não é tão rigorosa quanto a autoritativa. A principal conclusão é que, com base no critério que você definir, a classificação dos documentos que receberá do Jev vai

08:27 ser bem diferente. Portanto, o critério, ou as instruções que você fornece e que podem ser ajustadas, pode realmente afetar o tipo de classificação que você obtém para os documentos. Essa é a beleza disso, porque você pode orientar o reranqueador dessa forma. Tradicionalmente, usamos cross-encoders para reranquear: você fornece um par formado por uma pergunta e um documento ou trecho, certo? Mas ele não tem realmente a capacidade de seguir instruções. Então, fica

08:58 meio congelado no tempo. Certo. Mas talvez você esteja pensando que existe uma segunda opção: usar um LLM como reranqueador, que consegue seguir instruções. Você pode dizer exatamente quais devem ser os critérios de classificação, e isso é verdade. No entanto, isso vai custar caro e geralmente é muito mais lento. Para mostrar um exemplo, executei o mesmo prompt e a mesma consulta no Jev, no Gemini Flashlight e no Gemini Flash. O custo é extremamente alto em comparação

09:31 O mais interessante é que o custo realmente depende do tamanho dos chunks. Então, para tamanhos de chunk relativamente pequenos, tanto a velocidade quanto o custo do Jev são muito próximos dos do Flashlight. No entanto, à medida que você aumenta o tamanho, o custo continua praticamente aumentando de forma linear. Porém, a maior diferença aparece quando você começa a aumentar o tamanho dos chunks. É aí que ele realmente se destaca. Certo. Agora, mais uma coisa: o

10:03 a precisão da resposta final depende muito da precisão da recuperação. Então, neste caso, criei uma linha de base que usa busca de texto completo BM25. Um conjunto de consultas em que você pode ver que a precisão da linha de base é de apenas 21%. Mas, se você adicionar o Jev como reranker, ela sobe para 54%. E estamos falando da precisão top-1, certo? Então, geralmente, você terá, digamos, 10 ou 20 chunks diferentes e calculará

10:34 o top K; nesse caso, esse valor será bem mais alto. Certo. Então, este foi um exemplo rápido de como você pode usar um modelo como o Jeff para substituir diferentes pontos de decisão nos workflows que já existem. RAG é um ótimo exemplo disso, e você pode conectar diretamente o Jeff como substituto imediato nos seus workflows, especialmente se precisar tomar decisões em pontos específicos. Essas decisões não precisam ser binárias como as do Jev.

11:05 Estou pensando em criar mais conteúdo para mostrar como você pode usar o Jev como parte dos workflows que já existem. Se houver algum tópico específico de seu interesse, me avise. Ficarei feliz em abordá-lo nos próximos vídeos. Enfim, espero que você tenha achado este vídeo útil. Obrigado por assistir e, como sempre, até o próximo.

Transcrição original

[00:00] Jev, it seems to be the only thing people are talking about right now, but I wanted to create a video showing you practical examples of where exactly you can use this because there is not much content on it to be honest. So I decided to combine it with one of my favorite topics which is retrieval augmented generation. Now it’s extremely boring but if you look at different steps in a true augmented generation pipeline you see that there are multiple places where you

[00:32] have to make a decision such as reancher filter or citation and jev turns out to be a perfect candidate for those decision points. So in this video we’re going to look at how you can combine Jev with the retrieval of augmented generation for making these decisions and in the process I want to show you how to actually think about combining it this into your own workflows beyond the demos that you have been seeing on the internet. Now Jeff basically comes with

[01:05] three different primitives that you can use. One is binary decision making. You can create two or false classifier. The second one is choice ranker. So you can have multiple different choices, define a criteria and based on that select a specific choice and then you have a list or basically a score ladder we where you assign different scores to different options. Now for this video we’re going to be mainly focusing on the reranking

[01:37] which I think is a very interesting example which actually shows you different capabilities of Jev. One very interesting topic that I have been looking at is what if the policy of an organization changes but the actual context or the business logic remains the same. This is where most of the cross encoders actually fail. Now you can use something like an LLM reanker but it’s prohibitively expensive and I

[02:09] found that Jev actually gives you a really great combination of sterility and extreme low cost. Now there are other examples like if you are building something like graph rag where you need to extract knowledge from a corpus you can actually use jev to validate entities that are extracted. I’ll probably cover this in another video. Now if you’re new to Jev and want to understand what exactly it does beyond

[02:39] the hype I highly recommend to watch this video. Okay. So link to the notebook is going to be in the video description. Now the example we’re going to be trying to solve here is that there’s a two documented generation system as opposed to extract chunks or documents but there could be multiple different competing policies different versions and the system needs to resolve around them. When you run this block it’s going to ask you for the API key.

[03:09] It’s dirt cheap. You actually get $5 of free credit when you sign up. Here I’m using the Python official SDK. You can also use the rest API if you like that. Then we have a number of different helper functions. You have query the retrieve documents and then the LLM generates a response based on those documents. However, in the middle there could be some policy changes, updates to documentation which may not be actually reflected

[03:39] in how the answers are being generated because your vector distances can only measure semantic proximity but not correctness under your business logic. In a couple of examples I as I mentioned there might be changes to the official API docs or you might be looking for in-depth architectural explanation versus quick copy paste snippets. Okay. So in the rest of the video the benchmark that we’re going to be using. So there is um one query with multiple different candidate points and then

[04:12] there are two different official uh versions of the policy which are going to change over time and we’re going to test multiple different options. One is the cross encoder then LLM reanker and then Jev with the null criteria and in the process you’re going to actually see the effectiveness of a classifier like Jev which has the ability to follow instructions. So for this example, our query is going to be how do I fix 401 unauthorized error from the APIs. And to

[04:46] make it simple, I have a bunch of different chunks that I’m assuming are going to be returned from the either vector search or full text search along with a bunch of metadata. So this is what you would expect from a simple retrieval augmented generation pipeline. Now we want to create a reranker which is going to basically rank them and not only based on the user query that is provided but also additional instructions okay but first we need to understand primitives specifically how

[05:18] do we use criteria as a executable policy now as I said there are three different primitives we’re going to be using null which basically assigns calibrated probabilities and there are two potential outputs whether it’s true or false criteria. Now in this case we’re going to be using criteria as a policy which instead of prompt in instructions the criteria provides strict decision boundaries. So here is a set of instruction which says as the passage directly answer the question.

[05:50] Now there are two different criterias. So one is the specific answer the question asks for and false is share words or topics but does not answer it. So it’s not just true false. You can actually find the specific criteria you want. And just to show you how it works. So here I have a dictionary with multiple uh different keys. So for example, a direct answer would look something like this. Refunds are issued to the original payment method within 14 days. Right? And then there could be

[06:22] another example which overlaps with the uh topic but doesn’t really answer it. There might be another one where we have keyword based matches, right? And then something which is completely off and unrelated. Now if we run all of those four queries through our null criteria, Jude actually assigns the highest probability to do the direct answer. And for the other the ones, you can actually see that the confidence is really low. Right? So this can be used as a classifier. you can define a threshold

[06:54] uh on which you accept the answer below which you discard it. Okay. So before showing you my experiments I actually ran some ideas to see whether we can run multiple concurrent questions through this system and it seems like it’s actually great at concurrency. So for example, if you were to run multiple questions serially, in this case we are looking at 17 different decisions per second, you would get about 40 seconds if you run

[07:26] those sequentially. However, uh if you just use their 64 pools that it offers, you can get all of the decisions within 7.6 seconds, which is incredible. Okay, in the rest of the video we’re going to use Juul as a reanker and I want to directly do a comparison with cross encoder then LLM as a reanker and jewel and see how effective it can be. Now in this case we are specifically providing it a criteria based on which it needs to

[07:57] rank them and there are two different criterias. So the first one is let’s say a policy called authoritative version two and we’re going to be using the null primitive which means there are two different options and then there’s a second one which is fast workaround which is not as strict as the authoritative one. Now the main takeaway is that based on the criteria that you define the ranking of the documents that you’re going to get out of Juul is going

[08:27] to be very different. So the criteria or the in steerable instructions that you provide here can really impact what type of ranking you get from the documents and this is the beauty because you can actually steer your reanker with this. Now traditionally we use cross encoders for reanking where you provide pair of question and the document or chunk right but it doesn’t really have the ability to follow any instructions. So it’s kind

[08:58] of frozen in time. Okay. But you might be thinking there’s this second option where you can use LLM as a reanker which can actually follow instructions. You can tell it exactly what the criteria should be for ranking and that’s actually true. However, this is going to cost you a lot and it’s usually a lot slower. Now to show you an example, I ran the same prompt and query through Jev, Gemini flashlight and Gemini flesh. The cost is extremely high compared and

[09:31] the most interesting thing is that the cost actually depends on how big the chunk size is. So for relatively small chunk size, both the uh feed and cost of Jev are very close to flashlight. However, as you increase the uh size, you start seeing cost pretty much remain like linearly incre. However, the biggest difference is when you start increasing the chunk size. This is where it actually shines. Okay. Now, one more thing um the

[10:03] accuracy of the final response is really dependent on the accuracy of retrieval. So, in this case, I created a baseline which uses BM5 full text search. Um a set of queries that you can actually see the baseline accuracy is only 21%. But if you add Jev as a reranker, it pushes it up to 54%. And this is the top one accuracy we’re talking about. Right? So usually you are going to have uh say 10 or 20 different chunks and you compute

[10:34] top K in which case this is going to be a lot more higher. Okay. So this was a quick example of how you can use a model like Jeff uh to replace different decision points in your existing workflows. Rag is a really good example of that and you can directly plug in Jeff as a drop-in replacement in your one workflows especially if you have to make decision at specific points. They don’t have to be Je’s binary decision.

[11:05] Um I’m thinking of creating more content on show you you how you can use Jev as a a part of your existing workflows. If there is any specific topic you’re interested in, do let me know. I’ll be happy to cover that in the upcoming videos. Anyways, I hope you found this video useful. Thanks for watching and as always, see you in the next one.