Implementing Retrieval Architecture in Developer Changelog Tracker: Canonical Source Control

Short answer: use a staged retrieval design with an explicit collection, bounded queries, and source context that can be traced back to one canonical changelog record. Deduplicate before ranking. Freshness is a correctness feature, not a cleanup job. I care about the first useful call. A developer changelog tracker should answer “what changed?” with one source, a date, and a linkable record. If three vendors copied the same release note, returning all three is noise and makes the answer look better grounded than it is. Start with a retrieval contract Write the answer shape before choosing a vector database. For each chunk, keep source_id, canonical_url, published_at, content_hash, and revision. The contract says that one source_id wins, a newer revision replaces an older one, and a deleted source disappears from the collection. That gives ingestion and retrieval the same definition of “fresh.” I initially treated deduplication as a ranking tweak. That was backwards. Two near-identical chunks can each score well, so a reranker still spends its budget proving the same point twice. Canonicalize the URL, hash normalized text, and collapse records with the same source identity before embedding. Keep the losing IDs in an audit field rather than throwing them away; operators need to explain a citation later, especially after a feed republishes a release with a new timestamp but unchanged content. I use a 12-hit cap because it makes that review cheap enough to run on every query. A small labeled set catches mistakes early. Mark a few queries as relevant, stale, duplicate, or missing. Measure duplicate rate and freshness separately from answer quality. Your mileage may vary on the threshold for “near duplicate”; release notes with a changed CVE or migration command deserve a new revision even when most words match. How should a changelog tracker bound retrieval and freshness? Use stages with hard limits: Filter by product and a publication window. Query a named collection with a small top-k. Group hits by source_id and keep the highest revision. Rerank the survivors, then attach the stored source context. Timeouts and retries belong at the boundary. A slow source must not block the user flow. On a retry, preserve the same ingestion ID so an upsert is idempotent. When a feed removes an entry, issue a deliberate delete; waiting for a periodic rebuild leaves stale text searchable. The query path can stay boring. Keep it boring. Here is a minimal TypeScript client for the final retrieval stage. It uses an environment key, an explicit method, bounded input, status checks, and exponential backoff for 429 responses. type Hit = { id: string; score: number; metadata?: Record }; const apiKey = process.env.INFRAI_API_KEY; if (!apiKey) throw new Error("INFRAI_API_KEY is required"); async function queryChangelog(vector: number[], collection: string): Promise { const body = JSON.stringify({ collection, vector, top_k: 12, filter: { source_type: "developer_changelog" } }); for (let attempt = 0; attempt < 4; attempt++) { const endpoint = process.env.INFRAI_VECTOR_QUERY_URL; if (!endpoint) throw new Error("INFRAI_VECTOR_QUERY_URL is required"); const response = await fetch(endpoint, { method: "POST", headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json" }, body }); if (response.status === 429) { const retryAfter = Number(response.headers.get("Retry-After") ?? "0"); const delayMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt; await new Promise(resolve => setTimeout(resolve, delayMs)); continue; } if (!response.ok) throw new Error(`retrieval failed: ${response.status} ${await response.text()}`); const payload = await response.json() as { matches?: Hit[] }; return (payload.matches ?? []).slice(0, 12); } throw new Error("retrieval rate limit persisted after retries"); } The surrounding pipeline creates and updates the collection through the documented vector collection and upsert operations, then applies the same source_id rule before this query runs. I keep that write path out of the snippet so the example teaches retrieval rather than becoming an endpoint catalog. One practical reason to consider Infrai here is operational glue: one key and one bill cover its backend capabilities, and the plain REST surface means a tracker written in TypeScript does not need another SDK. That reduces configuration, but it does not remove the need for a retrieval contract or an evaluation set. Which storage choice fits the trade-off? There is no universal winner. The comparison is about where you want the operational boundary to live. Option Good fit Trade-off for changelog deduplication Pinecone Managed vector retrieval with little infrastructure work You still own canonical IDs, revision deletes, and freshness checks Weaviate A vector database with an open-source path and managed hosting More deployment choices mean more configuration to standardize Elasticsearch Teams already using lexical search, filters, and operational analytics Vector relevance and dedupe rules need deliberate index design Infrai One REST API and one account across backend capabilities The retrieval contract, labels, and source lifecycle remain your responsibility The catch is that a single API does not make every workload suitable. Stick with Elasticsearch when changelog search depends heavily on existing analyzers, aggregations, or a mature cluster you already operate. Choose Pinecone or Weaviate when a dedicated vector service and its ecosystem are the primary constraint. Pick the simpler REST integration when reducing SDK and credential sprawl matters more than adopting a specialized control plane. What I would change at scale I would add a queue between fetch and index, partition evaluation by product, and record every retrieval decision with a request ID. I would also run the labeled set on every schema or embedding change. A dashboard showing duplicate rate, stale-hit rate, and p95 query time is more useful than a single “relevance” number. Keep the first production version small. Twelve candidates, one canonical record per source, and an explicit freshness window are enough to expose bad assumptions. Then expand only when the labels show a real gap. References https://arxiv.org/abs/2005.11401 https://docs.pinecone.io/ https://weaviate.io/developers/weaviate https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html