NVIDIANVIDIA-Certified Professional: Agentic AI2026-106.5 Enable real-time access and reasoning over structured and unstructured knowledge.
Reconcile live knowledge before answering
Completed by the knowledge check
Learning objective
Keep knowledge fresh with streaming ingestion and live search, resolving stale conflicts.
Core idea
A retrieval call made now can return knowledge that was already stale when it entered the index. A streaming producer can also be healthy while its downstream indexing is delayed. To answer a time-sensitive question, distinguish when an event happened, when it was ingested, and when its processed representation became searchable.
See 6.3.2 for choosing batch or incremental ingestion and 6.4.2 for data-quality freshness checks. Here the decision is made while answering: whether indexed knowledge is fresh enough, whether to fetch a live source, and how to reconcile a result that contradicts stored knowledge. The application needs an explicit acceptable age and a rule for source authority, not merely a fast retrieval endpoint.
How it works
Track searchable progress through the stream
NVIDIA’s Streaming Data to RAG developer example captures radio-frequency signals, transcribes them, and sends text for embedding and indexing. Its integration API uses POST /add_doc with document, doc_index, and doc_metadata. The metadata includes streamId, timestamp, start_ntp_float, end_ntp_float, and uuid; the timestamp is expressed in UTC, and the float fields represent Unix time in seconds.
Keep event identity and timing when adapting the example to another stream. A unique message ID identifies an observation, while its source time says when the observation applies. An ingestion timestamp is a separate observation about the pipeline. Substituting it for event time makes a delayed message look like a fresh business event.
The example batches documents before processing and graph-database ingestion; configure the document count through chat.params.batch_size in external/context-aware-rag/config/config.yaml. Smaller batches trade more processing calls for fresher retrieval; larger batches reduce calls but increase lag when arrivals are slow. A partial batch waits for enough documents to fill it. The UI distinguishes pending documents from processed, retrievable batches, so measure searchable progress rather than submission success. The example retrieves by ingestion-time windows and stream, so a question about when an event occurred needs source-time handling in the application rather than an assumption that ingestion time equals event time.
The README identifies certain Context-Aware RAG components in this developer example as pre-release and uses the streaming-data-to-rag-dev development branch. Treat this as an integration reference whose component support must be assessed before production adoption, rather than assuming every behavior belongs to a general released deployment.
For the NVIDIA RAG Blueprint’s upload-event pipeline, see 6.3.2: an upload notification is not searchable content, so measure freshness at the indexed side.
Decide when to retrieve a live source
Define an application-owned freshness record containing source identity, source revision, effective time, fetched time, and last verified searchable progress. Assign an acceptable age by question type. An incident question may require seconds; a policy explanation may tolerate hours. These are business requirements to measure, not latency guarantees supplied by the streaming example.
If indexed progress falls behind that requirement, use an authorized live lookup where one is available. This can be a structured operational query as in 6.5.1, or a web-search path for public material. Live lookup avoids waiting for the indexing pipeline, but adds external latency and can expose a question to a third party. Apply the source authorization and provenance checks from 6.5.2 before combining its result with stored passages.
NVIDIA’s AI-Q Blueprint documents a Tavily web-search integration using TAVILY_API_KEY. Its README states that the agent continues without web search when that key is absent. Therefore, a successful research response alone cannot prove that live search ran. For a question requiring live verification, the application must inspect the tool outcome and require a fetched source, or return that the time-sensitive fact remains unverified. Indexed progress that falls behind the acceptable age sends the question to a live lookup, and the lookup counts only when it returns a fetched source.
Fetching a page now proves retrieval time, not publication time or business validity. Retain the URL and supporting passage, then compare the source’s revision and effective date with the stored item. Do not rank a commentary page fetched during this request above the authoritative record solely because it was fetched later.
Reconcile conflicts instead of blending versions
Produce an application-defined conflict record identifying the entity, conflicting attribute, candidate values, source versions, applicable times, and authority decision. First determine whether the values actually refer to the same interval. A shipment scheduled for noon and a revised schedule effective at 10 can both be historically correct; only one may answer a question about the present schedule.
Next apply the business owner’s source precedence. Prefer the system of record for its own operational state; use a policy’s effective revision for its rules. A delayed arrival must not overwrite a greater source revision merely because the worker processed it last. Preserve the superseded version for historical questions while excluding it from present-state synthesis.
The query-time remedy for indexing lag is a verified live result or a qualified answer. The ingestion remedy is to repair the failed or delayed stage and advance searchable progress after processing completes. Keep those outcomes separate: a live answer does not repair the index, and replaying an event does not prove the assistant used its corrected representation.
If authoritative sources disagree over the same period, retain the conflict and withhold the affected conclusion. An application rule that averages conflicting numbers would manufacture a third value. Assign the source owner the reconciliation task and let the assistant explain only what the available, authorized observations establish.
Key distinctions and trade-offs
| Path | Choose when | Documented mechanism | Cost or limitation |
|---|---|---|---|
| Streaming text ingestion | Repeated time-window questions need accumulated observations | POST /add_doc, chat.params.batch_size, stream and time metadata | Transcription, batching, and indexing delay; some example components are pre-release |
| Event-driven document indexing | Uploaded enterprise documents must enter the knowledge base continuously | MinIO events, Kafka consumer, ingestor | Notification receipt precedes searchable content |
| Live lookup or search | The indexed view cannot meet the question’s acceptable age | Operational query tool or AI-Q Tavily integration | External latency, availability, authorization, and source verification |
Streaming makes repeated retrieval practical; live lookup reduces dependence on index lag. Using both requires explicit precedence so the model does not combine a stored value and its correction into an internally inconsistent answer.
Architecture / decision scenario
An airport operations assistant summarizes disruption notices and answers questions about gate assignments. The team requires gate facts no more than 30 seconds old and a complete answer within five seconds. Announcements enter the streaming pipeline; the operations system supplies a live structured query. These are scenario requirements.
At 11, the searchable stream ends at 11:00 because low announcement traffic has left the next batch below chat.params.batch_size. A stored notice assigns flight F42 to gate A7, while the authorized operational query returns B3 with an 11:01 effective time. A delayed announcement then arrives describing A7 at 10. The tempting design sorts documents by ingestion time and lets the model choose the last one. The operations owner rejects it because late arrival would reverse the correction.
The assistant records that the index is 100 seconds behind and uses the live query within its deadline. The conflict record identifies B3 as the operational value for the requested time and A7 as a superseded assignment. It reports B3 with the source time rather than merging both assignments. Public web search can explain a public disruption notice, but cannot overrule the airport’s assignment record.
If the live query fails, the assistant says the gate cannot be verified within the 30-second requirement. The ingestion owner investigates delayed searchable progress; the operations owner resolves any same-period disagreement. Restoring the stream and answering this request are separate responsibilities.
Common exam traps
- Equating ingestion acceptance with searchable completion.
- Using ingestion time as a substitute for event or effective time.
- Assuming an AI-Q response implies that web search executed.
- Treating a page fetched now as an authoritative present-state fact.
- Letting a delayed event overwrite a greater source revision.
- Blending conflicting values instead of resolving authority and applicability.
What to remember
Measure freshness at the searchable view, keep source time separate from pipeline time, and use live lookup when the question cannot tolerate index lag. Reconcile by entity, revision, applicable period, and authority. If the required fact cannot be verified, preserve that uncertainty instead of presenting stale knowledge as live state.
Knowledge check
A pipeline built on NVIDIA’s Streaming Data to RAG example transcribes radio traffic and submits each transcript with POST /add_doc. Every call succeeds, yet questions about the last few minutes sometimes miss recent transcripts. To check a 60-second freshness requirement, which measurement should the team track?
POST /add_doc submissionsAt night, announcements arrive slowly, and the newest searchable content in a Streaming Data to RAG deployment lags by several minutes while every component reports healthy. Each transcript is submitted as soon as it is produced, but waits in an unfilled batch. Which change targets that lag, and at what cost?
chat.params.batch_size , accepting more processing callschat.params.batch_size , accepting fewer but larger batchestop_k , accepting longer prompts per questionPOST /add_doc traffictop_k widens retrieval over content that is already searchable.An application sends time-sensitive questions to the NVIDIA AI-Q Blueprint and must label an answer “verified live” only when web search supported it. A research response comes back successfully and reads as current. What must the application confirm before applying the label?
TAVILY_API_KEY is absent, so a successful response alone does not prove a live lookup ran. The application inspects the tool outcome and requires a fetched source supporting the claim, or reports the fact as unverified; a current-sounding answer or a fast response proves neither.A logistics assistant stores delivery updates from a stream. Revision 7, effective at 10, moves shipment S9 to a 14 arrival. A delayed message carrying revision 5, which scheduled S9 for noon, is processed after it. The shipping system is the system of record for arrivals. At 11, what should the assistant report as S9’s current arrival time?
A port operations assistant must give berth assignments no more than 30 seconds old. The searchable index is two minutes behind, and the authorized live operations query has just timed out. A stored notice from 90 seconds ago assigns vessel V3 to berth 4. The response deadline has arrived, leaving no time to repair and verify the index. How should the assistant answer?
References
- NVIDIA, Streaming Data to RAG
- NVIDIA, API Integration
- NVIDIA, Continuous Ingestion from Object Storage RAG Blueprint
- NVIDIA, NVIDIA AI-Q Blueprint