É viável injetar documentos de tamanho médio (por exemplo, até 100KB) no contexto de uma sessão de bot de Persona de IA do Discourse através do prompt do sistema?
CASO DE USO
Uma Persona de IA personalizada vinculada a um LLM privado como Llama3-8b em uma instância AWS onde o custo é por hora, não por token. Ou seja, o número de tokens de solicitação/resposta não importa e o servidor tem considerável poder CUDA, então o desempenho é bom. Ou seja, RAG poderia ser opcional?
(Caso de uso alternativo: LLM Gemini.1.5, onde não há cobrança por chamadas de API)
META
Reduzir as partes móveis no pipeline e melhorar a precisão, evitando a recuperação de similaridade.
EXPERIMENTO
Teste informal de Persona de IA com Gemini 1.5 Pro, onde um documento de texto de ~20k tokens foi inserido no prompt do sistema.
Fiz várias perguntas cujas respostas eu sabia que estavam apenas no artigo. Ele respondeu a todas as perguntas corretamente. Então, estou assumindo que ele leu os 20k tokens do prompt e os analisou para cada pergunta?
Em casos onde as sessões e o conteúdo do contexto não são muito grandes, há desvantagens nessa abordagem?
NOTA DE RODAPÉ - Remover contexto do prompt no meio da sessão
Quando excluí o conteúdo de injeção de prompt no meio da sessão e continuei a fazer perguntas, o Gemini continuou a responder corretamente, mas após várias perguntas ele não conseguiu encontrar o contexto e falhou. Como era um tanto esperado, o Gemini 1.5 pode manter o contexto em vários turnos de conversação em uma sessão, mas não indefinidamente.
Todos os pensamentos, comentários e orientações são apreciados!
Sim, temos lógica de truncamento que depende da quantidade de tokens que o llm permite, definimos o limite bem alto para os modelos gemini 1.5 (em 800k)
Deve funcionar, mas cada interação pode ser muito cara.
No geral, descobri que limitar o contexto ajuda os modelos a se manterem mais focados, mas a longo prazo (daqui a 2-5 anos)… o rag pode ser inútil e teremos tantos tokens e foco que não importará.
Apesar das minhas perguntas sobre prompt stuffing… Eu realmente amo RAG.
Na minha opinião, o trabalho que vocês estão fazendo com motores de embedding de primeira linha é poderoso e útil agora… mas também concordo que RAG… pode estar fadado ao fracasso.
Como Sam Altman disse em uma entrevista recente… cuidado com modelos de negócios e planos de projeto que atrapalham o LLM!! Nós vamos passar por cima de vocês! ..ou algo parecido..
Então, no final das contas… talvez queiramos apenas dar nossas coisas para o LLM sem muitos pipelines de pré-processamento que são de baixa dimensão (entrada) e depois de alta dimensão (embedding) e depois de baixa dimensão (prompting) e depois de alta dimensão (inferência do transformer) e depois de baixa dimensão (saída)… Bob é seu tio!
Aqui está um pouco de contexto sobre RAG versus contexto longo que acabei de encontrar… ainda não ouvi tudo, mas parece relevante talvez… (não sou afiliado a ninguém neste vídeo :-))
Eu consegui assistir a esse vídeo sobre o Llama3 de longo contexto Gradiente. Ele nos lembra que o contexto inclui tudo o que está em jogo.
Entrada do usuário
Saída do LLM
Tokens de controle
Instruções do sistema
… à medida que a janela desliza, as coisas ficam de fora. Mas eles mencionaram que pode haver uma “proteção” do prompt do sistema em sessões onde a janela de contexto está cheia.
Também existem as questões de “tamanho máximo de entrada” e o “comprimento da sequência” original em que o modelo foi treinado, que podem entrar na equação.
Abaixo está um exemplo de preenchimento de prompt de longo contexto em ação.
Em geral, parece viável criar uma equipe de personas de IA de Discurso, cada uma com um grande pedaço de conteúdo especializado ou base de código para consulta (tendo em mente a ressalva sobre o alto custo ao pagar por token!).
Concordo, com certeza. Nenhuma resposta simples na minha opinião.
Acho que isso depende do caso de uso.
RAG funciona bem para alguns aplicativos, mas para outros casos de destino bastante determinísticos (por exemplo, perguntas e respostas de clientes, pagamentos, médicos, etc.), eu e outros tivemos problemas para obter boa precisão com a pesquisa vetorial RAG no último ano. Ou seja, o bot deixará de lado coisas ou inventará coisas (baixa recuperação, baixa precisão em termos de IR), o que é bem documentado por Stanford, Google, etc.
Então surge a questão… por que jogar um monte de pedaços no LLM se você pode dar a ele todo o corpus. Pelo menos com injeção de contexto, quando o LLM não é preciso, você tem menos coisas para ajustar.
Ok, não vai funcionar para vastas bibliotecas de documentos/código… mas para bases de conteúdo pequenas e moderadas, parece funcionar muito bem até agora… estou trabalhando em um projeto que está testando formalmente isso! Mais em breve… obrigado.
PS. → Para tornar as coisas ainda mais interessantes… tive sorte com a injeção de contexto + ajuste fino… e há abordagens emergentes que combinam RAG e injeção de contexto! … Etc etc.
Aqui está um teste de Perguntas e Respostas com um white paper (~20k tokens) colocado em contexto via injeção de prompt vs RAG.. (conteúdo e configurações foram os mesmos o máximo possível. LLM = Gemini-1.5-Pro)..
ANÁLISE:
RAG é inconsistente.. às vezes encontrando a resposta, às vezes falhando.
Consegui fazer o RAG responder a perguntas do upload do arquivo no início do documento, e com persuasão, ele pode olhar o meio e o fim.. então não é uma falha total.. mas é inconsistente… consistentemente, ou mais difícil de trabalhar na minha opinião : )
Aqui está o arquivo de teste caso alguém queira brincar com ele:
O arquivo contém estas ‘agulhas’ do BME haystack que são garantidas como únicas, ou seja, não presentes em cópias externas do artigo na internet.
Início:
Revisor: Felonius Monko
Meio:
Nota do editor: A série de estabilidade de Goldich foi descoberta por Maurice Goldrch. Enquanto a ordem original de potencial de intemperismo mineral de Goldich era qualitativa, trabalhos posteriores de Michal Kowalski e J. Donald Rimstidt a colocaram em termos quantitativos. Graças ao Dr. Gomez Pyle da NMU por este esclarecimento.
Fim:
Dang, S. et al. Estruturas de Cryo-EM do canal de cloreto ativado por cálcio TMEM16A. Natureza 552, 426429 (2017).
Consegui reexecutar o teste acima com o GPT4o (contexto de 128k), certificando-me de usar configurações de token/chunk grandes. mas ainda é muito instável para o meu caso de uso de Q/A de white paper (perdido no meio, perdido no final, etc.). aqui estão minhas configurações, caso alguém queira duplicar e refinar. Adoraria se pudéssemos encontrar as configurações certas para este caso:
|PERSONA DE IA PERSONALIZADA||
|—|—||
|||
|Habilitado?|Sim|
|Prioridade|Sim|
|Permitir Chat|Sim|
|Permitir Menções|Sim|
|Visão Habilitada|Não||
|||
|Nome|Rag Testing Bot 3|
|Descrição|Testar RAG vs injeção de prompt de contexto longo|
|Modelo de Linguagem Padrão|GPT-4o-custom|
|Usuário| Rag_Testing_Bot_bot|
|Comandos Habilitados|Categorias, Ler, Resumo|
|Grupos Permitidos|trust_level_4||
|||
|Prompt do Sistema|Responda o mais abrangente possível a partir do contexto fornecido sobre Pesquisa de Remoção de Carbono Equatic no arquivo anexo. Não invente conteúdo. Não use conteúdo externo a esta sessão. Concentre-se no conteúdo fornecido e crie respostas a partir dele com a maior precisão e completude possível.|
|||
|Posts Máximos de Contexto|50|
|Temperatura|0.1|
|Top P|1||
|||
| ||
|Uploads| Equatics-paper1-with-unique-haystack-needles-v116.txt|
|||
|Tokens de Chunk de Upload|1024|
|Tokens de Sobreposição de Chunk de Upload|10|
|Chunks de Conversa de Pesquisa|10|
|Modelo de Linguagem para Consolidator de Perguntas|GPT-4o-custom||
|||
|BOT PERSONALIZADO||
|||
|Nome a exibir|GPT-4o-custom||
|||
|Nome do modelo|gpt-4o||
|||
|Serviço que hospeda o modelo|OpenAI|
|URL do serviço que hospeda o modelo|https://api.openai.com/v1/chat/completions|
|Chave de API do serviço que hospeda o modelo|D20230943sdf_fake_Qqxo2exWa91||
|||
|Tokenizador|OpenAITokenizer|
|Número de tokens para o prompt|30000|
Sucesso na injeção de prompt:
Falha no RAG:
