Oi, sou michael,
criei um banco de dados localmente no postgres e quando tento fazer upload dos dados no db, ele dá erro. Achei que é porque os dados que o pgvector store do postgres envia têm apenas 4 campos: id, embedding, content e metadata.
Não quero que todos os meus dados de um documento fiquem dentro de um campo de metadata, mas em um campo normal do meu db. Não consigo descobrir, tentei por um dia.
por favor, me ajudem
Oi @michael13, enquanto você espera por uma resposta, aqui estão algumas coisas que podem ajudar:
Automaticamente correspondido à sua pergunta.
Docs:
Fórum:
@achamm, @viko, @Anshul_Namdev - vocês já ajudaram em problemas similares antes, podem dar uma olhada?
Automaticamente sugerido pelo bot comunitário do n8n. É um piloto - compartilhe seu feedback aqui.
Oi @michael13 Bem-vindo!
O nó PGVector escreve apenas as quatro colunas que mapeia, e a opção Column Names renomeia essas quatro em vez de adicionar outras, então chunk_index e todas as outras colunas em document_chunks permanece nula na inserção. Coloque os campos que você deseja como colunas reais na opção Metadata do Default Data Loader, então deixe o Postgres copiá-los do jsonb metadata com um trigger before-insert. chunk_index é por chunk em vez de por documento, então o loader não consegue fornecer, numere-o no trigger em vez disso:
create or replace function document_chunks_fill()
returns trigger as $$
begin
NEW.chunk_index := coalesce(
(select max(chunk_index) + 1 from document_chunks
where metadata->>'doc_id' = NEW.metadata->>'doc_id'), 0);
return NEW;
end;
$$ language plpgsql;
create trigger document_chunks_before_ins
before insert on document_chunks
for each row execute function document_chunks_fill();
Defina doc_id no loader Metadata para que o contador tenha algo para agrupar, e adicione uma linha NEW.<column> := NEW.metadata->>'<key>'; para cada outra coluna que você deseja preencher.
A resposta existente está correta que o nó PGVector nativo escreve apenas suas colunas mapeadas de ID, vetor, conteúdo e metadados. Isso significa que seu esquema document_chunks não é compatível com este escritor enquanto chunk_index ou qualquer outra coluna não mapeada for NOT NULL sem um padrão de banco de dados.
Eu não usaria o gatilho max(chunk_index) + 1 como escrito. Duas inserções para o mesmo documento podem ler o mesmo máximo antes de qualquer uma ser confirmada e escolher o mesmo próximo valor. Uma restrição única pode detectar essa colisão, mas ainda fará uma inserção falhar.
Para o design que você descreveu, mantenha campos de negócio ordinários em uma tabela documents normal. Armazene as incorporações e o texto do fragmento na tabela de vetores, e mantenha apenas um doc_id estável nos metadados do vetor para que você possa juntar os fragmentos recuperados de volta à linha relacional. Isso evita copiar cada campo de negócio em metadados.
Em seguida, escolha a semântica de chunk_index explicitamente. Se ela só precisa ser globalmente exclusiva, use uma identidade gerada pelo banco de dados ou sequência. Se ela deve ser numerada separadamente dentro de cada documento, use um escritor personalizado que popule colunas reais doc_id e chunk_index, serialize a atribuição por documento, e aplique UNIQUE (doc_id, chunk_index). Não aplique SQL ALTER TABLE exato até inspecionar o DDL da tabela atual.
Se você exigir zero metadados, incluindo sem link de doc_id, o nó PGVector nativo é o escritor errado para este esquema; use um caminho de inserção Postgres personalizado.
Referências oficiais: