LlamaIndex Interview Questions: Ingestion, Document Updates, and Retrieval Evidence

LlamaIndex interview questions become concrete when a document changes and the assistant keeps citing its old contents. Follow the revision from source identity to stored nodes to query evidence before changing prompts or chunk sizes. A successful ingestion call does not, by itself, prove that users can retrieve the intended revision.

Start with Design a Multi-Tenant Enterprise RAG Assistant: Hybrid Retrieval, Reranking, ACLs. Use its freshness and permission requirements to explain a narrower LlamaIndex update contract.

Evidence boundary: Linked LlamaIndex documentation establishes the framework concepts and illustrated APIs. The policy-revision ledger, failure matrix and release procedure below are original design exercises and inferences. They are not candidate reports or claims about any employer's assessment. Vector-store behavior depends on the selected adapter and backend; verify the installed versions rather than assuming every integration offers identical guarantees.

LlamaIndex interview questions: what identifies the document?

The official Documents and Nodes guide describes a Document as the source container and a Node as a derived chunk with metadata and relationships. Keep their identities separate. One source document can produce several nodes; replacing the document may change their number and boundaries.

For this original exercise, a refund policy has stable source identity policy:42. Revision v1 permits refunds within 30 days. Revision v2 changes that period to 14 days and adds an exception. The connector should retain the source identity while recording the revision separately. Creating a fresh unrelated document ID on every load prevents an update mechanism from recognizing the intended replacement.

The document customization guide supports explicit IDs and metadata. A filename-derived ID may be useful in a small exercise, but decide what a move or rename means in the source system. Is it the same object at a new path, or a genuinely new document? The answer belongs to the connector's identity contract.

Record source ID, revision, tenant, permission scope and provenance. Specify which metadata should influence embeddings and which should be available to generation. The customization guide provides separate exclusions for embedding and LLM metadata; excluding a field from model text does not enforce authorization.

What does the ingestion cache actually cache?

The Ingestion Pipeline guide describes transformations that produce nodes and optionally write them to a vector store. It also describes caching node-and-transformation combinations. That avoids repeated computation; it is a different concern from reconciling the source document's current state.

Ask three separate questions: was the transformation output reused, did document management identify a changed source, and did query-visible storage reflect the intended revision? A cache hit answers the first question. It does not establish the other two.

Imagine that v2 was parsed correctly but an application-level answer cache still serves the v1 response. Clearing ingestion cache would redo work without addressing the observed stale answer. Conversely, if a custom transformation reads a remote policy setting absent from its cache identity, reusing its prior output can be wrong even when document text is unchanged.

This is an application inference: include every dependency that changes transformation meaning in a declared version or invalidation policy. Chunking configuration, embedding model revision and custom enrichment logic are candidates. Confirm what the installed transformation hashes actually cover; do not claim arbitrary external dependencies are automatically discovered.

Treat ingestion cache, document store, vector storage and answer cache as distinct operational components. Identify which one owns the state you are investigating and what evidence would show that its contents are current.

How should a changed document replace old nodes?

The document-management pipeline example explains the document-ID/hash comparison and the role of an attached document store. Upsert handling also requires the vector-store path; attaching a document store alone does not synchronize a remote vector index.

Use this original revision ledger as a proposed application invariant, not a claim that LlamaIndex makes every step atomic:

Event	Source identity	Derived nodes in this exercise	Required query-visible result
Initial ingestion	policy:42, v1	old-a, old-b	Authorized queries can retrieve v1
Text update	policy:42, v2	new-a, new-b, new-c	Current-policy queries retrieve v2; old nodes are retired from that scope
Retry of the update	policy:42, v2	Same intended replacement set	No additional live revision or accidental duplicates
Source deletion	policy:42 removed	All associated current nodes	Queries cannot use the removed policy

The node labels are illustrative identifiers. Three replacement nodes may be needed where two existed before. Upserting only matching node IDs can leave an old tail behind if the new document is shorter. Appending newly generated IDs can preserve the entire old revision. Explain how reference-document identity enables retirement of the complete old set.

Inspect the adapter's deletion behavior, source-to-node mapping and read-after-write visibility. If the backend lacks the needed operation, propose a different reconciliation mechanism or storage choice. A wrapper API name is not proof that every storage layer changed together.

When would you use update_ref_doc or refresh_ref_docs?

The official Document Management guide illustrates update_ref_doc, refresh_ref_docs and delete_ref_doc. Refresh processes supplied documents according to their identity and changed content and can insert new ones. Do not assume that absence from a partial input batch authorizes deletion from the complete corpus.

An abbreviated preparation example follows the documented identity pattern:

from llama_index.core import Document

