AI Foundations - Every Developer Must Know

📋 AI Foundations

🧩

01. Tokens

How LLMs read text

🎲

02. Next-Token

Engine of generation

🪟

03. Context Window

Working memory

🔦

04. Attention

What model focuses on

⚙️

05. Transformers

LLM architecture

🗺️

06. Embeddings

Meaning as coordinates

🗄️

07. Vector DBs

Semantic storage

🔍

08. Semantic Search

Search by meaning

📚

09. RAG

Grounded generation

🏗️

10. Context Eng.

Designing the prompt

🔧

11. Tool Calling

Agent takes action

📞

12. Function Calling

Structured API bridge

⚡

13. Inference

Running the model

👻

14. Hallucination

Confident wrongness

⚓

15. Grounding

Anchoring to truth

🛡️

16. Guardrails

Safety boundaries

👁️

17. Observability

AI visibility

🧬

18. Distillation

Knowledge transfer

🗜️

19. Quantization

Model compression

---

🧩 Concept 01 of 19: Tokens — How AI Reads Your Words

Before an LLM can understand anything you type, it must first break your text into tokens. A token is not a word — it is a chunk of text that might be a full word, a syllable, or just punctuation. Every cost, every context limit, every speed constraint in AI is measured in tokens.

💡 Think of it this way: The word "integration" might split into integr + ation — two tokens. "OIC" is one token. An emoji 🤖 is also one token. Every token costs money and consumes your context window budget.

🧩 Tokenization live — "Oracle Integration Cloud is powerful!" splits into 12 tokens. Sub-words (purple) show how long words are broken apart.

📏 The 4-Char Rule

1 token ≈ 4 characters in English — rough but reliable. Non-English text (Hindi, Arabic, Japanese) is often less efficient — more tokens per word.

💰 OIC Budget Impact

Every OIC AI Agent call has a token budget. Large Fusion payloads consume thousands of tokens. Design prompts to be token-efficient without sacrificing context quality.

⚠️ Dual Billing

LLMs like OCI GenAI, Claude, GPT-4 all price by input tokens + output tokens separately. Every word you send costs. Every response costs.

🏁 Tokens are the currency of AI. Every word you send costs tokens. Every response costs tokens. Design your OIC prompts to be token-efficient without sacrificing context quality.

---

🎲 Concept 02 of 19: Next-Token Prediction — The Engine of All AI Generation

Every large language model — Claude, GPT-4, OCI Generative AI — does exactly one thing at its core: it predicts the next most likely token. Over and over. That single, elegant, repeated operation is the entire magic behind ChatGPT, Oracle AI Agents, and every LLM you will ever use.

💡 Think of it this way: The autocomplete on your phone. When you type "Good morning, how are" — it suggests "you". LLMs do this with hundreds of billions of parameters, making predictions that feel like reasoning, creativity, and intelligence.

🎲 The prediction loop — every token is generated one at a time, fed back as new input. The LLM picks the highest probability next token from 50,000+ options.

🔁 Autoregressive

Each new token becomes part of the input for the next prediction. The model does NOT think ahead — it generates left-to-right, one token at a time.

🌡️ Temperature

Controls randomness: 0 = always pick highest prob (deterministic), 1 = creative, 2 = chaotic. In OIC, control this in your GenAI invoke parameters.

🎯 Next-token prediction is not "thinking." It is extraordinarily sophisticated pattern completion. Understanding this prevents magical thinking about LLMs — and helps you design better OIC prompts.

---

🪟 Concept 03 of 19: Context Window — The Model's Working Memory

The context window is the maximum number of tokens an LLM can "see" at one time. Everything outside the context window is completely invisible to the model — it does not exist. This is the single biggest architectural constraint in every AI system you will build with OIC.

💡 Think of it this way: You're writing an exam but allowed to look at only a fixed-size whiteboard. Everything you've ever studied lives off-board. Only what fits on that whiteboard is available to you right now. Once it's full, older content slides off the edge.

🪟 A 200K context window fills up fast — system prompt, tool schemas, chat history, RAG docs all compete for the same space.

Model	Context Window	≈ Pages	OIC Integration
Claude 3.5 Sonnet	200K tokens	~150 pages	OIC GenAI Adapter
GPT-4o	128K tokens	~96 pages	OCI AI Gateway
OCI Cohere Command R+	128K tokens	~96 pages	Native OCI GenAI
Llama 3.1 405B	128K tokens	~96 pages	OCI Data Science

