1Z0-1127-25 Building LLM Applications with RAG and Vector Search Practice Test 8 — 15 Questions

Question 1

A RAG application is hallucinating because the LLM receives irrelevant context from the retrieval step, even when topK is set to 3. Which strategy would best reduce hallucination by improving the relevance of retrieved documents?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Add a reranking step after retrieval to select the most relevant chunks. Adding a reranking step after retrieval directly addresses the core issue: even with a low topK, the initial retrieval may return chunks that are semantically similar but not precisely relevant to the query. Reranking uses a cross-encoder model to score each retrieved chunk against the query, reordering them so that only the most contextually relevant chunks are passed to the LLM. This reduces the chance of the LLM receiving irrelevant context, thereby minimizing hallucination.

Answer

Reduce the chunk size to one sentence per chunk

Answer

Implement a query rewriting mechanism

Answer

Increase topK to 10 to provide more context

Question 2

Which TWO actions can improve the retrieval accuracy of a RAG system? (Select two.)

Accepted Answer

Use a more accurate embedding model. Option D is correct because the embedding model determines the semantic quality of the vector representations; a more accurate embedding model produces vectors that better capture meaning, so semantically similar queries and passages land closer together in the vector space, directly raising retrieval precision. Option E is correct because enriching chunk metadata (e.g., source, section, date, entity tags) and applying strict metadata filters during retrieval narrows the candidate set to contextually relevant chunks, preventing semantically similar but off-topic passages from being returned. Option A is not inherently correct: a smaller chunk size can improve granularity but also fragments context and can hurt recall, so it is not a reliable accuracy improvement for all documents. Option B is not correct because removing stop words before embedding can strip useful contextual and syntactic signals, degrading embedding quality rather than improving it. Option C is not correct because significantly increasing topK expands the number of retrieved chunks, which tends to add noise and lower precision instead of improving accuracy.

Answer

Use a smaller chunk size for all documents

Answer

Remove stop words from documents before embedding

Answer

Increase the topK parameter significantly

Question 3

Which THREE components are essential in a typical RAG architecture built on OCI? (Select three.)

Accepted Answer

Vector database (e.g., OCI OpenSearch, Autonomous Database). A typical RAG (Retrieval-Augmented Generation) architecture on OCI requires a vector database such as OCI OpenSearch or Autonomous Database (option A) to store and index the embedded representations of documents and perform similarity search at query time. It also requires an embedding model such as Cohere Embed (option C) to convert both the source documents and the user query into dense vectors that can be compared in that vector store. Finally, it requires a large language model such as Cohere Command (option D) to consume the retrieved context along with the user prompt and generate the grounded natural-language answer. Option B is not essential because a data ingestion pipeline can be implemented with many tools (OCI Data Integration, Object Storage events, LangChain loaders, etc.), and Apache Spark is only one possible choice, not a required component. Option E is not essential either, since a prompt template for system instructions is an implementation detail of prompt engineering rather than a defining architectural component of RAG.

Answer

Data ingestion pipeline with Apache Spark

Answer

Prompt template for system instructions

Question 4

The architecture shown in the exhibit is missing a critical component for a RAG pipeline. What step is missing between receiving the user query and searching the vector store?

Accepted Answer

A query embedding step using an embedding model. In a RAG pipeline, the user query must be converted into a vector embedding using the same embedding model that was used to index the documents. Without this query embedding step, the vector store cannot perform a meaningful similarity search because it compares vectors, not raw text. Option B correctly identifies this missing transformation between receiving the query and searching the vector store.

Answer

A document chunking step

Answer

A data masking step for privacy

Answer

A reranker step after retrieval

Question 5

A company is building a RAG application using OCI Generative AI and wants to store embeddings for document retrieval. Which OCI service is most appropriate for storing and querying vector embeddings?

Accepted Answer

OCI Search with OpenSearch. OCI Search with OpenSearch is the most appropriate service for storing and querying vector embeddings because it natively supports k-nearest neighbor (k-NN) search and vector field types, enabling efficient similarity search over high-dimensional embeddings. This makes it ideal for RAG applications where document retrieval relies on comparing query embeddings against stored document embeddings.

