Knowledge Storage overview - Tablestore: Central de Documentação do Alibaba Cloud

O que é o Knowledge Storage service?

O Knowledge Storage service é um service RAG serverless totalmente gerenciado, criado sobre o Alibaba Cloud Tablestore. Você não precisa implantar ou manter servidores físicos ou infraestrutura.

Após importar documentos por meio do console, de um kit de desenvolvimento de software (SDK) ou da interface de linha de comando (CLI), o sistema os analisa e os divide em Chunks automaticamente, vetoriza-os e cria índices. Durante a recuperação, o service executa uma recuperação híbrida e retorna os Chunks relevantes.

Todos os dados são armazenados no Object Storage Service (OSS) e nos recursos do Tablestore na sua conta. O service não retém nem copia seus dados. Armazenamento e computação são separados e faturados de forma independente. Em um fluxo de trabalho típico de aplicação de IA, o Knowledge Storage service fornece gerenciamento e recuperação de conhecimento.

Para informações de faturamento sobre o Knowledge Storage service, consulte Product Billing. Para testar rapidamente o Knowledge Storage service, consulte Build your first knowledge base.

O Knowledge Storage service está disponível nas seguintes regiões: China (Beijing), China (Shanghai), China (Hangzhou), China (Shenzhen), China (Hong Kong) e Singapore. Selecione a região mais próxima para acesso.

Recursos e benefícios

Serverless e elasticidade — A arquitetura serverless totalmente gerenciada utiliza faturamento de pagamento conforme o uso, sem cobrança mínima. Armazenamento e computação são faturados de forma independente. Uma única base de conhecimento suporta até 10 milhões de documentos por padrão. Criado sobre a arquitetura distribuída do Tablestore, o service dimensiona conforme o seu negócio. Para limites específicos, consulte Quotas and limits.
Pipeline de base de conhecimento totalmente gerenciado — Após o upload de um documento, o sistema conclui automaticamente a análise do documento, a divisão em Chunks, o embedding, a criação de índices e todo o outro processamento. O service suporta formatos de documento comuns, incluindo PDF, Word (doc/docx), Excel (xls/xlsx), PowerPoint (ppt/pptx), texto simples (txt) e Markdown (md). Você não precisa criar um pipeline de processamento de documentos, gerenciar a implantação e a operação do modelo de embedding, ou criar e manter manualmente índices vetoriais. O service gerencia automaticamente todo o ciclo de vida da base de conhecimento.
Propriedade dos dados e controle total — Todos os dados brutos, intermediários e de resultado no processo são armazenados na sua própria conta de service de cloud, em um bucket do OSS ou em uma instância do Tablestore. O service não retém nem copia seus dados. Essa arquitetura mantém a propriedade e a segurança dos dados totalmente sob o seu controle e atende aos rigorosos requisitos de conformidade de dados de setores como finanças, governo e saúde.
Personalização flexível e recuperação precisa — O service suporta recuperação híbrida de canal duplo com recuperação vetorial e recuperação de texto completo (similaridade semântica + correspondência exata de palavras-chave). Ele fornece três estratégias de reclassificação (RRF, WEIGHT e MODEL) que você pode selecionar com base no seu cenário. Você pode controlar com precisão os módulos principais por meio de APIs e parâmetros, desde a seleção do modelo de embedding (Model Studio integrado ou personalizado), a configuração da estratégia de recuperação e as condições de filtragem de metadados até o gerenciamento de conteúdo no nível de Chunk.

Cenários típicos de aplicação

Cenário	Descrição
Sistema de perguntas e respostas com conhecimento empresarial	Importe documentação interna de product, manuais técnicos, FAQs, políticas e outros materiais para uma base de conhecimento e combine-os com um LLM para criar um sistema inteligente de perguntas e respostas. Quando um funcionário ou cliente faz uma pergunta, o sistema recupera os Chunks de conteúdo mais relevantes da base de conhecimento e os passa para o LLM gerar respostas precisas e rastreáveis. Isso se aplica a departamentos de atendimento ao cliente, RH, jurídico, operações de TI e outros.
Busca e resumo inteligente de documentos	Substitua um mecanismo de busca tradicional por palavras-chave por uma recuperação vetorial que compreende a intenção de busca do usuário e retorna os Chunks de documentos semanticamente mais relevantes. Combine isso com filtragem de metadados por tempo, categoria, autor e outras dimensões para fornecer uma recuperação precisa de documentos.
Base de conhecimento para Software como Service (SaaS) multilocatário	Use o Subspace para isolar dados de diferentes locatários, como usuários, departamentos e clientes, dentro da mesma base de conhecimento. Cada locatário pode recuperar apenas documentos em seu próprio Subspace, o que fornece isolamento de dados inerente sem a necessidade de uma base de conhecimento separada para cada locatário. Isso reduz significativamente a complexidade e o custo de gerenciamento.
Integração de pipeline RAG	Use o Knowledge Storage service como a camada de recuperação em uma arquitetura RAG e integre-o com frameworks de IA convencionais, como LangChain e LlamaIndex. Ingera documentos em uma base de conhecimento, chame a API Retrieve durante a inferência para obter o contexto relevante, anexe-o ao prompt e envie-o para o LLM para permitir a geração aprimorada por conhecimento.
Gerenciamento e auditoria de documentos de conformidade	Use este service para o gerenciamento de documentos de conformidade em setores como finanças, saúde e governo. Todos os dados são armazenados na sua própria conta de cloud para atender aos requisitos de conformidade de residência de dados. Use o campo `metadata` para rotular atributos do documento, como categoria, versão e período de validade, e combine-o com a filtragem de metadados para fornecer uma recuperação precisa de documentos de conformidade.