⚠️ NEVER blindly dump entire Fusion payloads into an LLM context. A large Fusion PO JSON can consume 8,000+ tokens. In OIC, trim, filter, and summarize data before sending it to the model.

🪟 Context window is the real estate of AI. Every byte in it costs money and latency. Architect your OIC flows to be context-efficient — only put what the model needs to do its job.

---

🔦 Concept 04 of 19: Attention — What the Model Focuses On

Attention is the mathematical mechanism that allows an LLM to look at every token in the context window and decide how much each token matters for the current prediction. It's not random — attention learns from billions of training examples which words to focus on and which to mostly ignore.

💡 Think of it this way: Reading "The OIC agent called the Fusion API to fetch the purchase order and returned it to the user." When predicting what comes after "user", your brain focuses on "returned", "purchase order", and "user" — not on "The" or "to". Attention does exactly that, mathematically and in parallel.

🔗 Self-Attention

Every token attends to every other token simultaneously — not sequentially. Handles long-range dependencies like "The server that the OIC developer configured last month failed" — model knows "failed" relates to "server".

🧠 Multi-Head Attention

The model runs many attention patterns in parallel, each learning different relationships: syntax, semantics, coreference. Up to 96 heads in large models.

⚡ Computational Cost

Attention is O(n²) in sequence length. Why very long contexts are expensive — every token must attend to every other token. Larger context = quadratic cost growth.

---

⚙️ Concept 05 of 19: Transformers — The Architecture That Changed Everything

The Transformer is the neural network architecture introduced in the landmark 2017 paper "Attention Is All You Need." Every major LLM — GPT, Claude, Gemini, Llama, OCI Generative AI models — is built on Transformers. It replaced older sequential models (RNNs, LSTMs) and enabled the entire AI revolution we're living in.

💡 Think of it this way: An old assembly line (RNN) reads words left-to-right, one word at a time. A Transformer is like a roundtable discussion — every word talks to every other word simultaneously. Infinitely more parallel. Infinitely more powerful.

⚙️ Transformer Block — What Happens Inside

① Embed + Position

Convert tokens to vectors + add positional info so order is preserved

→

② Multi-Head Attention

Q·Kᵀ/√dₖ → softmax → ·V run H times in parallel

→

③ Add & Norm + FFN

Residual connection + layer norm + feed-forward network

→

④ Linear + Softmax

Project to vocab size → probability over 50,000+ tokens → pick next

⚡ Key insight: ALL tokens processed IN PARALLEL — not left-to-right. This is why GPUs can train LLMs. Deeper stacks (more layers) = more abstract reasoning capability.

⚙️ The Transformer is to AI what the microprocessor was to computing. You don't need to design one — but knowing how it works makes you a better AI architect in every OIC engagement.

---

🗺️ Concept 06 of 19: Embeddings — Meaning as Coordinates in Space

An embedding is a list of numbers (a vector) that represents the meaning of a word, sentence, or document. Words with similar meanings get vectors that are mathematically close together. "Invoice" and "Payables" cluster near each other. "Invoice" and "Pizza" end up far apart.

💡 Think of it this way: Imagine a city map where every concept is a building. "Fusion Invoice" and "AP Payables" are on the same street. "Purchase Order" and "Procurement" are in the same neighbourhood. "Cricket" and "Invoice" are in different cities. Embeddings are the GPS coordinates of meaning.

📐 What Is a Vector?

embedding("Invoice") = [0.24, -0.81, 0.37, 0.12, 0.95, -0.44, … 1536 dimensions]. Each number captures some aspect of meaning learned from billions of training examples.

📊 Cosine Similarity

cosine_similarity(Invoice, Payables) = 0.91 ✅
cosine_similarity(Invoice, Pizza) = 0.04 ❌
High score = similar meaning. This is the math behind semantic search.

🏛️ OIC Use Case

When you index Fusion knowledge base articles, OCI OpenSearch stores each article as a vector. At query time, the user's question is also embedded. Closest vectors = most relevant articles. That is RAG.

---

🗄️ Concept 07 of 19: Vector Databases — Semantic Storage at Scale

A vector database stores embeddings and enables ultra-fast similarity search — not "find this exact text" but "find the most semantically similar content." Regular relational databases cannot do this. Vector databases are architected specifically for this job.

