Large Language Models
A comprehensive course note on large language models from language modeling and Transformer architecture through pre-training, post-training, RAG, fine-tuning, reasoning, tool use, agents, security, evaluation, and production engineering, connected to other AI paradigms.
Large language models (LLMs) are neural language models trained at substantial scale in data, parameters, and computation, most commonly within the Transformer family. There is no permanent parameter threshold that defines “large”; the term moves with hardware, model design, and training practice. A model should therefore be characterized not only by parameter count, but also by architecture, data, context length, post-training, inference cost, and task scope.
LLMs are not the whole of artificial intelligence. Artificial Neural Networks and Learning Models provides the neural-network foundation; Statistical Learning and Machine Learning supplies the language of probability, generalization, distribution shift, and evaluation; Logic Programming and Prolog provides explicit rules and formal inference; Fuzzy Logic models graded concepts through membership functions; Genetic Algorithms and Their Applications covers derivative-free stochastic search. Artificial Intelligence: Philosophy, Theory and Practice provides the broader framework needed to distinguish language generation, reasoning, understanding, agency, autonomy, and consciousness.
Statistical learning ----> probability, generalization, measurement
| |
v v
Neural networks --------> Transformer ----> Large Language Model
| |
| +--> RAG / tools / agents
| +--> fine-tuning / preference learning
| +--> multimodal systems
|
Logic programming ------> verification / symbolic tools
Fuzzy logic ------------> graded decision layers
Genetic algorithms -----> search / tuning / optimization
AI philosophy ----------> understanding, agency, autonomy, responsibilityUnit 1: From Language Modeling to Large Language Models
1.1 What is a language model?
A language model estimates the probability of a sequence or the conditional probability of the next unit in a sequence. For an autoregressive model:
P(x1, x2, ..., xT) = Π P(xt | x1, ..., x(t-1))
This factorization turns generation into repeated conditional probability estimation. At each step the model produces a distribution over the next token, a token is selected, appended to the context, and the process continues.
The objective immediately exposes an important limitation: high model probability is not the same as truth. A model optimizes the objective it was trained on. Establishing that a proposition is factually correct, formally valid, or supported by a source is a separate problem. Fluency, factuality, provenance, and logical validity must not be collapsed into one concept.
1.2 From statistical to neural language models
Classical n-gram models estimate the next item from a bounded history. They are simple and interpretable, but suffer from sparse data and limited context. Neural language models replace discrete table lookup with learned continuous representations so that related contexts can share parameters.
RNNs and LSTMs process variable-length sequences but make long-distance dependencies and large-scale parallel training difficult. Attention permits direct interactions among positions. The 2017 Transformer architecture removed recurrence as a mandatory sequencing mechanism and became the dominant architectural lineage for modern LLMs.
1.3 Base model, chat model, reasoning model, and agent are different layers
Terminology matters in system design:
- Base model: a generally pre-trained model before task-specific behavioral adaptation.
- Language model: a model of probability distributions over language sequences.
- Instruction-tuned model: a model post-trained to follow user instructions more reliably.
- Chat model: an instruction model adapted to conversational roles and multi-turn interaction.
- Reasoning model: a model or inference configuration optimized to spend additional computation on multi-step problem solving.
- Agent: a larger software system that combines a model with state, memory, tools, permissions, and an action loop.
- Multimodal model: a model that processes text together with images, audio, video, or other modalities.
This separation prevents capabilities provided by search, tools, application code, or orchestration from being incorrectly attributed to the core model.
Unit 2: Tokenization, Vocabulary, and Representation
2.1 Why tokens are needed
Neural models do not consume semantic concepts directly from raw strings. Text is first mapped to numeric token identifiers. A token may be a word, subword, character, byte sequence, or another learned unit. BPE, WordPiece, and unigram tokenization are common subword approaches.
Text
|
v
Normalization
|
v
Tokenization ---> token IDs
| |
v v
Vocabulary embedding table
|
v
dense vectorsTokenization is not merely preprocessing. Context windows and billing or resource estimates are measured in tokens, so identical meaning may have different costs under different tokenizers. Agglutinative languages such as Turkish can split into more subword pieces depending on vocabulary design. Production evaluation should measure token efficiency on the actual languages and domains being served.
2.2 Language-specific normalization
For Turkish, the I/ı and İ/i distinction, Unicode normalization, suffix chains, proper names, and mixed technical vocabulary matter. If training, indexing, and inference normalize text differently, the system can waste context and reduce retrieval quality.
Useful measurements include:
- tokens per character,
- tokens per word,
- fragmentation of domain terms,
- behavior on abbreviations and code fragments,
- Turkish-versus-English token cost for equivalent content,
- truncation rate in long documents.
2.3 Embeddings
Token IDs are mapped through learned embedding tables to dense vectors. These vectors are not dictionary definitions; they are distributed numerical representations optimized for the training objective. Contextual meaning emerges through subsequent Transformer layers.
Embedding models used for retrieval are a related but distinct concept. A document embedding used in RAG should not be confused with the internal token embedding of a generative model.
2.4 Position and context windows
Attention alone does not encode sequence order. Models therefore add absolute, relative, or rotary positional information. RoPE-style approaches are common in modern decoder architectures.
A context window is the number of tokens that can be processed in one request; it is not persistent memory. A model that technically accepts a long context may still use different regions of that context unevenly. Long-context evaluation must test where relevant information appears and how reliably it is recovered.
Unit 3: Transformer Architecture
3.1 Self-attention
Given an input representation X, learned matrices project it into queries, keys, and values:
Q = XWQ
K = XWK
V = XWV
Scaled dot-product attention is:
Attention(Q,K,V) = softmax(QK^T / sqrt(dk)) V
Each query position assigns weights to allowed key positions and combines the corresponding values. Autoregressive decoders apply a causal mask so that future tokens cannot be observed during next-token prediction.
Token vectors
|
+------> Q
+------> K ----+
+------> V |
v
Q K^T / sqrt(d)
|
softmax
|
v
weighted V sum
|
v
attention output3.2 Multi-head attention
A single attention head would learn all relationships in one projection space. Multi-head attention uses multiple projections and combines their outputs. For inference efficiency, Multi-Query Attention and Grouped-Query Attention reduce the number of independent key/value heads and therefore the cost of the KV cache.
3.3 The Transformer block
Implementation details vary, but the block can be understood as:
x
|
+--> normalization --> attention --> +
| |
+------------------------------------+ --> h
|
+--> normalization --> MLP --> +
| |
+------------------------------+ --> yResidual connections improve information and gradient flow. The MLP/FFN applies learned token-wise transformations and nonlinear activations. LayerNorm or RMSNorm-style normalization contributes to training stability.
3.4 Encoder, decoder, and encoder-decoder
- Encoder-only: bidirectional representation of an input; suitable for classification and representation tasks.
- Decoder-only: causal next-token generation; the dominant design for current generative LLMs.
- Encoder-decoder: separately encodes a source sequence and generates a target sequence; natural for translation and transformation tasks.
BERT-like encoders and GPT-like decoders belong to the same Transformer family but use different objectives and inference patterns.
3.5 Mixture of Experts
Mixture-of-Experts (MoE) models route each token to a subset of feed-forward experts rather than executing all expert parameters for every token. This can raise total parameter count while keeping active computation per token more limited. The trade-off is greater routing, load-balancing, communication, and distributed-training complexity.
Unit 4: Pre-training, Data, and Scaling
4.1 The pre-training pipeline
Architecture alone does not determine model quality. The data pipeline is equally important.
raw sources
|
v
license / provenance / access review
|
v
parsing and normalization
|
v
quality filters ----> privacy / safety filters
|
v
deduplication
|
v
language and domain balancing
|
v
tokenization
|
v
pre-trainingWeb text, books, code, scientific literature, transcripts, and enterprise documents follow different distributions. Source mixing changes learned behavior. Heavy duplication can increase memorization and benchmark leakage; low-quality automatically generated text can distort the training distribution.
4.2 Provenance and licensing
“Publicly accessible” does not imply permission for any form of model training or redistribution. A production data pipeline should track provenance, license, usage terms, personal-data status, deletion requirements, and redistribution rights. Dataset versions should be reproducible in the same way as software dependencies.
4.3 Training loss
A typical autoregressive objective minimizes the negative log-probability of the correct next token:
L = - Σ log Pθ(xt | x<t)
Perplexity is often expressed as:
PPL = exp(L_mean)
Perplexity is useful under the same tokenization and evaluation distribution. It is not a universal ranking metric for models that use different vocabularies or datasets.
4.4 Scaling laws
Model size, token count, and compute budget must be considered together. The Chinchilla work showed that, under a fixed compute budget, simply increasing parameter count can be suboptimal and that model size and training tokens should be balanced. The practical lesson is to seek a sufficiently trained model for the available compute rather than merely the largest model.
Scaling laws are empirical. Their coefficients should not be assumed invariant across architectures, tokenizers, data quality, or post-training methods.
4.5 Distributed training
Large models combine several parallelization strategies:
- data parallelism,
- tensor/model parallelism,
- pipeline parallelism,
- sequence/context parallelism,
- expert parallelism for MoE.
Mixed precision, gradient accumulation, activation checkpointing, and optimizer-state sharding reduce memory requirements. At cluster scale, network bandwidth and collective communication can become as important as raw accelerator FLOPs.
Unit 5: Post-training and Behavioral Adaptation
Pre-training develops broad statistical capabilities. Reliable instruction following is a separate objective, so modern models often pass through multiple post-training stages.
pre-trained base model
|
v
supervised instruction tuning (SFT)
|
+----------------------+
| |
v v
preference data safety data
| |
v |
RLHF / DPO / related preference methods
|
v
evaluation + adversarial testing
|
v
release candidate5.1 Supervised fine-tuning
SFT trains on prompt-response or task-output examples. A smaller set of high-quality, representative examples may be more valuable than a much larger weak dataset. SFT is effective for behavioral adaptation but is not always the right mechanism for continuously changing factual knowledge.
5.2 RLHF
Reinforcement Learning from Human Feedback can convert ranked model outputs into a learned reward signal and optimize the policy against it. The InstructGPT work demonstrated that increasing model size alone does not solve instruction following or user-intent alignment.
5.3 Direct preference optimization
Direct Preference Optimization (DPO) uses preference pairs to update the policy without requiring a separately trained reward model and the full reinforcement-learning loop. It is simpler operationally, but online and offline preference optimization have different distribution and stability trade-offs.
5.4 Reinforcement learning for reasoning
By 2025-2026, post-training had visibly expanded from conversational helpfulness to multi-step reasoning behavior. The DeepSeek-R1 work showed that reinforcement learning on verifiable tasks can encourage long problem-solving trajectories, while also exposing issues such as readability and language mixing that motivate additional staged training.
Improved problem-solving behavior is not evidence of consciousness. What is demonstrated is task performance under a particular training and inference regime.
Unit 6: Prompting, Context, and In-Context Learning
6.1 Prompt engineering
A prompt conditions behavior without changing model weights. System instructions, user input, examples, tool schemas, and retrieved documents may all occupy the same context window while serving different roles.
A useful prompt usually specifies:
- objective,
- relevant context,
- input boundaries,
- output format,
- success criteria,
- forbidden or high-risk behavior,
- a small number of examples where useful.
6.2 Context engineering
Production systems must decide what information reaches the model, in what order, with what trust level, and under what token budget. This includes instructions, conversation state, retrieved documents, tool results, user preferences, and workflow state.
+--> system policy
+--> user request
context builder -+--> relevant history
+--> retrieved evidence
+--> tool schemas/results
+--> workflow state
|
v
Model6.3 Zero-shot, few-shot, and in-context learning
A task given without examples is zero-shot; one or more demonstrations produce few-shot prompting. The model can infer a task pattern from context without a persistent weight update. This is often called in-context learning, but it is distinct from gradient-based training.
6.4 Sampling parameters
Temperature changes the sharpness of the token distribution produced from logits. Top-k restricts sampling to the highest k candidates; top-p keeps a dynamic set whose cumulative probability reaches a threshold. Lower temperature often narrows variation, but byte-for-byte reproducibility across hardware, kernels, or model revisions should not be assumed.
6.5 Chain-of-thought and self-consistency
Intermediate reasoning steps can help on complex tasks. Self-consistency samples multiple reasoning paths and selects a consistent answer rather than relying on one greedy path. However, a long explanation is not a proof of correctness. When deterministic verification is possible, calculation engines, tests, compilers, or symbolic solvers provide stronger evidence.
6.6 Long context is not perfect recall
Larger context windows do not guarantee uniform use of every token. The “Lost in the Middle” study showed that retrieval performance can depend strongly on where relevant information appears. Blindly appending entire document collections is therefore weaker than task-oriented retrieval, chunking, hierarchy, and context selection.
Unit 7: Retrieval-Augmented Generation — RAG
RAG combines a language model with external information retrieved at inference time. It is especially valuable for changing, private, or domain-specific knowledge.
document corpus
|
v
chunking -> embeddings -> index
|
user query -> query embedding
|
v
candidate retrieval
|
rerank
|
v
selected evidence
|
v
LLM
|
v
grounded response7.1 Pipeline stages
- source ingestion and provenance
- parsing and normalization
- chunking
- embedding
- vector or hybrid indexing
- query transformation
- retrieval
- reranking
- context construction
- generation with evidence references
7.2 Chunking
Fixed-size chunks are simple but may split headings, code, or tables. Structural, semantic, and sliding-window chunking can preserve more useful boundaries. Small chunks risk losing context; large chunks can reduce retrieval precision and waste the context budget.
7.3 Dense, sparse, and hybrid retrieval
Dense retrieval uses semantic embeddings; sparse retrieval uses lexical matching. Identifiers, error codes, names, and technical strings may require exact lexical signals, so hybrid retrieval can outperform purely dense search in engineering systems.
7.4 What RAG does not solve
RAG does not change model weights. It also does not automatically solve authorization, hallucination, or prompt injection. A malicious retrieved document can itself become an instruction source. Access control must be enforced during retrieval using the authenticated user's permissions rather than delegated to model instructions.
7.5 Provenance
A trustworthy system records which source version and passage influenced an answer. Document identity, version, section, and access time make later audit and correction possible.
Unit 8: Fine-Tuning and Parameter-Efficient Adaptation
8.1 Full fine-tuning
Full fine-tuning updates all or a large fraction of model parameters. It requires substantial accelerator memory and optimizer state. It can strongly adapt behavior but can also overfit small datasets or reduce general capabilities.
8.2 LoRA
Low-Rank Adaptation freezes base weights and learns low-rank updates. A weight update can be represented conceptually as:
ΔW = B A
where the rank is much smaller than the dimensions of the original weight matrix. Only a relatively small set of adaptation parameters needs to be trained.
8.3 QLoRA
QLoRA stores the frozen base model in a low-bit quantized form while training LoRA adapters. This makes adaptation of large models possible under much smaller memory budgets. The quality trade-off must still be measured for the target workload.
8.4 Choosing the mechanism
| Need | Primary mechanism | |---|---| | Output format or short behavior change | Prompt / few-shot | | Fresh or private knowledge | RAG | | Domain style or repeated task behavior | SFT / LoRA | | Preference alignment | Preference optimization | | Exact calculation or explicit rules | External tool / symbolic system | | Frequently changing enterprise data | RAG + access control | | Edge or memory-constrained deployment | Smaller model + quantization/distillation |
These mechanisms can coexist in one production system.
Unit 9: Reasoning and Test-Time Compute
Model quality can be improved not only through more pre-training but also by allocating additional computation at inference time: sampling several candidates, revising answers, searching over intermediate states, or scoring candidates with a verifier.
9.1 Test-time compute
Test-time compute means increasing the computation spent on a request while model weights remain fixed. Best-of-N, verifier-guided search, iterative revision, and adaptive sampling are examples. Work published in 2024 showed that difficulty-aware allocation of inference compute can sometimes outperform simply choosing a much larger base model under a comparable compute budget.
This result is task-dependent. Easy and difficult prompts do not benefit equally, so latency SLOs and quality targets must be optimized together.
9.2 Verifiers
A generator proposes candidates; a separate verifier scores or validates them:
problem
|
v
generator LLM ---> candidate 1 ---+
| candidate 2 ----+--> verifier --> selected answer
+--------> candidate N ----+The verifier may be a calculator, test runner, compiler, database query, Prolog/SMT solver, or another model. When formal verification is possible, it is stronger than free-form self-critique.
9.3 Reasoning is not consciousness
Solving a multi-step problem does not establish subjective experience. Observable task behavior and philosophical claims about consciousness are separate questions, examined more broadly in Artificial Intelligence: Philosophy, Theory and Practice.
Unit 10: Tool Use and Agent Systems
An LLM does not directly “have access” to a database or filesystem. Application code turns model output into validated tool calls. In a secure architecture, the model is not an authority source; it is a component proposing actions.
User
|
v
Orchestrator ----> policy / authorization
| |
v v
LLM ---- tool request --> validator
^ |
| v
+------ tool result --- tool / API / DB10.1 Tool calling
Tool calling uses a tool schema that defines a name, parameters, and expected result. The model may choose a tool and arguments, but argument validation, authentication, authorization, rate limits, idempotency, and transaction safety remain application responsibilities.
10.2 Agent loop
A practical agent follows a loop such as:
observe -> plan -> act -> receive result -> update state
Production systems must also define timeouts, maximum steps, budgets, cancellation, rollback, and human approval.
10.3 ReAct and Toolformer
ReAct interleaves reasoning with actions in an external environment. Toolformer demonstrated a training approach for learning when and how APIs should be called. These works form part of the historical foundation for modern tool-using LLM systems.
10.4 Tool protocols
By 2026, protocols for standardizing the connection between models and tools had become more visible. Model Context Protocol (MCP) is one example; its 2026-07-28 specification introduced a stateless protocol core, an extensions framework, and authorization hardening. Such protocols belong to the integration layer rather than the neural model itself.
10.5 High-risk actions
Financial transfer, permanent deletion, privilege changes, command execution, and safety-critical operations should not depend solely on model output. Human-in-the-loop approval, two-phase confirmation, or deterministic policy enforcement should be used where consequences are material.
Unit 11: Multimodal Large Models
Text-centric LLMs can be combined with image, audio, or video encoders:
text ---> tokenizer ---------------------+
|
image --> vision encoder --> projector ---+--> joint representation --> language model --> output
|
audio --> audio encoder ---> projector ---+Depending on the architecture, modality features are converted into vectors compatible with the language model. Multimodality expands capability but also expands the failure surface: OCR errors, hidden instructions in images, transcription mistakes, temporal alignment errors, or cross-modal prompt injection can propagate into the language output.
Unit 12: Evaluation
12.1 One benchmark is not enough
LLM evaluation is multi-layered:
Model level : loss, perplexity, broad benchmark scores
Task level : accuracy, F1, exact match, pass@k
RAG level : retrieval recall, ranking, groundedness
Agent level : task success, step count, invalid tool calls
System level : TTFT, token/s, errors, cost, resource use
Security level : injection, leakage, privilege abuse, adversarial tests12.2 Benchmark contamination
If evaluation examples appeared in training data, the measured score may partly reward memorization. Time-separated datasets, private test sets, transformed variants, and overlap analysis are useful mitigations.
12.3 LLM-as-a-Judge
A strong model can score another model's output and scale open-ended evaluation, but judge models exhibit position bias, verbosity preference, self-enhancement, and reasoning limitations. The evaluator is itself a model that requires validation.
12.4 Domain evaluation
A production system benefits from a versioned golden set drawn from its real request distribution. Difficult slices should include missing evidence, contradictory documents, long context, code, tables, non-English text, tool failures, and unauthorized-data requests.
12.5 Statistical confidence
Small benchmark differences may not be meaningful. Sample size, confidence intervals, and repeated measurements should be considered. These principles directly connect to Statistical Learning and Machine Learning.
Unit 13: Hallucination, Uncertainty, and Verification
“Hallucination” is a broad label for unsupported or incorrect generation. Treating every failure as one category can hide root causes. It is more useful to separate:
- unsupported factual claims,
- misinterpretation of retrieved evidence,
- logical errors,
- arithmetic errors,
- incorrect transcription of tool results,
- failure to express uncertainty,
- instruction conflicts.
13.1 Token probability is not a reliability score
Token probabilities describe the model's local generation distribution. They are not automatically calibrated probabilities of factual correctness.
13.2 Relation to fuzzy logic
A membership degree in Fuzzy Logic measures how strongly an observation belongs to a modeled fuzzy concept. A language-model token probability measures the probability of a next token under the model distribution.
Fuzzy membership: μ_hot(26°C) = 0.7
Language probability: P(token | context) = 0.7
Same numeric range != same semanticsFuzzy logic may be useful as an explicit decision layer around an LLM, but token probabilities should not be reinterpreted as fuzzy memberships.
13.3 Verification layers
- source retrieval and citation checks,
- independent verifier models,
- deterministic calculators,
- schema/type validation,
- compilation and unit tests,
- human approval,
- domain rules.
The strongest available evidence should be used for each task.
Unit 14: Security, Privacy, and Governance
LLM applications extend the conventional web/API attack surface with a natural-language control channel. Model input and model output should both be treated as untrusted data.
14.1 Prompt injection
Prompt injection occurs when user content or external data causes the model to follow unintended instructions. It can be direct, through the user's prompt, or indirect, through documents, web pages, email, retrieved content, images, or other external sources.
OWASP Top 10 for LLM Applications 2025 lists prompt injection as a primary risk. RAG and fine-tuning do not eliminate it.
14.2 Trust boundary
[Untrusted]
User / Web / File / RAG document
|
v
content parsing
|
v
LLM
|
v
proposed action
|
+------v-------+
| Policy | <-- trust boundary
| Authorization|
| Validation |
+------|-------+
v
real toolThe statement “I am authorized” from a model is not authorization. Identity and access control must be enforced in deterministic application code.
14.3 System prompts are not secrets
System instructions may guide behavior but should not contain passwords, API keys, connection strings, or authorization decisions. Security should remain intact even if prompt text becomes visible.
14.4 Output handling
LLM output that contains HTML, SQL, shell commands, or code should not be executed directly. Parameterized queries, allowlists, sandboxing, AST validation, schema checking, and least privilege remain necessary.
14.5 Poisoning and supply chain
Pre-training data, fine-tuning datasets, embedding models, tokenizers, weights, conversion tools, and runtime libraries are part of the supply chain. Model artifacts should have known provenance, versions, hashes, and licenses.
14.6 Risk management
NIST AI RMF and its Generative AI Profile treat risk across the lifecycle rather than as one benchmark score. High-impact systems should document data provenance, human oversight, use boundaries, incident handling, rollback, and monitoring.
Unit 15: Inference, Performance, and Serving Engineering
A production LLM is constrained by latency, throughput, memory, energy, and queueing behavior as well as output quality.
15.1 Memory components
A simplified budget is:
total ≈ model weights + KV cache + activations + runtime workspace
Training additionally requires gradients and optimizer states.
15.2 Prefill and decode
input tokens ----[prefill]----> first token
|
+--[decode]--> token 2
+--[decode]--> token 3
+--[decode]--> ...Prefill processes the prompt in parallel and is often compute-intensive. Decode generates output autoregressively and frequently becomes memory-bandwidth-sensitive because each new token must access model weights and cached attention state.
15.3 Operational metrics
- TTFT: time to first token
- TPOT: time per output token
- tokens/s: generation speed
- throughput: completed requests or tokens per unit time
- P50/P95/P99 latency: tail behavior
- goodput: useful work that satisfies the service-level objective
Average latency alone can hide severe tail behavior.
15.4 KV cache
Autoregressive decoding stores prior key/value tensors so that previous attention state is not recomputed from scratch. The cache grows with context length and concurrency. GQA/MQA, cache quantization, and paged memory management can reduce pressure.
15.5 FlashAttention
FlashAttention preserves exact attention results while reducing data movement across the GPU memory hierarchy. The systems lesson is that FLOP count alone does not determine latency; HBM/SRAM traffic can dominate wall-clock performance.
15.6 PagedAttention and continuous batching
PagedAttention manages KV-cache blocks using a paging-like abstraction to reduce fragmentation. Continuous batching admits new requests as previous requests finish rather than waiting for a static batch to drain, improving accelerator utilization under variable-length workloads.
15.7 Speculative decoding
A smaller draft model proposes several tokens; the larger target model validates them in parallel. Under favorable conditions this reduces decoding latency while preserving the target distribution.
15.8 Quantization
Weights represented in FP16/BF16 can be converted to INT8, INT4, or other lower-precision forms. This can reduce memory and improve effective bandwidth, but the quality effect is workload- and kernel-dependent. Quantization must be benchmarked on the actual target tasks.
Unit 16: Connections to Other AI Paradigms
16.1 Neural networks
An LLM is a large-scale instance of the concepts discussed in Artificial Neural Networks and Learning Models: weights, activations, loss functions, backpropagation, optimization, overfitting, and distribution shift all remain relevant. The Transformer is not a separate category of intelligence outside neural-network learning.
For the earlier historical treatment, Artificial Intelligence and the Artificial Neural Network Approach is also complementary.
16.2 Statistical learning
Statistical Learning and Machine Learning provides the conceptual basis for empirical risk, generalization, data distribution, and fair model comparison. Scale does not remove sampling bias or distribution shift.
16.3 Fuzzy logic
Fuzzy Logic provides explicit membership functions for graded concepts such as “high risk” or “near.” An LLM can learn how such expressions are used in language, but its hidden representations are not an explicit fuzzy rule base. In a hybrid system, an LLM may extract features while a fuzzy controller applies transparent domain rules.
16.4 Genetic algorithms
Genetic Algorithms and Their Applications can optimize derivative-free or discrete choices around an LLM: prompt templates, retrieval parameters, tool ordering, model ensembles, or multi-objective cost-quality trade-offs. Directly evolving billions of model weights is generally not the practical training strategy for modern LLMs.
16.5 Logic programming
Logic Programming and Prolog performs explicit reasoning over facts and rules. An LLM can propose structured facts, rules, or queries; a symbolic engine can validate them:
natural language
|
v
LLM ---> candidate facts / rules / query
|
v
Prolog / SMT / rules
|
validated result
|
v
LLM
|
v
explained answerThis separates generative flexibility from formal verification.
16.6 AI and philosophy
Artificial Intelligence: Philosophy, Theory and Practice supplies category boundaries that remain essential in LLM discussions:
- language generation != truth,
- problem solving != consciousness,
- tool use != independent goals,
- human-like expression != human subjective experience,
- benchmark performance != universal reliability.
Unit 17: Turkish and Domain Adaptation
17.1 Evaluate the target language directly
High English benchmark scores do not guarantee high-quality Turkish behavior. Evaluation should test agglutinative morphology, idioms, domain terminology, proper names, I/İ/ı/i handling, number/date conventions, formal versus colloquial language, and mixed Turkish-English technical text.
17.2 Choose the adaptation mechanism by problem type
A domain system may fail because:
- terminology is poorly represented,
- knowledge is stale,
- behavioral format is wrong.
These do not have the same solution. Terminology or style may motivate SFT/LoRA; fresh knowledge motivates RAG; external actions motivate tool integration.
17.3 Confidentiality
Fine-tuning confidential documents into model weights is not equivalent to keeping those documents in an access-controlled retrieval store. If access differs by user, retrieval-time authorization is often easier to audit than encoding all knowledge into shared weights.
Unit 18: Production Architecture
A prototype may use prompt -> model -> response. A production system should separate responsibilities.
+-------------------+
User ------------->| API / Session |
+---------+---------+
|
+--------v--------+
| Policy / ACL |
+--------+--------+
|
+--------------+--------------+
| |
+-------v-------+ +-------v-------+
| Context / RAG | | Tool registry |
+-------+-------+ +-------+-------+
| |
+--------------+--------------+
|
+------v------+
| LLM |
+------+------+
|
+------v------+
| Output |
| validation |
+------+------+
|
+---------------+---------------+
| |
user tool/action18.1 Versioning
Version separately:
- model and weight hash,
- tokenizer,
- system prompt,
- retrieval index,
- embedding model,
- reranker,
- tool schemas,
- safety policy,
- evaluation set.
A system can change behavior even when the neural model is unchanged.
18.2 Observability
Privacy-preserving telemetry can track request class, input/output token count, TTFT, TPOT, retrieval scores, tool calls, failure class, model/prompt version, and safety-filter result. Logging the entire user conversation is not always necessary.
18.3 Fault tolerance
Model servers, vector databases, and external tools can fail. Conventional distributed-system patterns still apply: timeouts, bounded retries, circuit breakers, fallback models, load shedding, queue limits, and graceful feature degradation.
Unit 19: Directions Visible by 2026
This section describes engineering trends that had become prominent by 2026 rather than timeless architectural laws.
19.1 Inference-time scaling
Modern reasoning systems increasingly allocate more computation to difficult requests using verifiers, search, or learned reasoning policies. This shifts part of the performance budget from pre-training toward inference.
19.2 Sparse expert models
MoE architectures increase total capacity while limiting active parameters per token. At scale, expert placement, all-to-all communication, and load balance become first-class systems problems.
19.3 Long context plus external memory
Longer context windows have not made RAG obsolete. Long context provides capacity; retrieval provides selection, provenance, freshness, and authorization. The two mechanisms are complementary.
19.4 Agents and protocol layers
LLMs increasingly interact with files, databases, code execution, browsers, and enterprise systems. As a result, permission boundaries, transactional safety, and tool protocols matter as much as model quality. MCP is one current standardization effort in this integration layer.
19.5 Smaller specialist models
Not every task benefits from the largest model. Distillation, quantization, and domain training can yield smaller models with lower latency, energy use, and deployment cost. Selection should be based on a measured quality-cost curve under actual traffic.
19.6 Multimodality
Text, images, audio, and video increasingly coexist in one system. This expands the evaluation and security surface: a text filter does not necessarily detect an instruction hidden in an image or audio stream.
19.7 Synthetic data and model-to-model learning
Strong models can generate training examples, preference data, or distillation targets. Synthetic data can reduce cost but can also reproduce model errors, reduce diversity, or leak benchmark patterns. External validation remains necessary.
Unit 20: Knowledge, Understanding, and System Boundaries
An LLM may encode broad factual patterns in parameters, but philosophical “knowledge” includes more than producing a correct-looking sentence. Provenance, justification, correction, and accountability matter.
A useful systems view separates three layers:
parametric model patterns
|
v
runtime context and external evidence
|
v
application verification / authorization / action layerThe model response is not automatically the system decision. In forensic, security, medical, financial, legal, or physical-control contexts, it should be explicit which decisions belong to the model, deterministic code, symbolic tools, or a human operator.
Human-like fluency can create a strong impression of understanding. For engineering purposes, observable behavior and measurable reliability should take precedence over anthropomorphic interpretation.
Unit 21: Quick Design Reference
Need fresh knowledge?
Yes -> RAG / external tool
No
|
+-> Need recurring domain behavior?
Yes -> SFT / LoRA / preference training
No
|
+-> Need exact rules or calculation?
Yes -> symbolic engine / deterministic tool
No
|
+-> Is task specification the main gap?
Yes -> prompt / in-context examplesBefore production release
- Is the task boundary explicit?
- Is there a private or closed evaluation set?
- Have Turkish and domain-specific cases been tested?
- Is retrieval authorization aligned with user permissions?
- Is model output treated as untrusted input to downstream systems?
- Do tools use least privilege?
- Are prompt-injection scenarios tested?
- Are model, tokenizer, prompt, and index versions recorded?
- Are P95/P99 latency and throughput measured?
- Is long-context and KV-cache memory budgeted?
- Is fallback behavior defined?
- Do high-risk actions require human or deterministic approval?
Conclusion
The most useful way to understand LLMs is not as isolated “intelligent chatbots,” but as systems that combine statistical learning, large neural networks, data engineering, distributed training, inference infrastructure, retrieval, verification, and security.
The Transformer supplies the neural core. Pre-training learns broad language patterns; post-training shapes instruction and preference behavior; RAG provides external knowledge; tools connect the model to actions; evaluation and security define operational boundaries.
This view also makes older AI paradigms complementary rather than obsolete. Neural networks learn representations; statistical learning provides measurement discipline; fuzzy logic models graded concepts explicitly; genetic algorithms provide derivative-free search; logic programming provides formal rules and verification. An LLM can serve as a natural-language interface and generative component between these methods without replacing them.
References
Core books
- Pere Martra. Large Language Models Projects: Apply and Implement Strategies for Large Language Models. Apress, 2024. ISBN 979-8-8688-0515-8.
- Raj Arun R. Mastering Large Language Models with Python. Orange Education, 2024. ISBN 9788197081828.
- John Atkinson-Abutridy. Large Language Models: Concepts, Techniques and Applications. CRC Press, 2024. DOI: https://doi.org/10.1201/9781003517245
- Morteza SaberiKamarposhti. Building Large Language Models (LLM): A Step-by-Step Guide to Practical LLM Development. 2024.
Foundational and current technical work
- Ashish Vaswani et al. “Attention Is All You Need.” NeurIPS, 2017. https://arxiv.org/abs/1706.03762
- Jordan Hoffmann et al. “Training Compute-Optimal Large Language Models.” 2022. https://arxiv.org/abs/2203.15556
- Edward J. Hu et al. “LoRA: Low-Rank Adaptation of Large Language Models.” ICLR, 2022. https://arxiv.org/abs/2106.09685
- Tim Dettmers et al. “QLoRA: Efficient Finetuning of Quantized LLMs.” NeurIPS, 2023. https://arxiv.org/abs/2305.14314
- Patrick Lewis et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS, 2020. https://arxiv.org/abs/2005.11401
- Long Ouyang et al. “Training Language Models to Follow Instructions with Human Feedback.” NeurIPS, 2022. https://arxiv.org/abs/2203.02155
- Rafael Rafailov et al. “Direct Preference Optimization: Your Language Model is Secretly a Reward Model.” NeurIPS, 2023. https://arxiv.org/abs/2305.18290
- William Fedus; Barret Zoph; Noam Shazeer. “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity.” 2021. https://arxiv.org/abs/2101.03961
- Tri Dao et al. “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness.” NeurIPS, 2022. https://arxiv.org/abs/2205.14135
- Joshua Ainslie et al. “GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints.” 2023. https://arxiv.org/abs/2305.13245
- Woosuk Kwon et al. “Efficient Memory Management for Large Language Model Serving with PagedAttention.” SOSP, 2023. https://arxiv.org/abs/2309.06180
- Charlie Chen et al. “Accelerating Large Language Model Decoding with Speculative Sampling.” 2023. https://arxiv.org/abs/2302.01318
- Nelson F. Liu et al. “Lost in the Middle: How Language Models Use Long Contexts.” 2023. https://arxiv.org/abs/2307.03172
- Shunyu Yao et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR, 2023. https://arxiv.org/abs/2210.03629
- Timo Schick et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS, 2023. https://arxiv.org/abs/2302.04761
- Lianmin Zheng et al. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” 2023. https://arxiv.org/abs/2306.05685
- Carlos E. Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” 2023. https://arxiv.org/abs/2310.06770
- Charlie Snell et al. “Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters.” arXiv preprint, 2024. https://arxiv.org/abs/2408.03314
- DeepSeek-AI et al. “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.” arXiv preprint, 2025; revised 2026. https://arxiv.org/abs/2501.12948
Security and risk management
- NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), 2024; web edition updated in 2026. https://doi.org/10.6028/NIST.AI.600-1
- OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2025. https://genai.owasp.org/llm-top-10/
- Model Context Protocol. Specification 2026-07-28. https://modelcontextprotocol.io/