revision = Document(
    text="Refunds are available within 14 days, subject to exceptions.",
    id_="policy:42",
    metadata={"revision": "v2", "tenant": "acme"},
)

# Existing compatible index, adapter and storage are prerequisites.
changed = index.refresh_ref_docs([revision])

The call is not a transactional release procedure. Specify the existing index, how it stores source relationships, and what the returned flags mean. Then verify retrieved node metadata and contents. A changed flag is useful execution evidence; it is not a universal guarantee of immediate visibility through every replica and cache.

Handle deletions through an explicit event or a verified complete inventory. An incremental batch containing one updated file is not a snapshot of all remaining files. For a full inventory, protect against connector failure returning an empty list and accidentally authorizing a mass removal.

The guide also exposes document-store deletion choices because nodes may be shared. Decide whether another index still uses the stored content before removing it. In an interview, distinguish retiring a document from one query scope from erasing every shared copy.

How do you recover from a partially completed update?

LlamaIndex's vector-store feature table distinguishes filtering, deletion and document-storage capabilities across integrations. It should prompt a backend-specific recovery discussion, not a claim that a distributed update has one universal transaction boundary.

Suppose new nodes were inserted but the worker crashed before retiring v1. A retry that blindly appends nodes can worsen duplication. Track an update operation's stable identity, source revision and intended node set. Reconcile existing state before deciding which steps to repeat.

For a stricter release requirement, an original design option is to stage a complete revision under an inactive generation, verify it, and switch the query's active-generation reference. This requires a reliable mechanism for that switch and enforcement across every retrieval path. It is not a built-in guarantee implied by creating an index.

State the trade-off: staging needs additional storage and careful cleanup, while in-place updates may expose intermediate state. Define whether the acceptable failure is a temporary absence, an older answer, or a mixed revision. Business requirements decide which compromise is acceptable.

A meaningful recovery test crashes after insertion, after retirement and before completion acknowledgment. Rerun the same operation, then inspect the source-to-node ledger and actual query results. Do not declare exactly-once behavior because a retry returned without raising an exception.

What evidence separates retrieval failure from answer failure?

The Retriever guide provides a way to inspect retrieval independently. The Response Synthesizer guide describes generation after retrieval and postprocessing, including a no_text mode for examining source nodes without generating an answer.

Use this original diagnostic matrix for the v2 policy question:

Observed evidence	Supported diagnosis	Next check
Retrieved text says 30 days and revision is v1	Stale or incorrectly scoped retrieval	Storage retirement, active revision, query and retrieval caches
Retrieved v2 text says 14 days, answer says 30	Retrieval supplied current evidence; answer path diverged	Prompt context, conversation history, synthesis and answer cache
Correct v2 text belongs to another tenant	Authorization failure despite relevant content	Tenant and user-permission enforcement before model exposure
No supporting span is returned	Missing evidence, not permission to invent an answer	Ingestion completeness, filters, retrieval settings and abstention

For each returned node, retain document identity, revision, permission-relevant scope, retrieval score and the text actually used. Inspect the context after postprocessing too. A relevant node might have been removed, truncated or replaced before generation.

A similarity score does not establish truth, currentness or access rights. A source list proves which nodes the response object associates with the run, not that every sentence is entailed by them. Check important claims against the specific supporting spans and preserve the relation between each citation and its source revision.

How would you evaluate the update rather than one answer?

The evaluation overview separates retrieval quality from response properties such as faithfulness and correctness. Use that separation to construct a small revision-focused exercise before a broad quality benchmark.

Create queries that require the changed refund period, the unchanged exception and information from an unrelated document. Test an authorized user, another tenant and a user whose access was revoked. Add a source deletion and a retry after partial insertion. Check the intermediate evidence as well as the final answer.

For the original v2 contract, assert that the changed-period query has current supporting text, forbidden nodes never reach generation, and a deleted policy does not remain answerable through a stale cache. These are different outcomes; an average language-quality score cannot substitute for any of them.

LlamaIndex's response-evaluation usage guide illustrates evaluator workflows. Treat judge outputs as fallible measurements. A response can faithfully repeat a stale source while failing the current business question. A correct-looking answer can also hide an authorization defect.

Version the corpus inventory, transformation configuration, embedding model, retrieval parameters and permission fixture. Report failures by cause. Keep a baseline that answers unchanged material correctly; fixing one changed-policy query by excluding too much content can damage the rest of the system.

Sources and Further Reading

• LlamaIndex Documents and Nodes
• Defining and customizing documents
• Ingestion Pipeline
• Ingestion pipeline with document management
• Document Management
• Vector-store features
• Retriever concepts and usage
• Response Synthesizer
• Evaluation concepts
• Response-evaluation usage

Research checked October 4, 2026. Confirm API names and integration behavior against your installed LlamaIndex packages.