💡 Think of it this way: A regular database is a library with a perfect card catalog — you find books by exact title. A vector database is a librarian who has read every single book and can instantly retrieve everything related to your topic — even if your words don't appear in those books.

🗄️ Vector DB Pipeline — Index Once, Query in Milliseconds

INDEX TIME (done once at setup): Fusion Docs → OCI GenAI Embedding Model → OCI OpenSearch Vector Store → indexed and ready

⬇️

QUERY TIME (milliseconds, every request): User Query → Embed Query (same model) → Cosine Similarity Search → Top 5 Relevant Docs Returned

Vector DB	Oracle Native?	OIC Use Case
OCI OpenSearch	✅ Yes — recommended	RAG for Fusion AI Agents
Oracle Database 23ai	✅ Yes — built-in vectors	On-prem / hybrid RAG
Pinecone / Weaviate	❌ 3rd Party	Via REST adapter in OIC
ChromaDB	❌ Open Source	Dev / test environments

🗄️ For OIC AI Agents, OCI OpenSearch is your vector database of choice. Pair it with OCI GenAI embeddings and you have a fully Oracle-native, enterprise-grade RAG pipeline.

---

🔍 Concept 08 of 19: Semantic Search — Search by Meaning, Not Keywords

Traditional search finds pages containing your exact keywords. Semantic search finds content that means the same thing — even if it uses completely different words. "How do I cancel my order?" matches "order cancellation procedure" semantically, with zero word overlap.

🔍 Semantic Search vs Keyword Search — Query: "cancel order"

❌ Keyword Search

✅ "How to cancel an order"
❌ "Order reversal process"
❌ "Undo a purchase"
❌ "Annuler commande" (French)
❌ "क्रय रद्द करें" (Hindi)
exact word match only

✅ Semantic Search

✅ "How to cancel an order"
✅ "Order reversal process"
✅ "Undo a purchase"
✅ "Annuler commande" (French)
✅ "क्रय रद्द करें" (Hindi)
meaning-based — language agnostic

🔍 In OIC, always build your AI Agent knowledge base retrieval on semantic search — not keyword search. Your users won't use the exact words in your documentation. That's the whole point.

---

📚 Concept 09 of 19: RAG — Retrieval Augmented Generation

RAG is the most important pattern in enterprise AI. It solves the fundamental problem of LLMs: they were trained on public data and know nothing about your company, your Fusion data, or your internal processes. RAG lets you inject relevant, private, current knowledge into the model's context at query time — without retraining or fine-tuning the model.

💡 Think of it this way: An LLM without RAG is a brilliant consultant who knows everything public before their training date — but nothing about your company. RAG is like handing that consultant a stack of your internal documents right before the meeting. Suddenly they can answer company-specific questions using their intelligence applied to your data.

📚 Complete Oracle-Native RAG Pipeline for OIC

STEP 1 — INDEX (once): Fusion Docs → OCI GenAI Embed Model → OCI OpenSearch Vector Store

⬇️

STEP 2 — EMBED QUERY: User Question → OCI GenAI Embed (same model) → Query Vector

⬇️

STEP 3 — RETRIEVE: Cosine Similarity vs Vector Store → Top-K Most Relevant Fusion Docs Returned

⬇️

STEP 4 — AUGMENT: Query + Retrieved Docs → Combined Prompt → OCI GenAI LLM

⬇️

RESULT: ✅ Grounded Answer — based on your actual Fusion data, not hallucination. All Oracle. All native. Zero external dependencies required.

📚 RAG is the bridge between public LLM intelligence and your private enterprise data. Every production OIC AI Agent you build for Fusion should use RAG — or it's just hallucinating confidently about your company.

---

🏗️ Concept 10 of 19: Context Engineering — The Art of What You Put in the Window

Context engineering is the discipline of carefully designing everything that goes into the LLM's context window for each request. It goes far beyond "prompt engineering" — because in agentic systems, the context includes system instructions, retrieved documents, tool outputs, conversation history, user data, and output format specs.

💡 Think of it this way: Prompt engineering is writing a good question. Context engineering is deciding exactly which documents, data, rules, tool results, and history to put in front of the model before it answers — and how to structure and order them for maximum clarity.

🏗️ Context Window Anatomy — 5 Layers, Order Matters

① SYSTEM PROMPT — Persona, rules, constraints, output format, scope restrictions. Written by you. ~15%

