doc rag harness

Recuperação de documentos de geração aumentada (rag) arnês

A área de geração aumentada de recuperação está evoluindo rapidamente. Existem muitas maneiras diferentes de implementar a recuperação. Algumas pessoas usam bancos de dados de incorporação e vetor, outros usam gráficos semânticos. Portanto, existem designs diferentes e também existem tarefas diferentes e é importante corresponder a um design a uma tarefa ¹ .

O objetivo desse arnês para fornecer definições de coleta, abstrações e blocos de construção para ajudar na compreensão, benchmarking, comparação e selecionando um design de recuperação específico que melhor corresponde a uma tarefa em questão.

O arnês pretende ser um pouco semelhante a um kit de compatibilidade de tecnologia + tecnologia (TCK) - para fornecer:

• Java/EMF Ecore Modelo/API para armazenamento e recuperação de documentos, incluindo "interface do provedor de design" a ser implementada por projetos de candidatos
• Estrutura de teste para avaliar como diferentes projetos executam uma tarefa específica.

Java foi selecionado como uma tecnologia dominante no mundo corporativo, com rico poder expressivo do idioma e um grande ecossistema maduro. O EMF Ecore foi selecionado porque existem recursos:

• Carregar/armazenar modelos de/para YAML, XMI e arquivos binários, bem como bancos de dados
• Gerar documentação HTML a partir de modelos e metamodelos
• Suporte de ferramentas para construir espectadores e editores - árvore, diagrama, texto; Eclipse IDE e navegador da web

Esta página fornece uma introdução aos conceitos principais e descreve vários casos de uso (tarefas) e projetos (alternativas).

Conceitos

O diagrama abaixo descreve a estrutura e o contexto do arnês:

As seções a seguir fornecem definições e esboço das dimensões de tarefa/design para cada definição. O metamodelo captura algumas das definições como elementos do modelo e os elabora em recursos, operações e subclasses.

Documento

O documento é memorizado representação de pensamento ou informação. Para os propósitos deste chicote documentos:

• São armazenados em uma fonte/repositório de documentos (como livros em uma biblioteca)
• Pode ser categorizado e as categorias podem ser aninhadas (por exemplo, gênero de livro - ficção / ficção científica)
• Pode ter estrutura interna (por exemplo, volume, capítulo, seção, parágrafo, palavra)
• Pode conter diferentes tipos de conteúdo - texto, imagem, vídeo, áudio, estruturas como listas e tabelas
• Pode fazer referência a outros documentos ou entidades externas

Implementações "físicas":

• Arquivo de texto
• Pdf. Em java pode ser carregado usando o apache pdfbox
• OCR resulta em, digamos, JSON
• MS Documentos do Office - em Java, pode ser carregado com Apache Poi. Os arquivos MS Excel podem ser carregados como modelo Ecore com o modelo Nasdanika Excel
• Documentos/páginas HTML (subtipo de texto)

Implementações "lógicas":

• Para PDF/OCR - uma varredura de um documento comercial. Por exemplo, um fax de uma mensagem rápida. Nesse caso:
  • Cabeçalho e rodapé adicionados pelo fax podem ser removidos como irrelevantes
  • Os corpos da página podem ser analisados ​​em uma estrutura específica rápida, por exemplo, MT 700
  • As incorporações podem ser criadas para corpos ou parágrafos ou cláusulas para alguns elementos, os números de cláusula podem ser excluídos do texto. Um pouco semelhante aos artigos da Wikipedia, as incorporações, onde as incorporações são calculadas para passagens, excluindo cabeçalhos.
• Para HTML - uma página de documentação. Digamos que a linguagem de expressão da primavera (SPEL) neste cabeçalho de caso, navegação esquerda, barra lateral direita e rodapé podem ser descartados como não relevantes ou analisados ​​nos respectivos recursos de documentos lógicos que podem ser ignorados. A pavimentação pode ser usada para categorização.
• Para arquivos de texto - dependendo do tipo de conteúdo. Por exemplo, pom.xml pode ser carregado em um modelo de objeto de projeto, o arquivo Java pode ser carregado em uma árvore de sintaxe ou em um gráfico com referências de tipo/campo/método resolvidas.