Answer

OCI MySQL Database

Answer

OCI Data Flow

Answer

OCI Object Storage

Question 6

During load testing, the RAG application's response time increases significantly. The vector search is performed on millions of vectors. Which optimization would MOST reduce latency?

Accepted Answer

Use approximate nearest neighbor (ANN) search instead of exact. Approximate nearest neighbor (ANN) search algorithms, such as HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index), trade a small amount of accuracy for a dramatic reduction in latency when searching over millions of vectors. In OpenSearch, ANN is implemented via the k-NN plugin and can reduce query latency from seconds to milliseconds by avoiding an exhaustive scan of all vectors.

Answer

Increase the number of replicas in OpenSearch

Answer

Shard the index by document type

Answer

Use a smaller embedding model

Question 7

A security audit reveals that the RAG application exposes internal documents through the chatbot. The vector search index contains sensitive data. Which action should be taken FIRST to mitigate?

Accepted Answer

Implement access control at the OpenSearch index level. The correct first step is to implement access control at the OpenSearch index level because the core issue is that sensitive internal documents are accessible to unauthorized users through the chatbot. By enforcing index-level permissions (e.g., using OpenSearch's fine-grained access control with roles and users), you can restrict which documents the RAG pipeline can retrieve, directly addressing the security vulnerability at the data source. This is a foundational security measure that should precede any other adjustments.

Answer

Reduce the number of retrieved chunks

Answer

Redact sensitive terms from documents before embedding

Answer

Use a different embedding model

Question 8

What is the primary purpose of chunking documents in a RAG pipeline?

Accepted Answer

To ensure each chunk fits within the model's context window. The primary purpose of chunking documents in a RAG pipeline is to divide large documents into smaller, manageable pieces that each fit within the model's context window. This ensures that the retrieval step can fetch relevant chunks without exceeding the token limit of the LLM, which would otherwise cause truncation or failure to process the input.

Answer

To improve embedding quality

Answer

To speed up training

Answer

To reduce storage costs

Question 9

A team uses Cohere's `rerank` endpoint after initial retrieval to improve result quality. What is the main benefit of reranking?

Accepted Answer

It reorders chunks by relevance to the query. The rerank endpoint takes the initial set of retrieved chunks and re-scores them based on their semantic relevance to the query, producing a reordered list where the most contextually appropriate chunks appear first. This improves the quality of the input fed to the LLM, leading to more accurate and coherent generated responses without altering the embeddings or the retrieval count.

Answer

It generates new embeddings for chunks

Answer

It combines multiple queries

Answer

It reduces the number of retrieved chunks

Question 10

In OCI OpenSearch, a k-NN search query returns results with low precision. The index uses HNSW algorithm. The search parameters are: `k=10`, `ef_search=100`. To improve recall without significantly increasing latency, which parameter should be adjusted?

Accepted Answer

Increase `ef_search`. Increasing `ef_search` expands the search radius in the HNSW graph, allowing the algorithm to explore more candidate nodes during the search phase. This directly improves recall by reducing the chance of missing true nearest neighbors, while the impact on latency is typically sub-linear because HNSW's hierarchical structure limits the additional traversal cost.

Answer

Decrease `ef_search`

Answer

Decrease `k`

Answer

Increase `k`

Question 11

Which TWO of the following are valid similarity metrics used in vector search?

Accepted Answer

Cosine similarity. Cosine similarity (B) is a valid vector-search similarity metric because it measures the cosine of the angle between two embedding vectors, giving a value from -1 to 1 that reflects semantic closeness independent of vector magnitude. Euclidean distance (C) is also valid, as it computes the straight-line L2 distance between two vectors in the embedding space, and vector databases commonly support it as a distance metric (often converted to a similarity score). Levenshtein distance (A) is not a vector metric; it measures the minimum number of single-character edits between two strings, so it applies to text/string comparison rather than dense vector embeddings. Hamming distance (D) counts differing bit positions between equal-length strings or binary codes, which is not the standard similarity measure for continuous embedding vectors. Jaccard index (E) measures set overlap (intersection over union) for discrete sets or token sets, not the geometric similarity between dense vectors used in vector search.

Answer

Levenshtein distance

Answer

Hamming distance

Answer

Jaccard index

Question 12

Which THREE factors should be considered when designing a chunking strategy for a RAG application?

Accepted Answer

Desired granularity of retrieval. Option A (Desired granularity of retrieval) is correct because chunk size directly determines whether retrieval returns broad context or precise, focused passages, so the target granularity must drive the chunking design. Option D (Document structure) is correct because chunk boundaries should respect natural divisions such as headings, sections, paragraphs, or code blocks, so the splitter must adapt to the source format rather than cutting blindly at fixed lengths. Option E (Embedding model's maximum input tokens) is correct because every chunk must fit within the embedding model's token limit; exceeding it causes truncation or errors, so chunk size must be bounded by that maximum. Option B (Number of GPUs available) does not belong because GPU count affects training or inference throughput, not the logical chunking strategy. Option C (Database indexing method) does not belong because the vector index type (for example HNSW or IVF) is chosen after chunking and concerns search performance, not how documents are split.

Answer

Number of GPUs available

Answer

Database indexing method

Question 13

A troubleshooting scenario: A RAG system returns no results for certain queries. The index exists and has documents. Which TWO are likely causes?

Accepted Answer

The query embedding dimension does not match the index dimension. Option B is correct because a vector index is built with a fixed dimensionality (e.g., 1536 for text-embedding-ada-002); if the query embedding is produced by a model with a different dimension, the similarity search cannot compute distances against the stored vectors and returns no matches. Option E is correct because embeddings from different models occupy incompatible vector spaces, so even with matching dimensions, a query embedded with a different model than the one used at index time yields meaningless similarity scores and effectively no relevant results. Option A is not a cause of empty results: brute-force (exact) search still returns nearest neighbors, and small index size only affects performance, not whether results are returned. Option C is not a cause: an over-length query is typically truncated or rejected by the embedding model, but if an embedding is produced it will still be searched. Option D is not a cause of no results for existing documents: an unrefreshed index would simply omit newly added documents, while the scenario states the index exists and contains documents.

Answer

The search algorithm is set to exact (brute-force) and index is small

Answer

The query is too long for the embedding model

Answer

The index has not been refreshed after adding new documents

Question 14

A developer is building a RAG application using OCI Generative AI. They notice that the generated responses often contain outdated information even though the knowledge base is updated daily. What is the most likely cause?

Accepted Answer

The vector database index is not rebuilt after data updates.. In a RAG pipeline, the vector database index is a static snapshot of the embedded knowledge base. When the knowledge base is updated daily, the index must be rebuilt or incrementally updated to reflect the new data. Without rebuilding, the retrieval step will still search the old index, returning outdated chunks and causing the LLM to generate stale responses.

Answer

The embedding model is not fine-tuned on the latest data.

Answer

The retrieval top-k is set too high.

Answer

The chunk size is too small, causing loss of context.

Question 15

A team is optimizing a RAG pipeline for OCI Generative AI. They observe that the model's responses are verbose and often include irrelevant details from the retrieved chunks, reducing user satisfaction. They have already tuned the prompt template. What is the most effective next step?

Accepted Answer

Implement a re-ranking step using a cross-encoder model.. Implementing a re-ranking step with a cross-encoder model directly addresses the problem of verbose and irrelevant responses. Cross-encoders evaluate the query-document pair jointly, producing a fine-grained relevance score that filters out noisy or off-topic chunks before they reach the generation model. This improves the quality of the context provided to the LLM, reducing verbosity and irrelevance without requiring retraining or altering the retrieval threshold.

Answer

Apply instruction tuning on the generation model.

Answer

Reduce the number of retrieved chunks from 5 to 3.

Answer

Increase the similarity threshold for retrieval from 0.7 to 0.85.