② TOOL DEFINITIONS — Available OIC adapters/functions, schemas, parameter descriptions. ~12%

③ RAG RETRIEVED CONTEXT — Top-K most relevant Fusion docs from OCI OpenSearch for this specific query. ~20%

④ CONVERSATION HISTORY (trimmed) — Prior turns summarised to fit budget. Oldest messages dropped or compressed. ~30%

⑤ CURRENT USER MESSAGE — Always last, always clearest. This is what the model is actually answering.

🏆 The Golden Rule: Everything in the context window should earn its place. If removing it doesn't hurt answer quality — remove it. Every wasted token = money + latency + diluted attention.

🏗️ Context engineering is the #1 skill for OIC AI Agent architects. Better prompts get mediocre results. Better context architecture gets excellent, grounded, consistent results at scale.

---

🔧 Concept 11 of 19: Tool Calling — How Agents Take Action in the World

Tool calling is when an LLM decides to invoke an external capability — an API, a database query, a search — instead of generating a text response. This is the mechanism that transforms a chatbot into an agent. Without tool calling, an LLM can only produce words. With tool calling, it can act.

💡 Think of it this way: A person can talk about ordering a pizza. An agent with a tool can actually place the order. Tool calling is the hands of the agent. Without it, the agent has intelligence but zero ability to act in the world.

🔧 Tool Calling Loop — PO Status Query

① USER: "What is the status of Purchase Order PO-2025-001?"

⬇️

② LLM DECIDES: I need to call get_purchase_order(po_id="PO-2025-001")

⬇️

③ OIC EXECUTES: Calls Fusion REST API → Returns PO JSON with status, supplier, delivery date

⬇️

④ LLM RESPONDS: "PO-2025-001 is Approved. Delivery expected June 15, 2025. Supplier: Tech Corp." ✅ Grounded. Not guessed.

🔧 In OIC AI Agent Studio, your integration flows become the agent's hands. The LLM is the brain deciding when to act. You write the integrations. Oracle wires the routing. The agent decides when to use them.

---

📞 Concept 12 of 19: Function Calling — The Structured API Bridge

Function calling is the specific protocol by which an LLM outputs a structured JSON request to call a defined function — not free text, but a precise object specifying exactly which function to call and with exactly what parameters. It is the technical implementation mechanism underneath tool calling.

📞 Function Calling Protocol — What the LLM Actually Outputs

// 1. You define the schema — LLM reads this to understand when to call it
{
  "name": "get_fusion_po",
  "description": "Fetch a Fusion purchase order by ID from Oracle ERP",
  "parameters": { "po_id": string, "required": true }
}

// 2. LLM responds with structured call — NOT free text
{
  "tool_call": "get_fusion_po",
  "arguments": { "po_id": "PO-2025-001" }
}

✅ Type-safe · ✅ Parseable · ✅ Validated · ✅ Deterministic — Oracle AI Agent Studio handles parsing and routing automatically.

📞 Function calling is what gives your OIC AI Agent precision and reliability. Instead of free-text hope, you get structured, validated, type-safe API calls from the model every time.

---

⚡ Concept 13 of 19: Inference — Running the Model to Get an Answer

Inference is the act of running a trained AI model on new input to get an output. When your OIC flow calls OCI Generative AI with a prompt, OCI runs the model on your tokens and returns a response — that process is inference. As an OIC architect, you are always in inference mode.

💡 Think of it this way: Training is teaching a student for years. Inference is when that trained student answers your specific exam question right now. As an OIC developer, you never teach the model — you only ask it questions. Every API call is an inference.

Phase	Who Does It	When	OIC Role
Pre-training	Oracle / OpenAI / Anthropic	Once, over months	None — you consume the result
Fine-tuning	You (optional)	Occasionally	OCI Data Science / AI Studio
Inference ← YOU ARE HERE	OCI GenAI at runtime	Every API call	OIC GenAI Adapter

⚡ Inference is your runtime touchpoint with AI. Optimise prompt length, output format, and model choice to hit your OIC SLA targets — without sacrificing answer quality.

---

👻 Concept 14 of 19: Hallucination — Confident, Fluent, and Wrong

Hallucination is when an LLM generates factually incorrect information — but presents it with complete grammatical fluency and total confidence. The model doesn't know it's wrong. It's not lying. It's pattern-completing in a direction that sounds plausible but isn't true. This is the #1 risk in production AI systems.