Carregador de documentos

Converte uma representação de um documento para outra. Por exemplo, PDF ou OCR JSON para um modelo de objeto de uma mensagem Swift MT 700.

Fonte de documentos

Armazenamento de documentos em um formato ou formato específico. Por exemplo, um sistema de arquivos com documentos em PDF. As fontes de documentos podem ser convertidas/adaptadas. Um dos exemplos de fonte de documentos é um commit git. O modelo Nasdanika GitLab pode ser usado para implementar o carregamento de documentos do GitLab.

Repositório de documentos

Uma coleção de documentos que fornecem funcionalidade de armazenamento e recuperação. A interface principal do DPI (veja abaixo) a ser implementada por projetos.

Ao armazenar um documento, o repositório pode executar tarefas como reconhecimento de imagem.

Pode haver várias modalidades de recuperação, como:

• Pesquisa de palavras -chave
• Pesquisa semântica
• Resumo - Pesquisar e resumir os resultados principais X

Os repositórios podem ser montados em outros repositórios e carregadores de dados. Por exemplo, um repositório PDF pode ser montado a partir de um carregador de dados do modelo de objeto PDF -> e um repositório de modelo de objeto. Além disso, os repositórios de documentos podem não precisar armazenar/recriar o documento de origem - eles podem fazer referência e recuperar um armazenamento de documentos - o original do qual o documento foi carregado ou de um armazenamento de documentos específico do repositório.

Também pode ser possível compor diferentes projetos de repositórios. Por exemplo, um repositório que suporta pesquisa de palavras -chave e um repositório que suporta pesquisa semântica. Nesse caso, os resultados da consulta do repositório de pesquisa de palavras -chave seriam necessárias, mas não suficientes e podem ser usadas para validar os resultados do repositório de pesquisa semântica.

Usuário / interface da web

Os usuários consultam um repositório de documentos por meio da interface do usuário da web. Eles podem fazer isso como parte de sua função de trabalho ou avaliar a funcionalidade de consulta de um design específico e fornecer feedback. Essas duas modalidades podem ser combinadas - os usuários podem optar por usar apenas o mecanismo/design de consulta "Champion", por exemplo, pesquisa de palavras -chave ou também selecionar motores/designs "Challenger".

A interface do usuário da web pode capturar o contexto do usuário, como função/posição na organização e passá -lo para o design como parte de uma consulta.

Patrocinador

Uma parte interessada em melhorar as qualidades do trabalho do usuário, como a produtividade, utilizando a geração aumentada de recuperação de documentos.

Os patrocinadores precisam equilibrar vários critérios para minimizar a "função de perda":

• Velocidade de recuperação
• Precisão
• Integridade
• Custos como custos de operação, custos de licença etc.

Projeto

O design é uma instanciação/incorporação das tecnologias e seus parâmetros de configuração.

Dimensões de design

Pontos de variação de design - o que pode ser alterado em diferentes modalidades/instanciações e fonte de valores. Por exemplo:

• Número de dimensões de incorporação
• Modelo ML
• Temperatura do modelo
• Banco de dados vetorial
• Versão do banco de dados vetorial

As dimensões do design podem formar uma árvore ou, mais precisamente, um gráfico direcionado. Por exemplo, as versões do banco de dados vetoriais seriam nós em um nó para um banco de dados vetorial específico.

Interface do provedor de design

A interface do provedor de design (DPI) abstrairá o chicote de uma implementação específica do design. É um conjunto de interfaces e classes abstratas que o design deve implementar. Por exemplo, interface DocumentRepository . O DPI é definido em Java/Ecore e pode fornecer adaptadores para diferentes tecnologias. Em particular:

• Rest API
• Ligantes do idioma e um corredor que implementa a API REST e chama componentes que implementam a interface de ligação ao idioma. Por exemplo, uma ligação do Python pode ser implementada com o frasco
• Ligantes/implementações da estrutura em ligações de idiomas ou diretamente sob o DPI em Java. Por exemplo, sob a ligação do Python, pode haver uma ligação de Langchain e, sob Java, pode haver uma ligação aberta

Tarefa

