Use this for last-mile review. Keep it open during mixed OCI Generative AI questions and pair it with the Resources when you want Oracle’s exact GenAI phrasing. Strong answers usually separate model fit, retrieval quality, data boundary, safety, and deployment operations before touching prompt wording.
Read every GenAI scenario in this order
- Decide whether the issue is model capability, prompt design, retrieval, data access, safety, or operations.
- Check whether the system needs generation, summarization, classification, extraction, embedding, or tool use.
- If external facts matter, inspect the RAG layer before changing the model.
- If enterprise data is involved, confirm access control, metadata filters, tenancy boundaries, and logging.
- Optimize cost and latency only after correctness and safety are measurable.
OCI answer sequence
Use this when the stem mixes ingress, async delivery, reliability, security, or operations.
flowchart TD
S["Scenario"] --> I["Classify the interaction mode"]
I --> E["Pick API Gateway, Events, Notifications, Streaming, or Functions"]
E --> R["Check retry, idempotency, ordering, and dead-letter behavior"]
R --> S2["Check Vault, IAM, private exposure, logs, and auditability"]
Fast lane picker
| If the question is mainly about… |
Start with… |
Usual winning move |
| bad answers from good-looking prompts |
retrieval and grounding quality |
prompt wording is rarely the first fix |
| irrelevant or wrong documents |
chunking, metadata, filters, and top-k |
retrieval boundary first |
| unsafe or hostile input |
prompt-injection defenses and permission limits |
treat retrieved content as untrusted |
| slow or expensive inference |
context length, candidate set, caching, and model fit |
control tokens before chasing bigger infra |
| evaluation |
retrieval, groundedness, and safety separately |
do not collapse quality into one vague score |
| model selection |
task type, modality, context need, and latency budget |
bigger model is not automatically better |
| private enterprise knowledge |
RAG plus access-aware retrieval |
avoid putting every problem into fine-tuning |
| action-taking assistant |
tool permissions and auditability |
generation and execution are different risks |
Canonical RAG flow
flowchart TD
Docs["Documents"] --> Chunk["Chunk and Clean"]
Chunk --> Embed["Embeddings"]
Embed --> Index["Vector Index"]
Query["Query"] --> Retrieve["Retrieve Top-K With Filters"]
Index --> Retrieve
Retrieve --> Prompt["Prompt With Context"]
Prompt --> Model["Model"]
Model --> Answer["Answer With Citations or Grounding"]
Fast rule: better prompts rarely fix a broken retrieval layer.
Service-fit chooser
| Requirement |
Stronger first fit |
| generate or summarize text with hosted foundation models |
OCI Generative AI style inference path |
| use enterprise documents without retraining |
RAG with vector search and metadata filters |
| build and manage custom ML workflows |
OCI Data Science style workflow |
| store and search embeddings |
vector index / vector database capability |
| call model output from an app |
endpoint, API, or application integration layer |
| automate actions from model reasoning |
tool/function integration with strict permissions |
Model-choice reminders
| Factor |
Better reading |
| context window |
limits how much source material and conversation state can be used |
| latency |
smaller or specialized model may beat a larger general model |
| cost |
token volume, model choice, retrieval volume, and reruns all matter |
| modality |
text, image, code, or embedding task shape should drive model choice |
| governance |
data handling and regional availability may eliminate otherwise attractive choices |
Prompting reminders
| Prompt need |
Stronger pattern |
| consistent answer format |
explicit output schema or structured instruction |
| better reasoning discipline |
specify role, constraints, and success criteria |
| reduce hallucination |
require use of provided context and say what to do when context is missing |
| extract facts |
provide fields, allowed values, and examples |
| unsafe request handling |
instruct refusal or escalation path, but do not rely on prompt alone |
Retrieval chooser
| Concern |
Strongest first lane |
Why |
| low relevance |
chunking and embeddings |
meaning may be represented badly |
| wrong tenant or version |
metadata filters |
boundary and freshness problem |
| too many weak documents |
top-k and ranking discipline |
context quality beats context quantity |
| fluent but unsupported output |
grounding quality and evaluation |
generation depends on retrieval quality |
| stale answer |
document freshness and index refresh path |
old chunks can beat a good prompt |
| mixed customer data |
tenant-aware filtering and authorization |
retrieval boundary is security boundary |
Chunking and retrieval traps
| Decision |
Too small |
Too big |
| chunk size |
weak context |
low precision |
| overlap |
wasted cost |
continuity breaks |
| metadata |
missing filters |
wrong tenant, version, or policy scope |
RAG design decisions
| Decision |
What to optimize |
| document cleaning |
remove boilerplate, navigation, duplicate headers, and low-signal text |
| chunk boundaries |
preserve semantic units such as section, table, or policy clause |
| embedding model |
match language, domain, and retrieval task |
| top-k |
enough candidates for coverage, not so many that context gets noisy |
| metadata filters |
tenant, product, version, date, policy, region, or entitlement |
| reranking |
improve final context quality when first-pass vector search is too broad |
Embedding and vector-search traps
| Trap |
Better reading |
| embedding everything without cleanup |
poor input creates poor retrieval |
| using only vector similarity when strict filters are needed |
security and freshness need metadata controls |
| increasing top-k to fix every miss |
more context can lower precision and raise cost |
| treating embeddings as reversible storage |
embeddings are search representations, not document originals |
| forgetting index refresh |
new or corrected documents need indexing before they can help |
Evaluation signals
| Layer |
What to measure |
| retrieval |
relevance, hit rate, filter correctness |
| generation |
groundedness, correctness, citation quality |
| safety |
prompt-injection resilience, leakage, policy violations |
| operations |
latency, token use, and failure rate |
| business fit |
task completion, escalation rate, and user correction rate |
Evaluation traps
| Trap |
Better reading |
| grading the whole system with one fuzzy quality impression |
score retrieval, generation, and safety separately |
| blaming the model before checking retrieval |
retrieval weakness often causes “model” weakness |
| assuming citation presence proves correctness |
citations can still point to poor or irrelevant retrieval |
| using only happy-path questions |
include adversarial, stale, missing-context, and permission-boundary tests |
| testing once before launch |
GenAI quality needs ongoing evaluation after content and behavior drift |
Prompt-injection and safety cues
| Concern |
Strongest first control |
| hostile instructions inside retrieved content |
treat documents as untrusted input |
| dangerous tool use |
limit permissions and allow only required actions |
| suspicious queries |
log, review, and monitor abuse patterns |
| cross-tenant data exposure |
strict metadata and access boundaries |
Safety and governance controls
| Risk |
Better control |
| prompt injection |
isolate instructions from retrieved content and constrain tool use |
| data leakage |
authorization-aware retrieval, redaction, and logging discipline |
| toxic or disallowed output |
safety filters, policy checks, and escalation path |
| unapproved model behavior |
evaluation gates and deployment approval |
| compliance evidence |
audit logs, data lineage, and retention policy |
| unsafe automation |
human approval or narrow tool permissions for high-impact actions |
| Trap |
Better reading |
| model can call any tool because it is smart |
tools need least privilege and allowlists |
| successful natural-language answer proves action is safe |
generation and execution require separate controls |
| retrieved document can override system policy |
retrieved content is untrusted input |
| no audit trail for tool calls |
enterprise agent design needs action evidence |
| agent used for a simple lookup |
use RAG or direct retrieval when staged reasoning is unnecessary |
Cost and latency controls
| Pressure |
Better first move |
| large token cost |
cap context length and top-k intentionally |
| retrieval overhead |
use filters to shrink the candidate set |
| repeated embedding cost |
cache and reuse embeddings and indexes where appropriate |
| high latency |
reduce unnecessary context and expensive paths first |
| unpredictable spend |
set usage limits, monitor token volume, and cap retries |
| slow answer from many calls |
reduce chain depth before scaling infrastructure |
Deployment cues
| If the question is mainly about… |
Strongest first lane |
| safe rollout |
staged deployment and rollback path |
| quality drift |
continuous evaluation and monitoring |
| enterprise safety |
policy, permission, and data-boundary enforcement |
| operational confidence |
observe latency, errors, and token spend |
Production monitoring map
| Signal |
Why it matters |
| latency |
user experience and timeout risk |
| token usage |
direct cost and context-size pressure |
| retrieval hit quality |
source of many answer-quality failures |
| grounding score or review result |
detects unsupported answers |
| safety violation rate |
shows policy and abuse pressure |
| escalation / correction rate |
practical business-quality signal |
| index freshness |
prevents stale or missing source behavior |
Troubleshooting order
| Symptom |
Check first |
| fluent but wrong answer |
retrieval relevance and context grounding |
| cites wrong source |
metadata filters, chunk boundaries, and reranking |
| refuses too often |
safety policy, prompt constraints, and missing context |
| leaks wrong tenant |
authorization filter and retrieval boundary |
| too slow |
context length, top-k, chain depth, model size |
| too expensive |
token volume, retries, embedding refresh, model choice |
| works in test but not prod |
permissions, region, endpoint config, and data freshness |
Decision order that usually wins
- Classify the failure as retrieval, generation, safety, deployment, or cost.
- Fix source quality, access boundaries, and filters before increasing model size.
- Measure retrieval and generation separately.
- Add safety controls beyond prompt wording.
- Optimize token and latency costs only after the answer is grounded and safe.
Last 15-minute review
| If you only keep one thing from each lane… |
Remember this |
| RAG |
retrieval quality shapes answer quality |
| chunking |
chunk size and metadata both affect correctness |
| safety |
retrieved content is untrusted input |
| evaluation |
score retrieval, generation, and safety separately |
| cost |
top-k and context length are major levers |
| model choice |
fit the task, not the hype |
| deployment |
monitor quality, safety, latency, and spend together |
What strong 1Z0-1127-25 answers usually do
- identify whether the issue is retrieval, generation, safety, or deployment first
- improve grounding and filters before reaching for more prompt complexity
- treat prompt injection and data-boundary control as core system design issues
- balance answer quality with latency and token cost instead of optimizing only one dimension
- keep tool use, retrieval, and generation in separate risk lanes
- use evaluation evidence instead of vague “better response” impressions