A análise de documentos, a divisão em Chunks e a criação de índices após a importação são assíncronas e concluídas automaticamente pelo sistema. Avalie cuidadosamente se o Knowledge Storage service é adequado para cenários que exigem processamento em tempo real ou estratégias de divisão em Chunks estritamente personalizadas.
Para consultas de dados puramente estruturados, recomendamos o modelo de coluna larga ou um banco de dados relacional. Para indexação de dados de streaming em tempo real, recomendamos o uso direto de um índice de busca do Tablestore.

Glossário

Os dados em uma base de conhecimento são organizados em quatro níveis de entidade:

Entidade	Descrição
KnowledgeBase	Uma base de conhecimento. Cada base de conhecimento corresponde a dados de documento, Chunk e índice.
Document	Um registro associado a um arquivo do OSS que captura o status e os metadados do documento.
Chunk	Um segmento de documento que armazena dados vetoriais e o texto original. É a menor unidade de recuperação.
Index	Um índice vetorial e de texto completo gerenciado pelo service, usado para recuperar Chunks candidatos.

O sistema cria automaticamente as tabelas de dados correspondentes no Tablestore. Nos nomes das tabelas a seguir, os espaços reservados representam o nome e o ID da base de conhecimento:

Tabela de documentos: {knowledge_base_name}_{knowledge_base_id}
Tabela de Chunks: {knowledge_base_name}_{knowledge_base_id}_chunk
Tabela de índices: {knowledge_base_name}_{knowledge_base_id}_index

Configuração da source de dados da base de conhecimento

A source de dados para uma base de conhecimento é o Alibaba Cloud Object Storage Service (OSS). Independentemente de como os documentos são carregados, seus dados brutos são armazenados no seu próprio bucket do OSS.

Uma base de conhecimento precisa de acesso de leitura e gravação ao bucket do OSS: ela lê os documentos de source para análise e divisão em Chunks, e grava os resultados intermediários da análise de volta no OSS.

Você pode importar documentos para uma base de conhecimento das três maneiras a seguir:

Upload de arquivos locais — Especifique um arquivo ou diretório local. O SDK faz o upload automaticamente para o OSS e, em seguida, o adiciona à base de conhecimento. Se você especificar um diretório, o SDK percorre recursivamente todos os arquivos.
Adição de arquivos do OSS — Se um arquivo já estiver no OSS, especifique seu caminho do OSS para adicioná-lo diretamente à base de conhecimento sem fazer o upload.
Importação em massa de um diretório do OSS — Especifique um caminho de diretório do OSS. O sistema verifica automaticamente todos os arquivos no diretório de forma recursiva. Você pode usar inclusionFilters e exclusionFilters para filtrar arquivos por padrão de nome.

Para detalhes sobre cada método, consulte Document management.

Configuração de embedding da base de conhecimento

A configuração de embedding determina como os Chunks do documento são vetorizados e é especificada ao criar uma base de conhecimento.

Não modifique a configuração de embedding após criar uma base de conhecimento. Para alterar o modelo ou a dimensão, exclua e crie a base de conhecimento novamente. Avalie totalmente a seleção do modelo antes de criar a base de conhecimento.

Item de configuração	Descrição
`provider`	Provedor do modelo: `bailian` (Model Studio integrado) ou `custom` (personalizado).
`model`	Nome do modelo. O Model Studio suporta `text-embedding-v3` e `text-embedding-v4`.
`dimension`	Dimensão do vetor. Por exemplo, o `text-embedding-v4` possui 1.024 dimensões.
`url`	Necessário apenas no modo `custom`. Entre em contato com o Tablestore com antecedência para registrar uma URL válida.
`apiKey`	Necessário apenas no modo `custom`.

Se embeddingConfiguration não for especificado, o sistema usa o modelo text-embedding-v4 do Model Studio integrado com 1.024 dimensões por padrão. É adequado para a maioria dos cenários.

Recomendações de seleção

Para cenários gerais em chinês e inglês, recomendamos o text-embedding-v4 com 1.024 dimensões. Ele oferece um bom equilíbrio entre compreensão semântica e desempenho.
Para integrar um service de embedding próprio ou de terceiros existente, use o modo custom para manter sua pilha de tecnologia consistente.
Dimensões maiores fornecem uma representação semântica mais rica, mas também aumentam os custos de armazenamento e computação. Para a maioria dos cenários, recomendamos 1.024 dimensões.

Configuração da estratégia de recuperação da base de conhecimento

Ao chamar a API Retrieve, a configuração de recuperação (retrievalConfiguration) é determinada na seguinte ordem de prioridade:

Prioridade	Source	Descrição
1 (mais alta)	Parâmetros da API Retrieve	A configuração passada na solicitação atual entra em vigor apenas para essa solicitação.
2	Configuração no nível da base de conhecimento	Definida quando a base de conhecimento é criada, e você pode modificá-la usando UpdateKnowledgeBase.
3 (mais baixa)	Padrão do sistema	Recuperação híbrida vetorial e de texto completo com fusão ponderada `WEIGHT` (vetor 0,7 : texto completo 0,3).

Tipos de recuperação

Tipo	Descrição	Cenário aplicável
`DENSE_VECTOR`	Recuperação vetorial baseada em similaridade semântica.	Descreva requisitos em linguagem natural quando a compreensão semântica for necessária.
`FULL_TEXT`	Recuperação de texto completo baseada em correspondência exata de palavras-chave.	Insira palavras-chave exatas, nomes próprios ou ID.

Ative ambos os tipos de recuperação e combine seus resultados por meio do mecanismo de reclassificação.

Estratégias de reclassificação

Tipo	Descrição	Cenário aplicável
`RRF`	Fusão de classificação recíproca ponderada sem chamadas de modelo adicionais.	Cenários gerais com baixa latência.
`WEIGHT`	Pondera as pontuações de recuperação vetorial e de texto completo por uma proporção especificada.	É necessário um controle refinado sobre a contribuição dos dois canais de recuperação.
`MODEL`	Chama um modelo Rerank para reordenar os resultados candidatos.	É necessária uma alta qualidade de classificação e uma latência adicional é aceitável.

Para obter detalhes sobre a configuração da estratégia de recuperação e métodos de ajuste, consulte Retrieval and Ranking.

Gerenciamento multilocatário

O Subspace é uma partição de isolamento de dados dentro de uma base de conhecimento. Use-o para isolar dados por usuário, departamento ou locatário dentro da mesma base de conhecimento. Defina "subspace": true ao criar uma base de conhecimento para ativá-lo.

Regras principais:

Não modifique a opção do Subspace após criar uma base de conhecimento.
Após ativar o Subspace, especifique o campo subspace em todas as operações de documento (adição, consulta, exclusão e listagem) e de recuperação. Caso contrário, o sistema retornará um erro.
O Retrieve suporta a consulta de vários Subspaces ao mesmo tempo, passando uma lista de até 32 Subspaces.
Um nome de Subspace pode ter até 128 bytes de comprimento.

Em um ambiente empresarial, cada funcionário no mesmo departamento possui seus próprios documentos. O administrador do departamento cria uma base de conhecimento com o Subspace ativado e atribui um Subspace independente a cada funcionário, como employee_zhangsan e employee_lisi. Os documentos de cada funcionário são invisíveis para os outros, enquanto o administrador gerencia centralmente a configuração da base de conhecimento. Para recuperar dados entre funcionários, passe vários Subspaces para o Retrieve para uma recuperação conjunta.

Subspace e múltiplas bases de conhecimento

Dimensão	Subspace	Múltiplas bases de conhecimento
Granularidade de isolamento	Partições lógicas dentro da mesma base de conhecimento	Bases de conhecimento completamente independentes
Configuração de embedding	Configuração compartilhada	Cada base de conhecimento possui uma configuração independente
Escopo de recuperação	A recuperação conjunta entre Subspaces é suportada	A recuperação é limitada a uma única base de conhecimento
Custo de gerenciamento	Baixo: uma base de conhecimento gerencia todos os locatários	Alto: é necessário gerenciar múltiplas bases de conhecimento
Cenário aplicável	Isolamento de dados multilocatário para dados homogêneos	Diferentes domínios de negócios e requisitos de embedding