Spot-Check Pinecone Retrieval Quality with a Query by Vector Id

The fastest way to judge a RAG corpus is to ask it about something it already contains. This blueprint runs that check as a repeatable flow: io.kestra.plugin.pinecone.Query uses vectorId to query by an existing vector's id, so no embedding model is needed at query time, and returns the five nearest neighbors with their metadata. If a product FAQ's closest neighbors are unrelated release notes, the embedding or chunking strategy has a problem, and this flow surfaces it before users do. Discord gets the match count; the full scored match list stays on the execution.

How it works

1. similarity_query (io.kestra.plugin.pinecone.Query) queries the index named by index_name using vectorId set to the vector_id input, with topK: 5 and includeMetadata: true. Querying by id makes Pinecone use the stored vector as the query point, so the check needs no embedding call.
2. The task outputs the matches as rows and the match count as {{ outputs.similarity_query.size }}.
3. notify posts the anchor id and the match count to Discord as plain scalars, pointing at the execution for the full scored list.
4. The errors block posts a distinct Discord alert when the query fails, which usually means the anchor vector is missing or the index is unreachable.

What you get

• A retrieval QA check that runs without an embedding model in the loop.
• The top five neighbors with metadata attached to every execution, ready for human review.
• A match count scalar that downstream tasks can assert on, for example failing when fewer than five neighbors return.
• A repeatable anchor-based check: keep a handful of known documents as anchors and run the flow against each.

Who it's for

• ML engineers validating that a re-embedded or re-chunked corpus still clusters sensibly.
• RAG teams who want a quick post-ingestion smoke test instead of waiting for user complaints.
• Support and search teams checking that known duplicate documents actually retrieve each other.

Why orchestrate this with Kestra

An ad hoc query in a notebook proves the index worked once, on one laptop. Kestra makes the spot check a versioned flow with inputs, so anyone can run it against any anchor document, every run is stored with its full match list, and the check can be chained after every ingestion. Retrieval QA becomes part of the pipeline instead of a tribal ritual.

Prerequisites

• A Pinecone index that already contains vectors; the embeddings upsert blueprint loads one.
• The id of at least one existing vector to use as the query anchor.
• A Discord incoming webhook for the report and failure alerts.

Secrets

• PINECONE_API_KEY: Pinecone API key with read permission on the index.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the PINECONE_API_KEY and DISCORD_WEBHOOK_URL secrets to your Kestra namespace.
2. Execute the flow with vector_id set to a document id you know is in the index.
3. Check the Discord message reports five matches, then open the execution to review the neighbors and their metadata.

How to extend

• Add a filter map to the query to restrict matches by metadata, for example only documents from the same product area.
• Set includeValues: true when you need the raw vectors for offline distance analysis.
• Raise topK and add a downstream assertion that the anchor's known duplicate appears in the results.
• Run the flow for a list of anchor ids with a Loop task to build a small retrieval regression suite.

Links

• Pinecone plugin documentation
• Pinecone documentation