O que é o txtai?
txtai é um framework Python de código aberto (licença Apache 2.0, github.com/neuml/txtai) para busca semântica, orquestração de LLM e workflows de modelos de linguagem, construído e mantido pela NeuML. Seu componente central é um banco de dados de embeddings — descrito na própria documentação como uma união de índices vetoriais (densos e esparsos), redes de grafos e bancos de dados relacionais em um único objeto.
- Busca vetorial: embeddings densos e esparsos, filtragem SQL, modelagem de tópicos, análise de grafos e indexação multimodal (texto, documentos, áudio, imagens, vídeo) em um único índice
- Pipelines: wrappers prontos em torno de modelos de linguagem para perguntas e respostas, resumo, tradução, transcrição e rotulagem de texto
- Workflows: encadeiam vários pipelines em um único job de processamento, de um script simples de dois passos a um processo em lote multimodelo
- Agentes: agentes autônomos que combinam embeddings, pipelines e workflows para resolver tarefas de vários passos, construídos sobre o framework smolagents
- APIs e bindings: um serviço REST/FastAPI mais um servidor Model Context Protocol (MCP), com bindings de cliente para JavaScript, Java, Rust e Go
- Mais de 70 notebooks de exemplo cobrindo o framework de ponta a ponta, mantidos junto com a biblioteca principal
Como funciona a arquitetura embutida do txtai?
O objeto Embeddings do txtai mantém o índice vetorial e o armazenamento de metadados diretamente dentro do processo Python, persistindo ambos em arquivos locais em vez de se comunicar com um serviço de banco de dados separado. Por padrão, o índice vetorial usa Faiss e os metadados de conteúdo ficam em um arquivo SQLite local — o mesmo modelo de "embutido no processo da aplicação" que o próprio SQLite usa, ao contrário do modelo cliente/servidor do PostgreSQL.
- Backend ANN (configuração
backend): Faiss por padrão; HNSW, Annoy e pgvector são suportados como alternativas intercambiáveis sem alterar o restante do código - Armazenamento de conteúdo (configuração
content): SQLite por padrão quando habilitado; suporta DuckDB ou um banco de dados cliente/servidor via URL de conexão para equipes que ultrapassam um único arquivo - Armazenamento de objetos: armazenamento binário opcional para imagens ou objetos serializados (pickle) arbitrários, sobre o mesmo índice de embeddings
- Persistência:
embeddings.save(path)grava o índice e o banco em disco como um diretório portátil;embeddings.load(path)o reabre em um novo processo sem etapa de importação/exportação - Nenhum processo servidor para iniciar, monitorar ou corrigir — o índice vive e morre com o próprio processo da aplicação, assim como um cache em memória ou baseado em arquivo
Em que o txtai é diferente de um banco de dados vetorial independente?
Chroma, Qdrant, Weaviate e Milvus normalmente rodam como serviço próprio — um contêiner ou endpoint gerenciado ao qual sua aplicação se conecta pela rede. O txtai, em vez disso, roda dentro do processo que o chama, de forma parecida com a diferença entre SQLite e PostgreSQL: sem string de conexão, sem processo separado para manter vivo, sem salto de rede entre o código e o índice.
O que se ganha ao embutir o banco de dados
Zero infraestrutura para provisionar — sem contêiner Docker, sem endpoint gerenciado na nuvem, sem pool de conexões. Implantar é copiar um diretório. Para aplicações de nó único, ferramentas de linha de comando, apps desktop ou protótipos, isso remove toda uma superfície operacional (disponibilidade, autenticação, latência de rede) que um banco de dados vetorial independente introduz mesmo em pequena escala.
O que se abre mão em troca
Um serviço de banco de dados vetorial independente pode ser consultado simultaneamente por muitos processos independentes, escalado horizontalmente entre máquinas e gerenciado com ferramentas de operações dedicadas (backups, réplicas, controle de acesso) separadas do ciclo de vida de qualquer aplicação específica. Um índice embutido fica restrito ao processo que o abriu — gravações concorrentes de múltiplos processos não são o caso de uso padrão, e coleções muito grandes que precisam ser distribuídas entre nós superam o que um índice de arquivo único comporta.
📌Nota: O Chroma também oferece um modo embutido para prototipagem, mas seu caminho de produção é um servidor. O txtai não tem um modo de produção separado para o qual evoluir — embutido é a única arquitetura que ele oferece.
O txtai suporta RAG e agentes de IA?
Sim — geração aumentada por recuperação (RAG) e agentes autônomos são casos de uso centrais no txtai, não recursos anexados a um armazenamento vetorial.
- RAG: o pipeline
RAGcombina um índiceEmbeddingscom um LLM, recupera trechos relevantes para uma consulta e gera uma resposta com citações às fontes — a própria documentação do txtai descreve o RAG como "mais do que busca vetorial", também cobrindo recuperação de contexto de web e SQL - Agentes: construídos sobre o framework smolagents da Hugging Face, os agentes do txtai conectam embeddings, pipelines, workflows e outros agentes para resolver tarefas de vários passos de forma autônoma; o prompting de agentes via arquivos
agents.mdeskill.mdé suportado - Workflows: os pipelines se encadeiam em jobs lineares ou ramificados — por exemplo, extrair texto, dividi-lo em blocos, gerar embeddings e depois resumir cada bloco — sem escrever manualmente o código de ligação
- Grafos de conhecimento: a extração de entidades guiada por LLM pode construir um grafo semântico sobre um índice de embeddings, somando análise de relações à busca por similaridade simples
Quais LLMs funcionam com o txtai?
O txtai suporta modelos locais e modelos baseados em API pelas mesmas interfaces de pipeline LLM e RAG — alternar entre eles é uma mudança de configuração, não uma reescrita de código.
Caminho | Tipo | Nota |
|---|---|---|
| Hugging Face Transformers | Local | Qualquer LLM causal do Hugging Face Hub ou um caminho local |
| llama.cpp | Local | Modelos quantizados em formato GGUF, CPU ou GPU |
| Ollama | Local | Aponta para um servidor Ollama em execução |
| vLLM | Local / autogerenciado | Servidor de inferência de alto throughput para produção |
| LiteLLM | API | Roteia para OpenAI, Anthropic Claude, AWS Bedrock e outros |
O exemplo de início rápido de RAG do txtai carrega um modelo Hugging Face pelo caminho (por exemplo, Qwen/Qwen3-0.6B) diretamente no pipeline RAG junto ao índice de embeddings — nenhum servidor de LLM separado é necessário, a menos que se opte por rodar um por motivos de throughput.
Como configurar o txtai?
Ter um índice de busca semântica funcionando leva um pip install e algumas linhas de Python — não há contêiner para configurar antes.
- 1Instalar Python 3.10 ou posterior, depois o pacote:
pip install txtai. Use `pip install "txtai[pipeline-data]"` se também precisar de extração de documentos (PDF, DOCX, HTML) para RAG. - 2Criar um índice de embeddings em um script Python:
import txtai, depoisembeddings = txtai.Embeddings(). - 3Indexar uma lista de documentos: `embeddings.index(["Correct", "Not what we hoped"])
. Cada chamada adiciona texto (ou tuplas(id, text)` para conjuntos maiores) ao índice em disco. - 4Executar uma busca semântica:
embeddings.search("positive", 1)retorna as correspondências mais próximas por significado, não por sobreposição de palavras-chave. - 5Persistir o índice para reutilização:
embeddings.save("index_path")grava em disco; reabrir depois comembeddings.load("index_path")— sem necessidade de reindexar entre execuções. - 6Para uma API web em vez de um script embutido: definir um
app.ymlmínimo com um modeloembeddings.path, depois servir:CONFIG=app.yml uvicorn "txtai.api:app"e consultar via HTTP comcurl.
import txtai
# Criar um índice de embeddings (Faiss + armazenamento local por padrão)
embeddings = txtai.Embeddings()
# Indexar texto — cada string vira uma entrada pesquisável
embeddings.index(["Correct", "Not what we hoped"])
# Busca semântica — encontra significado, não só palavras-chave
results = embeddings.search("positive", 1)
print(results) # [(0, 0.298...)] — o índice 0 ("Correct") é o mais próximo
# Persistir em disco para reutilização após reiniciar o processo
embeddings.save("index_path")O exemplo mínimo do txtai precisa de GPU?
Não. O modelo de embeddings padrão (sentence-transformers/all-MiniLM-L6-v2) e o backend ANN Faiss rodam ambos em CPU. Uma GPU acelera a geração de embeddings e a inferência de LLM em maior escala, mas não é necessária para seguir esta configuração.
Como adicionar geração aumentada por recuperação a esta configuração?
Passe o mesmo objeto Embeddings para um pipeline txtai.RAG junto a um LLM local ou por API: rag = txtai.RAG(embeddings, "model-name"), depois chame rag("sua pergunta"). O pipeline cuida da recuperação e da construção do prompt.
Para quem o txtai é indicado?
Use o txtai quando quiser uma única dependência Python para busca, RAG e agentes sem infraestrutura para operar — evite quando precisar de um armazenamento vetorial escalável horizontalmente para muitas aplicações independentes.
Use o txtai se
- Você está construindo uma aplicação Python de nó único, uma ferramenta de linha de comando ou um app desktop e quer busca vetorial sem implantar um serviço de banco de dados
- RAG, agentes e workflows multimodelo devem vir de um único pacote, em vez de combinar um banco de dados vetorial com um framework de orquestração separado
- O conjunto de dados cabe confortavelmente em uma máquina — de alguns milhares a poucos milhões de vetores, dependendo da dimensão e da RAM disponível
- Prototipagem é a prioridade e a decisão de "qual serviço de banco de dados vetorial implantar" pode ser adiada até o projeto se provar
Evite o txtai se
- Você precisa de um armazenamento vetorial consultado simultaneamente por muitos serviços ou aplicações independentes — essa é a função de um banco de dados cliente/servidor, não de um embutido
- Sua coleção precisa ser distribuída entre várias máquinas porque excede o que um único nó comporta em memória ou disco
- Você quer um construtor de workflows visual, sem código — o txtai é uma biblioteca Python code-first, sem tela de arrastar e soltar
- Você precisa de garantias de serviço gerenciado (SLA, ferramentas de operações dedicadas, controle de acesso separado da aplicação) que hoje só um provedor de banco de dados vetorial hospedado oferece
📌Nota: Veredito: escolha o txtai quando a restrição for "uma aplicação Python, uma máquina, operação mínima". Escolha um banco de dados vetorial independente (Qdrant, Weaviate, Milvus) quando a restrição for "muitos serviços precisam consultar o mesmo índice, em escala, desde o primeiro dia".
txtai vs. Chroma, Qdrant e LlamaIndex
Essas quatro opções resolvem problemas que se sobrepõem, mas são distintos: txtai e Chroma trazem um armazenamento vetorial embutido, Qdrant é um serviço de banco de dados dedicado, e LlamaIndex é um framework de orquestração sem armazenamento próprio.
Ferramenta | Arquitetura | Implantação | Licença | Ideal para |
|---|---|---|---|---|
| txtai | BD vetorial embutido + RAG/agentes | In-process, sem servidor | Apache 2.0 | RAG e agentes Python em um pacote |
| Chroma | Banco de dados vetorial | Modo embutido ou servidor | Apache 2.0 | Armazenamento vetorial de prototipagem simples |
| Qdrant | Banco de dados vetorial | Servidor (Docker/nuvem) | Apache 2.0 | Busca de produção multi-cliente |
| LlamaIndex | Framework RAG/orquestração | Precisa de armazenamento externo | MIT | Conectores de dados sobre qualquer BD vetorial |
Erros comuns ao avaliar o txtai
Esses erros vêm de aplicar suposições sobre bancos de dados vetoriais baseados em servidor a uma biblioteca com um modelo de implantação fundamentalmente diferente.
Erro 1: esperar que o txtai escale como um banco de dados vetorial hospedado de fábrica
Um índice Faiss/SQLite embutido está vinculado ao processo e à máquina que o abriram. Se o plano é ter muitas instâncias de aplicação consultando um índice compartilhado e crescente de forma concorrente, é preciso um backend de conteúdo cliente/servidor (content: client com URL de conexão) ou migrar para um serviço de banco de dados vetorial dedicado — não o modo embutido padrão.
Erro 2: tratar o txtai como "apenas" um banco de dados vetorial
Avaliar o txtai só pela qualidade da busca ANN ignora a maior parte do que o pacote oferece. Pipelines, workflows, agentes e construção de grafos de conhecimento são módulos centrais, não adicionais — uma comparação justa também os pesa contra montar separadamente um banco de dados vetorial mais LangChain, LlamaIndex ou framework semelhante.
Erro 3: presumir que a NeuML já vende uma versão hospedada
A biblioteca de código aberto não tem custo de licença. A NeuML oferece consultoria paga em torno da stack txtai e, segundo sua própria documentação, está desenvolvendo um produto hospedado separado chamado txtai.cloud — mas, no momento desta análise, essa oferta ainda está em desenvolvimento, não é um produto entregue e precificado para avaliar.
Perguntas frequentes
O txtai é gratuito?
Sim. O txtai é de código aberto sob a licença Apache 2.0, sem limite de uso nem custo de licença para a biblioteca em si. A NeuML, empresa que o mantém, vende consultoria de IA paga e desenvolve separadamente um produto hospedado chamado txtai.cloud, ainda em desenvolvimento no momento desta análise.
O txtai exige um servidor de banco de dados separado?
Não. O txtai embute seu índice vetorial e armazenamento de metadados diretamente dentro do processo Python — por padrão um índice ANN Faiss mais um arquivo SQLite, ambos persistidos como arquivos locais, sem processo servidor para implantar ou monitorar.
Quais backends ANN o txtai suporta além do Faiss?
Faiss é o padrão. O txtai também suporta HNSW, Annoy e pgvector (além de outros backends via seu pacote extra ann), configuráveis pela opção backend sem alterar o código da aplicação.
Em que o txtai é diferente do Chroma?
Ambos trazem um armazenamento vetorial embutido, mas o caminho típico de produção do Chroma é rodar como servidor, enquanto o txtai não tem um modo servidor separado para o qual evoluir — o txtai também reúne pipelines RAG, agentes e workflows multimodelo no mesmo pacote, o que o Chroma não faz.
Em que o txtai é diferente do Qdrant?
O Qdrant é um serviço de banco de dados vetorial dedicado, projetado para rodar como processo próprio (via Docker ou endpoint gerenciado na nuvem) e ser consultado por muitos clientes ao mesmo tempo. O txtai roda embutido dentro de um único processo de aplicação, trocando essa concorrência e escala horizontal por zero sobrecarga de implantação.
O txtai suporta geração aumentada por recuperação (RAG)?
Sim. O pipeline RAG combina um índice Embeddings com um LLM local ou por API, recupera trechos relevantes para uma consulta e gera uma resposta com citação — a própria documentação do txtai apresenta o RAG como algo além da busca vetorial, incluindo recuperação de contexto de web e SQL.
O txtai pode usar LLMs locais em vez de uma API na nuvem?
Sim. O txtai carrega modelos via Hugging Face Transformers, llama.cpp (formato GGUF), Ollama ou vLLM para inferência totalmente local, ou roteia para OpenAI, Anthropic Claude ou AWS Bedrock via LiteLLM quando um modelo por API é preferido — a mesma interface de pipeline LLM/RAG cobre os dois casos.
O txtai suporta agentes de IA?
Sim, construídos sobre o framework smolagents da Hugging Face. Os agentes do txtai conectam embeddings, pipelines e workflows para resolver tarefas de vários passos de forma autônoma, e suportam convenções de prompting de agentes como agents.md e skill.md.
Sob qual licença o txtai é distribuído?
Apache License 2.0, que permite uso comercial, modificação e redistribuição sem royalties — a mesma licença permissiva usada por Chroma e Qdrant.
Quem mantém o txtai?
O txtai é desenvolvido e mantido pela NeuML, empresa fundada por David Mezzetti. Além de manter a biblioteca de código aberto, a NeuML oferece consultoria de IA paga em torno da stack txtai.
O txtai consegue lidar com grandes conjuntos de dados que não cabem em uma máquina?
Não no seu modo embutido padrão. Um índice Faiss/SQLite de arquivo único fica limitado à máquina que o contém. Conjuntos de dados que precisam ser distribuídos entre vários nós, ou que exigem que muitos serviços independentes consultem um índice compartilhado simultaneamente, se encaixam melhor em um banco de dados vetorial dedicado e escalável horizontalmente.
O txtai é uma boa escolha para um primeiro protótipo de RAG?
Sim, especialmente para um desenvolvedor Python — toda a stack (índice, pipeline RAG e, opcionalmente, um LLM) se instala com um único pip install txtai e roda em um único script, sem contêiner de banco de dados para levantar antes da primeira linha de lógica de aplicação.