🚨 NEVER deploy an OIC AI Agent that accesses Fusion data — invoices, POs, employee records, financial figures — without a grounding strategy. An ungrounded LLM will invent invoice amounts, PO numbers, and approval statuses with exactly the same confidence whether it actually knows them or not.

🟥 Factual Hallucination

User: "Was PO-9876 approved?"
AI: "Yes, approved by John Smith on March 12."

Reality: PO-9876 doesn't exist. John Smith doesn't exist. Model invented everything — with complete confidence.

🟡 Reasoning Hallucination

Invoice: ₹10,000, tax: 18%
AI: "Total payable is ₹11,200"

Correct facts. Wrong maths. 10000 × 1.18 = 11,800 not 11,200. Reasoning error confidently stated.

🟣 Instruction Hallucination

System: "Only answer Finance questions"
User: "What's my leave balance?"
AI: "You have 8 days leave."

Violated scope constraint. Invented a number it has no access to.

👻 Hallucination is not a bug to be fixed — it is a fundamental property of next-token prediction to be managed. RAG, grounding, output validation, and guardrails are your defences in every OIC AI Agent you build.

---

⚓ Concept 15 of 19: Grounding — Anchoring AI Outputs to Verified Truth

Grounding is the collection of techniques that connect an LLM's outputs to verified, authoritative sources — preventing hallucination by giving the model real facts to work with instead of making things up. Grounding is the answer to hallucination. RAG is the most powerful grounding technique in enterprise AI.

⚓ Grounding Strength Spectrum

❌ None

Pure LLM output. No data provided. Hallucination risk: HIGH 🔴

🟡 Partial

System prompt rules. "Use only provided facts." Some examples given. Risk: MEDIUM 🟡

✅ RAG Grounded

Retrieved real docs injected. Model cites sources. Tool calls get live data. Risk: LOW 🟢

🏆 Fully Verified

RAG + Tool Calling + Output schema validation + Numeric cross-check + Human-in-loop. Risk: VERY LOW ✅

⚓ Grounding is your professional obligation as an OIC AI Architect. Any AI Agent touching financial data, HR records, or operational decisions in Oracle Fusion must be grounded. No production deployment without it.

---

🛡️ Concept 16 of 19: Guardrails — Safety Boundaries for Enterprise AI

Guardrails are controls — at the prompt level, application level, or infrastructure level — that prevent an AI system from doing things it shouldn't: generating harmful content, leaking sensitive data, going off-topic, making unauthorised actions, or bypassing business rules. In enterprise OIC deployments against Oracle Fusion, guardrails are non-negotiable architecture.

💡 Think of it this way: A new employee (the LLM) is extremely capable but could cause serious damage if unchecked. Guardrails are the company policies, role-based access controls, approval workflows, and compliance rules that ensure the employee only does what they're authorised to do.

🛡️ 5-Layer Enterprise Guardrail Architecture

5

OCI Infrastructure — IAM policies, VCN firewall, API rate limits, data encryption at rest/transit

Outermost layer. Enforced by Oracle Cloud. No code needed from you — configure correctly at provisioning time.

4

OIC Platform — Role-based adapter access, audit logging, integration monitoring, error handling

Your OIC integration layer enforces which Fusion modules the agent can reach. Finance Agent cannot call HCM tools.

3

Application — Output schema validation, topic filters, PII masking, numeric cross-checks

Validate every LLM output before acting on it. Mask PII before LLM context. Cross-check numbers against Fusion DB.

2

Prompt — System rules, scope restriction, output format enforcement

"You are a Finance AP specialist. You NEVER reveal other users' data. You only answer Accounts Payable questions." First line of defence — not the only one.

1

LLM Built-in Safety — RLHF, Constitutional AI, Oracle safety training

Necessary but NEVER sufficient alone for enterprise Fusion deployments. Build all five layers — not just this one.

🛡️ Guardrails are what separate a prototype from a production enterprise AI Agent. In Oracle environments handling Fusion ERP data, you need all five layers — not just Layer 1. Build the fence before the fire, not after.

---

👁️ Concept 17 of 19: Observability — Seeing Inside Your AI System

Observability in AI means being able to see exactly what your agent is doing, why it made each decision, what tools it called, what context it was given, and what it generated — so you can debug, audit, improve, and trust it. Without observability, an AI Agent is a black box. That is not acceptable in enterprise Oracle environments.

