RAG Document Metadata Tagger (BYO-key)

Auto-generate metadata tags for documents before indexing into a vector store.

Use your own OpenAI or Anthropic API key to generate title, summary, keywords, category, and date metadata for a document chunk. Outputs clean JSON ready for vector database ingestion. Your key stays in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why attach metadata to RAG chunks?

Metadata lets your vector store filter and re-rank beyond pure similarity — for example restricting retrieval to a category, date range, or document type. Rich metadata improves precision and powers hybrid search.

Good retrieval is rarely about embeddings alone. The metadata you attach to each chunk — title, category, keywords, date — is what lets a vector store filter and re-rank results instead of returning the nearest-but-irrelevant neighbour. This tool generates that metadata for you, using your own OpenAI or Anthropic key, and hands back clean JSON to drop into your ingestion pipeline.

How it works

Choose a provider and model, paste your API key, and drop in a document chunk. Select which fields you want — title, summary, keywords, category, date. The tool sends one direct request from your browser asking the model to return a strict JSON object with exactly those fields. The response is parsed, validated, and shown as formatted JSON you can copy verbatim into the metadata field of your upsert call.

Your key never reaches a Gera server — it is held only in the tab and sent straight to the provider (with the official direct-browser-access header for Anthropic). Refreshing clears it.

Why metadata matters for RAG quality

Without metadata, a vector store can only rank by semantic similarity. That is fine for direct factual queries, but it fails on two common scenarios:

Temporal relevance. If you have Q1 and Q3 earnings reports in the same index, a query about “current revenue” will surface whichever chunk happens to be semantically closest. With a date field in metadata, you can filter to the most recent quarter first, then run similarity search inside that narrower set.

Category-scoped retrieval. A support knowledge base might contain both API docs and billing policies. A question about “how to cancel” should search billing content, not API docs. A category field turns that intent into a filter predicate, cutting the candidate pool before any embedding comparison runs.

What a tagged chunk looks like

For a paragraph discussing API rate limits, a typical output might be:

{
  "title": "API Rate Limit Policy",
  "summary": "Describes the per-minute and per-day request limits for each plan tier and the behavior when limits are exceeded.",
  "keywords": ["rate limit", "429 error", "throttling", "API quota"],
  "category": "developer-docs",
  "date": null
}

That JSON merges directly into the metadata object you pass to your vector DB upsert call (Pinecone, Weaviate, Qdrant, pgvector, and most others accept arbitrary key-value metadata).

Using the output

  • Merge the JSON into each chunk’s metadata before calling your vector DB’s upsert.
  • Use category and date as filter predicates at query time to narrow the candidate set.
  • Keep keywords for hybrid (dense + sparse) search or BM25 boosting.

Tips

  • Cheaper, faster models (gpt-4o-mini, claude-3-5-haiku) are usually plenty for short tagging tasks and minimise cost.
  • Generate only the fields your retrieval layer uses — every extra field is tokens spent and noise stored.
  • Tag at the chunk level, not the whole document, so per-chunk filtering stays meaningful.
  • Run a sample of ten chunks through the tagger and inspect the output before processing a full corpus — it is the fastest way to catch prompt or schema mismatches early.