A tarefa é um uso específico da recuperação de documentos. Por exemplo, pesquisa semântica na documentação técnica específica da Organização "Como implanto um microsserviço de primavera no AKS?".

Conjunto de dados de teste

Uma coleção de documentos de teste, consultas e avaliadores de respostas.

Entradas do corredor

Uma coleção de combinações de conjunto de dados de teste / design a serem executadas pelo Test Runner.

Test Runner

• Lê entradas
• Instancia conjuntos e projetos de dados de teste
• Carrega documentos de um conjunto de dados de teste em um design
• Executa consultas e avalia respostas. Os avaliadores de resposta podem fornecer feedback ao design
• Armazenamento Resultados dos testes para análise posterior e geração de relatórios

O corredor de teste pode executar apenas partes das etapas acima, dependendo das entradas. Por exemplo:

• Já pode haver um design com documentos pré-carregados e o corredor de teste executará apenas a parte de consulta
• Ou o conjunto de dados de teste pode conter apenas documentos, mas não consultas e avaliadores de resposta, porque consultas e respostas devem ser fornecidas pelos usuários através da interface da web
• O Test Runner pode carregar documentos no design e salvá -lo como um novo design. Por exemplo, crie um contêiner a partir de uma imagem, carregue documentos e pare o contêiner e crie uma imagem do contêiner.
• Da mesma forma, o corredor de teste pode levar um conjunto de dados de teste, combiná -lo com o usuário fornecido feedback e criar e criar um novo conjunto de dados de teste.

As execuções de teste podem ser distribuídas por vários agentes/máquinas.

Resultados do teste e feedback do usuário

Armazenamento dos resultados dos testes e feedback do usuário. Os resultados dos testes e o feedback do usuário devem fazer referência a conjuntos e projetos de dados de teste. Como tal, é essencialmente um repositório de metadados de arnês que contém árvores/gráficos de definição de projeto, definições de conjunto de dados de teste e resultados das execuções de teste.

Gerador de relatório

Gera um relatório. O relatório pode estar em formato HTML com visualizações. Um possível formato de relatório:

• Painel esquerdo com a árvore dos projetos, a árvore das tarefas e os conjuntos de dados de teste para tarefas. Também pode incluir uma "Tree Tech Stack" - Blocos de construção de design categorizados. Por exemplo, uma árvore de bancos de dados de vetores, suas versões e configurações. Se o painel esquerdo ficar muito barulhento, alguns dos itens poderão ser movidos para a barra de navegação.
• Painel de conteúdo - documentação para o item selecionado. Por exemplo
  • Página inicial - Um resumo dos testes executados: tabela classificável filtrável com permutações de design/teste (para espaços relativamente pequenos), visualizações, por exemplo, eCHarts 3D Scatter. Ele também pode conter um assistente de design para criar designs, respondendo a perguntas e selecionando um design testado que melhor se encaixa nas respostas.
  • Página de design - Configuração, testes e resultados - Tabela, visualizações
  • Página de tarefas - Descrição, testes, designs, visualizações. Ele pode hospedar uma interface da web de agregação que coleta respostas de todos os designs para esta tarefa e permite que os usuários comparem respostas de designs alternativos. Uma opção para comparar é a comparação em pares, possivelmente sem se revelar de qual design uma determinada resposta vem.
  • Bloco de construção (por exemplo, banco de dados vetorial, versão, configuração) - Descrição, projetos que o usam.

O relatório pode conter links para a interface do usuário da web ou até mesmo "hospedar" a interface da web se for implementada como um aplicativo de página única (spa) com, digamos, react ou vue.js/bootstrapvue

Comunidade

Partes contribuindo para os conjuntos de dados de arnês, desenhos e dados de teste. Os membros da comunidade podem desempenhar papéis diferentes em diferentes componentes.

--- trabalho em andamento ---

Tarefas

Esta seção descreve várias tarefas (casos de uso) para geração aumentada de recuperação e pesquisa em geral.

Dimensões:

• Número de documentos
• Número de usuários
• Frequência de alterações
• Privacidade
• Risco - custo de erro

Documentação técnica

Exemplo - Função de tecnologia em uma grande empresa:

• Vários níveis:
  • Corporativo, vincula as opções de tecnologia em toda a empresa (por exemplo, Java/Spring, componentes Maven), fornece blocos de construção compartilhados em toda a empresa (por exemplo, uma biblioteca de componentes de bootstrap) e outras tecnologias (por exemplo, um pipeline de construção)
  • Segmento - estreita as opções de tecnologia, por exemplo, a versão do Java, adicione maneiras específicas de segmento de fazer as coisas no topo das diretrizes corporativas (que, por sua vez, são construídas sobre as diretrizes e documentação de tecnologia do setor/fornecedor). Pode introduzir blocos de construção no nível do segmento.
  • Capacidade/equipe - estreita ainda mais as escolhas da tecnologia e refina como elas são usadas. Pode introduzir blocos de construção de capacidade/equipe, como bibliotecas de widgets.

Para cada um dos itens acima, há uma dimensão de tempo - atualizações de pilha de tecnologia na parte superior, lançamentos na parte inferior. Veja o cenário da arquitetura TOGAF para uma visualização.

Nesse meio ambiente, os usuários precisam de uma solução de recuperação que permita recuperar documentos específicos para a posição e a função do usuário na empresa e o esforço para o qual são atribuídos. Por exemplo, um desenvolvedor de Java trabalhando, digamos que a liberação atual pode precisar de informações sobre o Java 17. Se o mesmo desenvolvedor for designado para trabalhar na versão futura, eles podem precisar de informações, digamos, Java 20. Quando trabalham com tecnologias como Kubernetes e Azure Aks, a documentação do fornecedor pode ser um pouco considerável e causar uma confusão por que o Azure contém o que a documentação do fornecedor pode ser um dos que se conhecem em geral, o que se sabe como se o que é o que se une a seriedade, mas a documentação do fornecedor é que a documentação do fornecedor é que a Kubernetes e a que contém o que é um dos que se conhecem, mas a documentação do fornecedor é que a documentação do fornecedor é que a Kubernetes e o que contém o que é o que se diz que é o que se diz que é o que se diz que é o que se diz que é um dos que se conhecem, mas a documentação do fornecedor.

• Número de documentos: dezenas de milhares
• Número de usuários: centenas a milhares
• Frequência de mudanças: Baixo (por exemplo, mensalmente) a moderado (várias vezes por mês)
• Privacidade: interno
• Risco: Baixo

Procedimentos

Dimensões:

• Número de documentos: baixo milhares
• Número de usuários: centenas a milhares
• Frequência de mudanças: Baixo (por exemplo, mensalmente)
• Privacidade: interno, restrito, confidencial
• Risco: médio a alto

Documentos operacionais

Dimensões:

• Número de documentos: possivelmente milhões
• Número de usuários: centenas a milhares
• Frequência de mudanças: Alto (diário)
• Privacidade: Confidencial, Informações Pessoais - PII, PHI, PCI
• Risco: alto

Desenhos

Incorporações, bancos de dados de vetores, LLM's

PENDÊNCIA. De acordo com as informações do setor, visam um número muito grande de documentos - corresponde aos documentos operacionais que usam caso

Gráficos

PENDÊNCIA. Pode ser melhor para um número menor de documentos (procedimentos) - todos eles podem se encaixar na memória e as pesquisas podem ser executadas em gráficos semânticos. No caso do banco de dados vetorial, uma maneira de construir índices é usar gráficos - Hierárquica Small World (HNSW)

Gráficos polimórficos

PENDÊNCIA. Pode ser uma boa opção para o caso de uso da documentação técnica:

• A empresa cria um gráfico de conhecimento (modelo) para as opções de tecnologia corporativa. Pode haver vários modelos - linha de base, lançamentos futuros
• Os segmentos tomam os gráficos/modelos corporativos e personalizam - o conceito semelhante à herança em idiomas orientados a objetos, como Java e também semelhante às camadas no docker
• Recursos/equipes podem levar mais longe

Esse processo resultará em um grande número (centenas) de gráficos/modelos relativamente pequenos (bases de conhecimento) com dezenas de milhares de documentos.

Notas de rodapé

1. Espaço de design para redes neurais gráficas, parte da palestra de Stanford CS224W: ML com gráficos, slides ↩