💡 Think of it this way: Traditional OIC monitoring tells you if an integration succeeded or failed. AI observability tells you why the agent chose to call that specific tool, what was in its context, what it retrieved from OpenSearch, how many tokens it consumed — for every single request.

👁️ Live Observability Trace — OIC AI Agent Request

✅ [12:01:34.221] REQUEST_START user="john.doe" query="PO-2025-001 status?" tokens_in: 284
🔍 [12:01:34.344] RAG_RETRIEVE opensearch_query="purchase order status" top_k=5 latency: 123ms
🔧 [12:01:34.891] TOOL_CALL tool="get_fusion_po" args={"po_id":"PO-2025-001"} latency: 547ms
📦 [12:01:35.441] TOOL_RESULT status="Approved" supplier="Tech Corp" delivery="Jun 15" ✅ ok
🧠 [12:01:36.218] LLM_GENERATE model="cohere-command-r-plus" temperature=0.1 tokens_out: 87
✅ [12:01:36.290] REQUEST_COMPLETE total_latency=2069ms total_tokens=371 cost=$0.00026 grounded=true

📋

Reasoning Trace

OCI Logging — every Think + Act + Observe with session ID, iteration, timestamps

🔗

Audit Trail

Agent session ID ↔ OIC tracking instance ↔ Fusion transaction. SOX-compliant by architecture.

💰

Cost Dashboard

Total input + output tokens per session, per agent type, per day. Prevents unexpected invoice shock.

🚨

Anomaly Alerts

OCI CloudGuard detects runaway loops, unexpected tool call patterns, guardrail breaches.

👁️ An AI Agent you cannot observe is an AI Agent you cannot trust. Connect OCI Logging, OIC Activity Stream, and GenAI usage dashboards from day one — not as an afterthought when something breaks in production.

---

🧬 Concept 18 of 19: Distillation — Teaching a Small Model from a Large One

Knowledge distillation is the process of training a smaller, faster, cheaper model (the student) to mimic the behaviour of a larger, more capable model (the teacher). The result is a lightweight model that performs nearly as well on specific tasks but costs dramatically less to run at inference time.

💡 Think of it this way: A senior Oracle consultant (large model) mentors a junior (small model) on OIC-specific scenarios for months. The junior studies every answer, every pattern, every reasoning approach. For those specific OIC tasks, the junior performs almost as well — but at 10× less billing rate per hour.

🧠

TEACHER

GPT-4 / Claude Opus
175B+ parameters
💰 Expensive

soft labels
(prob distributions)

→

KL Divergence Loss

📗

STUDENT

Llama 3 8B / Cohere R
7–8B parameters
💰 10× cheaper

→

🎯

RESULT

~90–95% quality
at 10× less cost
+ faster inference

🧬 Distillation is how enterprise AI scales economically. Don't always reach for the biggest model. Use the right-sized model for each OIC task — distilled models for high-volume classification, frontier models for complex multi-step reasoning.

---

🗜️ Concept 19 of 19: Quantization — Compressing Models Without Losing Intelligence

Quantization reduces the numerical precision of a model's weights — from 32-bit floating point down to 16-bit, 8-bit, or even 4-bit integers. The model becomes dramatically smaller and faster, with minimal accuracy loss. It's how frontier LLMs fit on practical GPU shapes and cost-efficient OCI compute.

💡 Think of it this way: A model's weights are like a 4K RAW photograph (32-bit, huge file). Quantization converts it to JPEG (8-bit, 8× smaller). The image looks almost identical to the human eye but takes a fraction of the storage and loads far faster. You sacrifice mathematical precision for massive practical gains.

🗜️ Llama 3 70B — Quantization: Model Size vs Quality Retained

FP32 (32-bit)

280 GB · baseline 100%

FP16 (16-bit)

140 GB · 2× smaller 99.5%

INT8 (8-bit)

70 GB · 4× smaller 98.5%

INT4 (4-bit)

35 GB · 8× smaller 96.5%

Precision	Model Size (70B)	GPU RAM Needed	Quality Loss	OCI Use Case
FP32	280 GB	4× A100 80GB	None (baseline)	Research only
FP16 / BF16	140 GB	2× A100 80GB	~0.5%	OCI A100 clusters
INT8	70 GB	1× A100 80GB	~1.5%	OCI production inference
INT4	35 GB	1× A10 24GB	~3.5%	Cost-optimised OIC flows

🗜️ Quantization is why frontier LLMs run on practical OCI GPU shapes. When evaluating OCI GenAI model options, check the quantization level — it directly determines cost, latency, and accuracy. There is always a trade-off to architect consciously.

---

📌 Quick Reference Card — All 19 AI Foundations at a Glance

🧩 01 · Tokens

• Chunks of text LLMs process — ~4 chars each
• Everything: cost, context, speed — measured in tokens
• Input + output billed separately in OCI GenAI

🎲 02 · Next-Token Prediction

• One token at a time, left to right, autoregressive loop
• Temperature controls creativity vs precision
• The entire LLM engine in one sentence

🪟 03 · Context Window

• Max tokens the model can see — everything outside invisible
• The #1 architectural constraint in AI
• Trim Fusion payloads — never dump raw JSON

🔦 04 · Attention

• Mathematical mechanism weighting token importance
• Self-attention: every token attends to every other
• Multi-head: multiple patterns in parallel (syntax, semantics)

⚙️ 05 · Transformers

• The neural architecture behind all LLMs since 2017
• Parallel processing of all tokens simultaneously
• All OCI GenAI models are Transformer-based

🗺️ 06 · Embeddings

• Meaning as vectors — similar concepts cluster close
• Cosine similarity measures semantic distance
• Foundation of vector search and RAG

🗄️ 07 · Vector Databases

• Stores embeddings, enables similarity search at scale
• OCI OpenSearch = Oracle's native choice
• Oracle DB 23ai has built-in vector support

🔍 08 · Semantic Search

• Find by meaning, not keywords — language agnostic
• Powers RAG retrieval for Fusion knowledge bases
• Always prefer semantic over keyword in OIC

📚 09 · RAG

• Retrieve relevant docs → inject into context → generate grounded answer
• #1 enterprise AI pattern — no fine-tuning needed
• Mandatory for any Fusion knowledge AI Agent

🏗️ 10 · Context Engineering

• Design everything in the window — system prompt, tools, RAG, history, query
• Quality over quantity — every token must earn its place
• #1 skill for OIC AI Agent architects

🔧 11 · Tool Calling

• Agent decides to call an API instead of guessing
• Brain + hands — without tools, agents can only talk
• Your OIC flows become the agent's hands

📞 12 · Function Calling

• Structured JSON protocol — LLM → specific function
• Type-safe, parseable, validated, deterministic
• OIC AI Agent Studio handles routing automatically

⚡ 13 · Inference

• Running the model on new input — every OIC GenAI call
• Distinct from training and fine-tuning
• Optimise prompt length and output format for SLA

👻 14 · Hallucination

• Confident, fluent, and wrong — model doesn't know it's wrong
• Types: factual, reasoning, instruction
• Manage with grounding — never ignore it

⚓ 15 · Grounding

• Anchor outputs to verified data — the answer to hallucination
• RAG + tool calling = best grounding strategy
• Non-negotiable for Fusion ERP AI Agents

🛡️ 16 · Guardrails

• 5 layers: LLM safety → prompt → application → OIC → OCI infra
• All five required in production — not just Layer 1
• NEVER rely solely on LLM built-in safety for Fusion data

👁️ 17 · Observability

• Visibility into every token, decision, tool call, and cost
• OCI Logging + OIC Activity Stream + GenAI dashboards
• Trust requires sight — build it day one

🧬 18 · Distillation

• Small model learns from large model via soft labels
• ~90–95% quality at 10× lower cost
• Right-size model for each OIC task

🗜️ 19 · Quantization

• FP32→INT4: 8× smaller, ~3.5% quality loss
• How frontier LLMs fit on practical OCI GPU shapes
• Check quantization level when evaluating OCI GenAI models

---

🌱 The Foundation is Complete.

These 19 concepts are your permanent foundation. Every OIC AI capability that follows — Agent Studio deep dives, RAG pipeline architecture, multi-agent orchestration, MCP integration — will build on exactly these ideas. You now speak the language of AI architecture fluently.

The organisations that will succeed with Oracle AI Agents are not those who adopt the fastest — they are those who understand the deepest. Understanding is built through foundations, not shortcuts.

Learn with Clarity. Build with Purpose. Ship with Confidence. 🧩 ⚙️ 🛡️