Author Archives: krcmic.com

Embedding

Embedding is a numerical representation of content that allows a model or search system to compare meaning, not just exact wording. A text, image, document or another input is converted into a vector – a list of numbers. By comparing how close or distant these vectors are, the system can estimate whether two texts, products, images or queries are semantically related, even if they do not use the same words. This is why embeddings are a core building block of semantic search, retrieval systems, recommendation engines and many modern AI applications.

At first glance, embedding can sound abstract. People work with words, sentences, images and meaning. Computers need numerical representations they can compare mathematically. An embedding is the bridge between human content and a vector space where similarity can be measured. That is the practical reason why embeddings matter.

An embedding is a vector – a list of numbers that represents the meaning or characteristics of a piece of content. Because content is turned into vectors, a system can compare texts, queries, images or documents by semantic similarity, not only by exact keyword overlap.

What embedding really means in practice

Embedding is a way to convert content into numerical form so that a machine can work with it.

When a person reads these two questions, the relationship is obvious:

How should I deal with a late payment?
What should I do if an invoice has not been paid on time?

The wording is different, but the meaning is very close.

Traditional keyword search can struggle here. If it mainly looks for exact word overlap, it may miss a relevant document written in different language. Embeddings approach the problem differently. Both questions are converted into vectors. If those vectors end up close to each other in vector space, the system can treat them as semantically related.

Practically speaking, embeddings make it possible to search by meaning, not only by literal wording.

Why embeddings matter

Embeddings matter because most information is not written in exactly the same way users ask for it.

People phrase things differently. Documents use different terminology. One person writes late payment, another writes unpaid invoice, a third writes payment default or overdue receivable. All of these may point to the same practical issue, but exact-match search does not always connect them reliably.

That is why embeddings are important for:

semantic search,
RAG systems,
document retrieval,
recommendation engines,
finding similar products,
duplicate detection,
grouping similar texts,
internal knowledge base search,
multimodal search across text, images and documents.

Without embeddings, many modern AI systems would still depend too heavily on exact wording.

How to picture an embedding

A useful way to imagine an embedding is as coordinates in a space. Not a simple 2D map, but a high-dimensional space with hundreds or even thousands of numerical dimensions.

What matters is not one individual number on its own. What matters is the full arrangement of the vector and how close that vector is to other vectors.

If two embeddings are close, the system treats the underlying content as similar. If they are far apart, the content is probably less related.

For example:

a sentence about a damaged delivery claim may be close to a sentence about reporting shipping damage,
a sentence about a damaged delivery claim will be much further from a sentence about a pancake recipe,
a product such as a black sports backpack will be closer to other sports backpacks,
and further away from a category such as office chairs.

An embedding is not a single score or a one-number label. It is a structured vector that allows content to be compared against other content. That comparison is the main reason embeddings are used.

How embeddings differ from ordinary keyword search

Traditional search usually works primarily with the words the user enters. If someone types a phrase into a search bar, the system tries to find documents where the same or very similar terms actually appear.

That works well for precise names, codes, product IDs and structured identifiers. It works less well when the user describes a problem in everyday language but the content uses different terminology – for example a more formal phrase, an internal label or a domain-specific expression.

Example: a user searches a help centre for how to change the delivery address of an order and types:

I want to change the delivery address.

The help article might be titled:

Updating shipping details in an order

The meaning is close, but the wording is different. A person sees that immediately. Simple keyword search may not.

Embeddings solve this differently. The user query and the help articles are converted into vectors. The system then compares their semantic similarity. If the query vector is close to a document vector, the system can surface that article even when the wording does not match exactly.

That does not mean embeddings replace keyword search in every situation.

If the user is looking for an order number, EAN, SKU, VAT ID, invoice code or an exact document title, precise matching is usually better. In that case you do not want something merely similar in meaning. You want the exact record.

That is why real systems often combine both approaches – keyword or full-text search for exact queries, and embeddings for natural-language queries.

Embeddings are strong when the user describes intent in ordinary language. Full-text search is strong when the user needs an exact name, code or identifier. In practice, the best systems often combine both.

How an embedding is created

An embedding is not written manually. It is produced by an embedding model. That model takes an input and converts it into a numerical vector.

In simplified form, the process looks like this:

the system receives an input – a sentence, paragraph, document, query, product title, product description or another piece of content,
the input is prepared technically – for text, this usually includes tokenization,
the embedding model processes the input and transforms it into a vector,
the vector is stored or compared with other vectors,
when a new query arrives, the system creates a query embedding and compares it with stored embeddings,
the closest vectors are treated as the most semantically similar results.

So an embedding is not a hand-written label. It is the output of a model trained to place similar content near similar content in vector space.

What a vector actually is

A vector is simply a list of numbers.

A simplified example might look like this:

[0.12, -0.48, 0.91, 0.07, -0.33]

Real embeddings are usually much longer and can contain hundreds or thousands of values.

A person cannot look at these numbers and directly read the meaning of a text. It is not the case that one number means complaints, another means goods and a third means payment. It does not work that literally.

What matters is how the full vector compares with other full vectors. If two vectors are close, the system treats the underlying content as similar.

What embedding similarity means

Similarity between embeddings means that two pieces of content are close to each other in vector space.

There are several mathematical ways to measure this. Systems often use cosine similarity, Euclidean distance or dot product. Most readers do not need the formula. The important point is simple: the system measures closeness between vectors.

For example:

the embedding of the query How do I return an item? may be close to a document titled Procedure for withdrawal from a contract,
the embedding of the query How do I configure SPF? may be close to an article about email authentication,
the embedding of an image of a black backpack may be close to other visually similar backpack images.

A higher similarity score means a higher chance that the content is relevant. It does not prove correctness. It is a similarity estimate, not a guarantee.

Embeddings help systems find content that is semantically similar. They do not mean the system understands text in the same way a human does.

Embedding and semantic search

Semantic search means search by meaning. This is one of the most common uses of embeddings.

Traditional search tends to ask:

does the document contain the same word as the query?
does the phrase occur in the text?
does the wording match closely enough?

Semantic search asks something closer to:

is the meaning of the query similar to the meaning of the document?
does this text solve the same problem?
does this passage match the user’s intent?

That is a major difference.

If a user asks What should I do if a customer has not paid?, the system may retrieve a document called Procedure for overdue invoice payment. The exact words do not match, but the situation clearly does.

Embedding and retrieval

Retrieval means finding and loading relevant information. Embeddings are one of the key ways to improve retrieval.

A common workflow looks like this:

documents are split into smaller chunks,
each chunk is converted into an embedding,
the embeddings are stored in a search index or vector database,
the user query is also converted into an embedding,
the system compares the query vector with stored document vectors,
the most similar chunks are selected,
those chunks are passed to the language model as context.

That is often the reason an AI assistant can find the right passage in documentation even when the user asks in very different wording.

Embedding and RAG

RAG, or Retrieval-Augmented Generation, combines retrieval of relevant information with answer generation. Embeddings often power the retrieval part.

A typical example looks like this:

a company has an internal knowledge base,
each article or article chunk is embedded,
a user asks a question in natural language,
the query is embedded too,
the system retrieves the most semantically similar passages,
the language model uses those passages to generate the answer.

Without embeddings, RAG would often rely much more heavily on keyword overlap. That can work for exact phrasing, but it is weaker for flexible, human-style queries.

Embedding and vector databases

A vector database is a database designed to store embeddings and retrieve similar vectors efficiently.

A traditional database is good at exact lookups. It can find a customer by email, an order by number or a product by SKU.

A vector database answers a different type of question:

which documents are semantically similar to this query?
which products are similar to this description?
which images resemble this uploaded picture?
which records look similar to this case?

In many RAG systems, the vector database is the component that quickly finds the nearest embeddings and therefore the most relevant chunks.

Embedding and context windows

A context window defines how much information a language model can process in one step.

Embeddings help decide what should enter that limited space.

If a company has thousands of documents, it cannot send all of them to the model on every query. That would be slow, expensive and noisy. Embeddings make it possible to retrieve only the most relevant passages and place those into the model’s context.

So the model does not receive everything. It receives a smaller, more relevant subset.

Embedding and tokens

Tokens are the units language models use to process text. They matter for embeddings too, because embedding models also have input limits and costs.

If you want to embed a very long document, you usually cannot feed it as one endless block. The document must be split into smaller parts and embedded piece by piece.

This also improves quality. If an entire long document had only one embedding, the vector would often be too general. A shorter, focused passage usually has a more precise semantic representation than a huge document mixing multiple topics.

Embedding and chunking

Chunking means splitting a long text into smaller units. For embeddings, this is extremely important.

Imagine a long document that contains terms and conditions, complaints, payments, shipping and privacy information. If the whole document is turned into one embedding, the resulting vector will be too broad and too vague.

A better approach is to split it into meaningful sections:

the complaints section,
the payments section,
the shipping section,
the withdrawal section,
the privacy section.

Each section gets its own embedding. If the user asks about complaints, the system can retrieve the complaint-related chunk rather than the whole document.

Embedding and prompts

A prompt is the input or instruction given to a language model. The embedding itself is usually not what the user writes into the prompt. It is a technical layer used before the final prompt is assembled.

A common flow looks like this:

the user writes a question,
the system creates an embedding for that question,
it retrieves similar document chunks,
those retrieved passages are inserted into the prompt,
the language model generates the final answer.

So embeddings often decide what enters the prompt as context.

Embedding and large language models

A large language model generates an answer from text input and context. An embedding model has a different role. It does not generate a user-facing answer. It converts content into a vector.

The difference is simple:

embedding model – turns text or another input into a numerical vector,
language model – turns text input and context into a readable answer.

In practice, the two are often used together. The embedding model finds relevant supporting material. The language model turns that material into a readable answer.

Embedding and multimodal models

With multimodal systems, embeddings are not limited to text. An image, audio file, video, document page or another type of input can also be converted into a numerical representation.

That makes it possible to:

search for images using a text description,
find products similar to an uploaded photo,
compare documents by content,
retrieve visually similar screenshots,
connect text queries with visual content.

For example, a user might type black sports backpack with a laptop compartment. A multimodal system does not need to rely only on exact product titles. If it uses multimodal embeddings, it can retrieve visually and semantically related products even when the text labels differ.

Where embeddings are used

Embeddings are useful wherever a system needs to compare content by similarity.

Common use cases include:

semantic search,
RAG systems,
recommendation engines,
duplicate detection,
clustering similar items,
text classification pipelines,
knowledge base search,
image retrieval,
customer support search,
internal document discovery.

Embedding in e-commerce

In e-commerce, embeddings can improve product search, recommendation and intent matching.

Customers often do not search by exact product names. They write things like:

light backpack for airline travel,
running shoes for asphalt,
gift for a child who likes creative activities,
cheaper alternative to this product.

A strict keyword system may fail if the product catalogue uses different wording. Embeddings can help match the intent of the query to the meaning of the product descriptions.

They can also help find similar products based on descriptions, attributes or images.

Embedding in internal knowledge bases

In internal knowledge bases, embeddings help bridge the gap between how people ask questions and how documents are written.

An employee may ask:

Where can I find the procedure for a client who refuses to pay an invoice?

The document may be titled:

Process for handling overdue payment

Embeddings make it possible to retrieve the correct document from knowledge base by meaning even when the wording is different. That is one of the main reasons embeddings are so useful in internal AI assistants.

Embedding for documents and PDF files

For documents, embeddings are usually created chunk by chunk. Taking an entire PDF and turning it into one vector is usually too coarse.

A better process looks like this:

extract the text from the document,
split it by headings, paragraphs or meaningful sections,
create an embedding for each chunk,
store those embeddings in a search index,
retrieve only the chunks relevant to the user query.

Metadata also matters – such as document title, date, version, department or source. The embedding alone does not tell you whether a document is current, valid or authoritative.

Embedding and OCR

OCR turns text from scanned images, screenshots or PDF pages into machine-readable text. Embeddings can then work on top of that extracted text.

Example:

a company has scanned contracts,
OCR extracts the text,
the text is split into chunks,
embeddings are created for those chunks,
users can then search the contracts by meaning.

OCR helps obtain text. Embeddings help compare and retrieve that text semantically.

Embedding and clustering

Clustering means grouping similar items together. Embeddings are well suited to this because similar items usually end up near each other in vector space.

Example:

a company has thousands of customer support tickets,
each ticket is turned into an embedding,
the system groups semantically similar tickets together,
the company sees which problems appear repeatedly,
it can then improve FAQ pages, workflows or support documentation.

Clustering can reveal patterns in large datasets that would take a very long time to identify manually.

Embedding and recommendation

Embeddings are also used in recommendation systems. If articles, products, videos or documents have vector representations, the system can recommend similar items.

Example:

a user is reading an article about prompt engineering,
the system finds content with similar embeddings,
it recommends related articles about tokens, context windows or retrieval.

The same logic can be used for products, films, music or internal content.

Embedding and result quality

Embeddings are not perfect. Two vectors being close does not prove the result is correct.

A system may retrieve something that is only superficially similar. Or it may miss a highly relevant document because the wording, structure or domain language is unusual. Embeddings also do not encode things like legal priority, current validity or organisational authority unless those signals are added through other mechanisms.

That is why embeddings are often combined with:

keywords,
metadata,
document dates,
document type filters,
user permissions,
reranking,
manual rules for critical cases.

A well-designed system does not rely on embedding similarity alone.

IMPORTANT! Embeddings help find semantically similar content, but they do not guarantee correctness. If the source data is outdated, duplicated or poorly structured, the system can retrieve content that is similar in meaning but still practically wrong.

Embedding versus full-text search

Full-text search and embeddings solve a similar problem in different ways.

Full-text search is strong when precise words, names, codes and identifiers matter. Embeddings are strong when semantic similarity matters.

Example:

full-text is ideal for a query such as order 20260415-88,
embedding-based search is better for a query such as how should I handle a customer who has not paid an invoice?

In practice, a hybrid approach is often best. This is commonly called hybrid search.

Embedding versus categories

A category is a manual or automatic label such as complaints, payments, shipping, marketing or technical support.

An embedding is more fine-grained. It does not only say that two documents belong to the same category. It allows the system to compare how semantically close they are even within that category.

For example:

two documents may both belong to the complaints category,
one may be about damaged deliveries,
the other may be about returning goods without giving a reason,
their embeddings can show that they address different subtypes of complaint.

Categories help organise content. Embeddings help compare semantic proximity.

What embeddings do not do

An embedding is not full understanding. It is a mathematical representation useful for comparison.

By itself, an embedding cannot:

answer a question,
verify whether a document is true,
determine whether a source is current,
decide which source has legal priority,
replace human review in sensitive decisions,
guarantee that the retrieved result is the right one.

Those tasks require additional layers – such as metadata, business rules, retrieval logic, a language model, source citation, access control and human oversight.

Common mistakes when using embeddings

One of the most common mistakes is assuming that embedding automatically means understanding. It does not. Embeddings are mainly useful for similarity comparison.

Another common mistake is creating one embedding for a document that is far too long. The resulting vector becomes too generic and stops representing specific parts well.

Ignoring metadata is another serious problem. A system may retrieve a semantically similar document, but without metadata it may not know whether the document is current, valid or accessible to a given user.

Typical mistakes include:

embedding overly long texts as one vector,
splitting documents badly,
missing version or date information,
relying only on embeddings without full-text support,
using an unsuitable embedding model for the language or domain,
failing to test on real queries,
sending semantically similar but practically wrong results into the answer-generation step.

How to recognise a well-used embedding system

A well-designed embedding setup is one that returns genuinely relevant results, not just loosely similar ones.

A good system should:

retrieve content by meaning,
work even when the user phrases the query differently from the document author,
combine embeddings with metadata,
handle document freshness and versioning,
respect permissions,
return traceable sources,
avoid overly broad vectors,
be tested against real user queries.

The goal is not to use embeddings for their own sake. The goal is to retrieve the right content for the actual task.

Embeddings in company environments

In companies, embeddings are most useful where there is a large amount of content and people need to find the right piece of information quickly.

Typical use cases include:

AI assistants over internal documentation,
customer support knowledge base search,
finding similar complaints or tickets,
recommending relevant articles to sales teams,
searching technical documentation,
analysing customer queries,
grouping similar operational problems.

But this only works well if the underlying source base is in reasonable shape. Embeddings do not fix a messy knowledge base. If documents are old, duplicated or contradictory, embeddings may simply retrieve those issues more efficiently.

Embeddings and security

Embeddings can be connected to sensitive data. If a vector database stores representations of internal documents, contracts, emails or customer communication, permissions and data protection matter.

Important questions include:

who is allowed to search those embeddings,
whether the embedding points to sensitive source content,
whether permissions are checked during retrieval,
where embeddings are stored,
whether the original document can be traced,
how embeddings are deleted when source documents are removed,
how old document versions are handled.

An embedding is numerical, but it still relates to underlying content. It should not be treated as automatically neutral from a security perspective.

Risks and unknowns

With embeddings, it is important to remember that results depend on mathematical similarity, data quality and the design of the retrieval system.

Similarity does not mean correctness – the system may retrieve content that is semantically similar but not the right answer. Mitigation: combine embeddings with metadata, rules and source checks.
Poor source quality – if documents are old, duplicated or contradictory, embeddings may still return them as relevant. Mitigation: clean the knowledge base and mark current versions clearly.
Chunks that are too long – the embedding becomes too broad. Mitigation: split by meaning, not only by arbitrary size.
Chunks that are too short – context is lost. Mitigation: preserve headings, nearby sentences and links to the source document.
Wrong embedding model – a model may be weak for a specific language, domain or data type. Mitigation: test on real queries and real documents.
Ignoring exact-match needs – embeddings are not ideal for codes, IDs and exact identifiers. Mitigation: combine them with full-text search and metadata filters.
Missing permission checks – the system may retrieve content a user should not see. Mitigation: enforce access control at retrieval time.
Outdated indexes – embeddings may still point to removed or obsolete documents. Mitigation: reindex regularly and delete invalid entries.
Overconfidence in similarity scores – a high score does not guarantee a correct result. Mitigation: use relevance thresholds, reranking and human review in sensitive workflows.

Related terms

Retrieval – the process of finding and loading relevant information that will later be used as input for an answer.
RAG – an architecture that combines retrieval of relevant information with answer generation.
Vector – a list of numbers that, in the case of embeddings, represents content in mathematical form.
Vector database – a database designed to store embeddings and retrieve similar vectors efficiently.
Semantic search – search based on meaning, not only on exact keyword overlap.
Hybrid search – a combination of full-text search and semantic search based on embeddings.
Chunking – splitting a long document into smaller parts so that more precise embeddings can be created.
Reranking – an additional ranking step used to reorder retrieved results by likely relevance.
Context window – the space into which a model’s query, supporting material and answer must fit in one step.
Token – the basic unit of text or input used by language models and many embedding pipelines.
Large language model (LLM) – a model that processes and generates text based on input, context and learned language patterns.
Multimodal models – models that can work with multiple input types such as text, images, audio or documents.
OCR – technology that extracts machine-readable text from images, scans or PDF documents.

Sources and references

Vector embeddings – OpenAI API – developers.openai.com – April 2026 – documentation explaining that an embedding is a numerical vector and that vector distance helps estimate how closely two pieces of content are related.
Embeddings APIs overview – Vertex AI – docs.cloud.google.com – April 2026 – overview of how embeddings are created and used in Google Vertex AI for text, multimodal inputs and similarity search.
Understand embeddings – Microsoft Learn – learn.microsoft.com – February 2026 – explains how embeddings capture semantic similarity in vector space and how they are used to compare pieces of text.
Semantic Search with Embeddings – Cohere Docs – docs.cohere.com – April 2026 – practical explanation of semantic search using embeddings, where documents and queries are converted into vectors and compared by similarity.
What are Vector Embeddings? – pinecone.io – June 2023 – accessible explanation of vector embeddings and why they matter for similarity search, recommendations and duplicate detection.
Vector Similarity Explained – pinecone.io – June 2023 – explains common similarity measures such as cosine similarity, Euclidean distance and dot product.
Embeddings – Machine Learning Crash Course – developers.google.com – August 2025 – educational material explaining embeddings as lower-dimensional numerical representations of data and why they help machine learning systems work with large inputs.

Large Language Model (LLM)

Leave a reply

A large language model, usually shortened to LLM, is a type of artificial intelligence model designed to process and generate natural language. It is trained on very large amounts of text and other data so that it can recognise linguistic patterns, work with context and produce new text-based output – for example answers, summaries, translations, rewrites, explanations, code suggestions or document analysis.

Most modern large language models are based on the transformer architecture. In practical terms, this means they generate text by predicting the next token according to the input they have received and the context already available to them.

At first glance, the term large language model may sound like a technical concept relevant mainly to developers, researchers or AI engineers. In reality, it is one of the key terms behind today’s generative AI. Large language models power many chatbots, writing assistants, summarisation tools, search-enhanced AI systems, customer support assistants, coding tools and business applications that work with documents or text.

If you want to understand what today’s AI tools actually do, why they can sound convincing and why they can still be wrong, LLM is one of the best concepts to start with.

An LLM is not a database of ready-made answers. It does not simply look up a finished sentence and copy it into the response. Instead, it receives an input, breaks it down into tokens, evaluates patterns and relationships in the context, and then generates the next part of the output step by step.

What does “large” mean in large language model?

The word “large” does not only mean that the model can work with long documents. It mainly refers to the scale of the model and the training process. A large language model is typically trained on very large datasets and contains a large number of internal parameters. These parameters are adjusted during training so that the model can capture statistical relationships in language and use them when generating output.

This scale is one reason why modern LLMs can perform many language-related tasks that previously required separate systems. The same model can often summarise a document, answer a question, rewrite a paragraph, translate a sentence, classify text or help draft an email.

However, larger does not automatically mean better in every situation. A larger model may be more flexible, more fluent and better at handling varied instructions, but size alone does not guarantee factual accuracy, legal suitability, privacy compliance or correct interpretation of a specific business problem.

How a large language model works

In simplified terms, a large language model works by predicting tokens. A token is not always the same as a full word. It can be a word, part of a word, a number, punctuation mark or another small unit of text. The model processes text in this tokenised form rather than in the same way a human reader sees words and sentences.

When you ask an LLM a question, the model does not “think” in a human, conscious sense. It analyses the input, the instructions and the available context, then estimates which token is most likely or most appropriate to come next. It repeats this process many times until it produces a complete answer.

This is why an LLM can appear to understand a topic very deeply. It can imitate structure, tone, reasoning patterns and domain-specific vocabulary. But it is still a statistical model. Its output is generated from learned patterns, not from human experience, intention or real-world understanding.

Why transformers are important for LLMs

Modern large language models are usually built on transformer-based neural network architectures. Transformers are important because they improved the ability of models to work with longer sequences of text and identify relationships between different parts of an input.

Before transformers became dominant, many language systems struggled more with long-range context. A sentence at the beginning of a document could be difficult to connect with a sentence much later in the same text. Transformer architecture, especially through attention mechanisms, made it much more practical for models to evaluate which parts of the input are relevant to each other.

This is one of the reasons why today’s LLMs can work with prompts, conversations, documents, code snippets and more complex instructions better than older generations of language systems.

If you want to understand the broader background, it is useful to connect this concept with machine learning, deep learning, neural networks and natural language processing. A large language model is not magic outside the rest of AI. It is a specific development within machine learning, built around language, scale and neural network architectures.

What LLMs can do in practice

Large language models are used for a wide range of natural language processing tasks. These include text generation, summarisation, translation, question answering, paraphrasing, classification, sentiment analysis, document review, chatbot responses, code assistance and information extraction.

In practice, this means an LLM can work as a writing assistant, a support tool for internal documentation, a first-draft generator, a research helper, a customer support component or a layer inside a larger business application.

The important point is that an LLM is not just a tool for “writing texts”. It is a general-purpose language model that can be used for many tasks involving language and structured text. It can help transform, compress, explain, compare or reorganise information.

For European businesses, this matters especially in areas where communication, documentation and compliance are central. Examples include customer support, legal drafting support, HR documentation, technical manuals, public administration, e-commerce content, multilingual communication and knowledge management.

How LLMs relate to tokens and the context window

Large language models do not work directly with words in the same way people do. They work with tokens. This matters because tokens also define the practical limits of the model.

The context window is the amount of information a model can consider at one time. It includes the user’s prompt, system instructions, previous messages, retrieved documents and often the model’s own response. If the input is too long, not all information can necessarily be considered at once.

This is why even powerful LLMs have practical limits. A model cannot automatically use every document a company owns unless those documents are actually provided to it through a suitable system. In real applications, this is where concepts such as retrieval, chunking, embeddings and retrieval-augmented generation become important.

In simple terms: if the model does not receive the relevant information in its current context, it cannot reliably use it.

How LLMs are trained and adapted

The foundation of a large language model is created during pre-training. In this phase, the model learns general patterns from large volumes of data. It learns how language is structured, how concepts are commonly related, how arguments are formed and how different types of text tend to continue.

Pre-training gives the model broad language ability, but it does not automatically make it suitable for every professional use case. A general LLM may write fluently, but it may not know a company’s internal terminology, legal rules, product details, tone of voice or risk requirements.

That is why LLMs are often adapted further. This can happen through prompting, system instructions, fine-tuning, retrieval from external knowledge bases or integration with business systems. In many practical cases, retrieval is more suitable than fine-tuning because the model can access up-to-date company knowledge without needing to be retrained every time a document changes.

Where large language models have limits

Large language models can be useful, but they are not a guarantee of truth. They can produce fluent and confident answers that are factually wrong. This is often described as hallucination, although in many professional contexts it is clearer to say that the model generated an unsupported or incorrect output.

LLMs may also misunderstand instructions, miss important details, overgeneralise from patterns, invent sources or apply the wrong tone. The risk is higher when the question requires current information, legal interpretation, medical advice, financial judgement or precise technical facts.

There are also operational limits. Large models can be expensive to run, require significant computing power and need careful monitoring. Businesses must also consider data protection, confidentiality, vendor lock-in, auditability, cybersecurity and compliance obligations.

For organisations in the European Union, these issues are especially important because AI use often intersects with GDPR, sector-specific regulation, copyright, transparency requirements and the EU AI Act. In other words, using an LLM is not only a technical decision. It can also be a legal, operational and governance decision.

Why LLMs matter outside technical fields

The term large language model is important even for people who will never train or deploy one themselves.

Marketers, editors, lawyers, analysts, managers, teachers, consultants, support teams and public-sector employees increasingly work with AI tools that are based on LLMs. Understanding the concept helps them use those tools more realistically.

An LLM is not a search engine, although it can be connected to search. It is not a verified knowledge base, although it can be connected to one. It is not a human expert, although it can imitate expert language. It is a generative model that works with language patterns and context.

Once you understand that, it becomes easier to understand why prompts matter, why context matters, why outputs need checking and why an answer can be linguistically excellent but still wrong.

This is also why LLM literacy is becoming a practical skill. The point is not that everyone must become an AI engineer. The point is that people using AI tools should understand enough to know when the output is useful, when it needs verification and when the task should not be delegated to an AI system without human oversight.

Large language model vs generative AI

LLM and generative AI are related terms, but they are not identical.

Generative AI is the broader category. It includes systems that can generate text, images, audio, video, code or other types of content. A large language model is one type of generative AI focused mainly on language and text-based input and output.

Many modern AI products combine several model types. A tool may use an LLM for language, another model for image generation, speech recognition for audio input and retrieval systems for working with external documents. From the user’s point of view, it may feel like one AI assistant. Technically, it can be a combination of several systems.

Related terms

Transformer – a neural network architecture used by most modern large language models. It helps models work with context and relationships between parts of a sequence.
Token – a basic text unit processed by the model. A token can be a word, part of a word, punctuation mark, number or another small unit of text.
Prompt – the instruction or input given to an AI model. The prompt strongly influences what the model generates and how it structures the answer.
Context window – the amount of information the model can consider at one time. It is usually measured in tokens, not words or pages.
Fine-tuning – an additional training process used to adapt a model to a specific task, style or domain.
Retrieval-augmented generation – a method where the model is supplied with relevant external information before generating an answer.
Machine learning – the broader AI field in which systems learn from data rather than relying only on fixed manual rules.
Natural language processing – the area of AI focused on processing, analysing and generating human language.
General-purpose AI model – a term used in the EU regulatory context for AI models that can perform a wide range of distinct tasks and can be integrated into different downstream systems.

Sources and further reading

LLMs: What is a large language model? – developers.google.com – April 2026 – explains what a large language model is, how it works, and how it relates to the transformer architecture.
What are Large Language Models? – ibm.com – April 2026 – provides an overview of what large language models are, what they are used for, and what their main strengths and limitations are.
What are tokens and how to count them? – help.openai.com – April 2026 – explains what tokens are, how they are counted, and why they matter for model input length, pricing, and context windows.
General-Purpose AI Models in the AI Act – Questions & Answers – digital-strategy.ec.europa.eu – July 2025 – explains how the EU AI Act defines and regulates general-purpose AI models, including key obligations and the broader legal framework.
Machine learning – krcmic.com – April 2026 – explains the broader foundations of machine learning and helps place large language models into the wider AI context.

Multimodal models

Leave a reply

Multimodal models are AI models that can work with more than one type of input at the same time – for example text, images, audio, video, documents, charts or screenshots. In other words, they are not limited to answering text questions only. They are designed to connect different kinds of information and evaluate them within a shared context.

At first glance, a multimodal model can seem simple. A user uploads an image, asks a question and gets an answer. In reality, the underlying principle is much more complex. The model has to convert text, images, audio, video or documents into technical representations it can process and then detect relationships across those different inputs.

A multimodal model is an AI system that is not limited to one data type. It can process, for example, text and an image together, and in some cases also audio, video, a document or another file type. Practically speaking, the model is not trying to understand only words, but also what is visible, audible or contained in an attached file.

What a multimodal model means in practice

A standard language model works mainly with text. The user writes a prompt and the model answers in text. A multimodal model goes further. It can receive, for example, a photo, an application screenshot, a scanned document, a chart, an audio recording or a video together with a text question.

The difference is substantial. The user no longer has to describe everything in words. They can show the model what they are dealing with. For example, they can upload a photo of a technical label and ask what the values mean. They can attach a screenshot of an error message and ask for an explanation. They can upload a PDF invoice and ask for the due date, total amount and supplier.

That is why multimodal models matter especially where text alone is not enough. In real-world workflows, most information is not purely textual. We work with documents, tables, product photos, screenshots, charts, scans, recordings, presentations and mixed combinations of these formats.

What a modality is

A modality is the way information is represented or delivered. In AI, the term usually means the type of input a model works with.

Common modalities include:

text – queries, articles, emails, contracts, instructions, code, manuals,
images – photographs, screenshots, charts, diagrams, scans, product images,
audio – spoken input, recordings, phone calls, meetings, podcasts,
video – screen recordings, camera footage, tutorial videos, presentations,
documents – PDFs, presentations, spreadsheets, scanned forms, technical sheets,
structured data – tables, database exports, JSON, CSV or analytical reports.

People think multimodally by default. When you watch a video, you process visuals, sound, speech, movement, on-screen text and the broader situation at the same time. When you read instructions, you often combine text with an image. When you evaluate a complaint, you may rely on the customer description, the product photo, the order record and the company rules together.

Multimodal models try to do something similar computationally. They do not see or hear like a human. Instead, they convert different inputs into mathematical representations and then search for relationships across them.

How a multimodal model differs from a standard language model

A classic language model is primarily text-based.

It can work with sentences, word meaning, text structure, context and the probability of the next response. That is very powerful for writing, summarisation, translation, coding or text analysis.

A multimodal model, however, can also accept non-text input. For example, an image, a chart, an audio file or a document page. That significantly broadens what the system can be used for.

Practically speaking – a text-only model needs you to describe the problem in words. With a multimodal model, you can partly show the problem directly. That matters especially for screenshots, documents, product photos, charts, technical diagrams or recordings.

Example:

Text-only model: “I will describe what I see on the invoice, and you help me find the due date.”
Multimodal model: “I upload the invoice as an image or PDF and ask when it is due.”

In the first case, the user has to do much of the interpretation manually. In the second case, the model can analyse the attached source directly.

How multimodal models work

Multimodal models work by converting different input types into representations that can be connected or compared inside the same system. Text is usually turned into tokens or embeddings. Images are processed through a vision component. Audio is converted into an audio representation. Video may involve a combination of frames, time sequence and sometimes audio.

The model does not “see” a tree, an invoice or a broken product in a human way. It works with numerical representations that capture patterns, relationships and probabilities.

1. The model first converts the input into technical form

Text is usually split into smaller units called tokens. Images are processed through the visual part of the model. Audio is transformed into a representation that the system can analyse. Video is more complicated because the model has to deal with frames, motion, temporal continuity and often also sound.

2. The model looks for relationships between different input types

If the model receives an image and a question, it has to connect the visual information with the textual instruction. If you ask “What is wrong with this chart?”, the model has to understand that the question refers to the visual structure of the chart. If you ask “Where is the problem in this screenshot?”, it has to map the text request to a specific part of the screen.

3. The model returns an answer in the required form

The output does not have to be plain text only. A multimodal model may return a summary, a list of detected issues, a description of an image, structured data, JSON, an explanation of a chart, a transcript of audio or instructions for a downstream system.

That is one reason multimodal models matter not only for chat interfaces, but also for process automation.

Why multimodal models matter

Multimodal models move AI from pure text handling toward working with more realistic inputs. Most business and everyday problems are not stored as clean text.

A typical workflow problem may include:

an email from a customer,
an attached photo,
an order in PDF,
a screenshot from an internal system,
a data table,
a note from a phone call,
internal rules that define how the situation should be handled.

Older automation often handled only one part of that chain. For example, reading text, extracting invoice fields or classifying an image. A multimodal model tries to bring several of these inputs into one shared context.

What matters most about multimodal models is that they move AI closer to the way people work with information in practice. They do not isolate text, images or sound as separate worlds, but try to interpret their relationship.

Text and images: the most common form of multimodality

The most common practical example of multimodality is the combination of text and image. The user uploads an image and asks a question about it.

The model may, for example:

describe what is visible in the image,
explain a technical diagram,
identify a problem in a screenshot,
compare a product photo with its description,
read visible text from an image,
explain a chart or table,
suggest a caption for an image,
check whether visual materials are consistent.

That is useful in marketing, e-commerce, technical support, software development, education, administration and customer service.

Text and documents

Documents are another important area. Multimodal models can work with PDFs, scans, forms, technical sheets or presentations. The difference compared with plain text extraction is that the model may also take the page layout into account.

This matters, for example, for invoices where reading isolated words is not enough. The system needs to understand which field is the supplier, which one is the customer, which value is the invoice number, which date is the issue date, which date is the due date and which amount is the amount payable.

Similarly, for charts it is not enough to read text labels. The model also needs to relate axes, values, legends and the visual pattern of the data.

Text and audio

Another important combination is text and audio. The model may work with spoken input, a transcript, a phone call or a meeting recording. In practice, that means the user does not always have to type. They can speak.

With audio, though, the task is not limited to speech-to-text. More advanced multimodal systems can also work with the flow of a conversation, the structure of a meeting or the context of a spoken exchange. The practical output may be meeting notes, an action-item list, a summary of decisions or a draft reply.

Text, images and video

Video is more complex than a static image because it includes time. The model therefore has to process not only what appears in one frame, but also what changes over time.

This can be useful for:

summarising a longer video,
analysing a screen recording,
checking the steps in a tutorial video,
finding a specific moment in a recording,
describing events for users who cannot watch the video directly,
checking errors in a process, operation or production step.

At the same time, video introduces more room for mistakes. The model may miss a detail, misread the sequence of events or infer something that is not clearly present.

Multimodal models and OCR

OCR stands for Optical Character Recognition. Traditional OCR tries to convert text visible in an image or scan into machine-readable text. For example, it may turn a scanned invoice into extracted text lines.

Multimodal models can extend that workflow. They do not only “read” the text. They may also try to interpret the meaning and structure of the document.

Example:

OCR reads: “Due date 15 May 2026”.
A multimodal model may answer: “The invoice is due on 15 May 2026 and, based on today’s date, it is not yet overdue.”

The difference is interpretation. OCR converts an image into text. A multimodal model tries to combine text, layout and the user’s question into an answer.

Multimodal models and embeddings

An embedding is a numerical representation of content. It can represent text, an image, audio, video or a document. Embeddings allow systems to compare the similarity of different inputs.

With multimodal models, this matters because different input types can sometimes be mapped into a shared semantic space. That makes it possible, for example, to search for images using a text query or find documents related to a screenshot.

A practical example:

The user writes: “Find images of products that look like a black sports backpack.”
The system does not have to rely only on file names or captions.
It can compare visual similarity together with the text request.

This is valuable in e-commerce, digital archives, image libraries, document systems and knowledge bases.

Where multimodal models are used

Multimodal models make sense wherever several types of source material are used together.

E-commerce

In e-commerce, multimodal models can help with product photos, descriptions, categorisation, attribute checking or complaints. A model may detect that the image does not match the product title, that the description is missing important details or that the claimed defect is visible in the attached photo.

Marketing and content

In marketing, a model can analyse banners, website screenshots, social media visuals, campaign charts or content drafts. It can help with alternative text, chart explanations, readability checks or suggestions for clearer visual communication.

Customer support

Customers often cannot describe a problem precisely. They send a screenshot, a photo of a defective item or a recording of the issue. A multimodal model can process those materials, suggest a ticket category, draft a reply and highlight details for a human agent.

Software and UX

In software work, the model may analyse an interface screenshot, an error message or a draft screen. It can help explain what is unclear, where a user-flow problem may exist or why a specific element is confusing.

Administration and documents

In administrative work, multimodal models are useful for invoices, contracts, forms, presentations, technical sheets or scanned documents. They can help with sorting, checking, summarising or extracting key details.

Education

In education, a model may explain a chart, map, diagram, physics problem, geometry sketch or handwritten solution. A student can show the work and ask where a mistake happened.

Industry and technical support

In technical environments, a model may assist with equipment photos, labels, wiring layouts, maintenance reports or service documents. In sensitive technical cases, however, the result still needs expert verification.

Main advantages of multimodal models

Their biggest advantage is that the model can work with more realistic inputs than a pure text chatbot.

Less manual describing – the user does not need to rewrite the contents of an image, chart or document by hand.
Better context handling – the model can combine a text question with a visual or audio source.
Faster orientation in documents – the user can upload a file and ask for specific information.
Broader business usefulness – multimodality is useful in support, administration, marketing, sales, development and operations.
Better accessibility – the model can describe an image, transcribe audio or explain a chart to people who cannot easily work with that format directly.

Limits of multimodal models

Multimodal models are powerful, but they are not error-free. That is important to stress because visual and document analysis can look very convincing to users.

A model may:

misread small text in an image,
confuse similar-looking objects,
misinterpret a chart or legend,
miss a detail in a document,
misread a technical diagram,
infer information that is not actually present,
answer confidently even when the input is ambiguous.

Important: a multimodal model is not a proof tool and not a substitute for expert judgement. It can help with orientation, summarisation and preliminary analysis, but in legal, medical, financial, safety-critical or technical decisions the result must be checked by a human.

Why a multimodal model does not mean AI truly “sees”

When people say a model “sees” an image, that is shorthand. The model does not perceive an image through lived experience, physical space or human-world understanding. It processes image data.

That does not make the output useless. It simply means we should distinguish between practical image analysis and human perception. A model may correctly describe a screenshot, identify text in a document or explain a chart. At the same time, it may still fail on details a person would notice immediately.

Multimodal models and hallucinations

A hallucination in AI means the model produces a false or unsupported claim. With multimodal models, this may happen when the system says it sees something in an image that is not actually there, or when it draws a conclusion from a document that the source does not really support.

Examples:

the model may read the wrong invoice number from a poor-quality photo,
it may confuse similar logos or brands,
it may misunderstand a chart with an unclear axis,
it may treat a decorative element in a document as a meaningful data point.

That is why, in important tasks, it helps to force the model toward precision. For example: “List only details explicitly visible in the document. If something cannot be confirmed from the file, say that it cannot be verified.”

How to work with multimodal models properly

The same rule that applies to text AI applies here as well: the more precise the task, the better the output. The user should not just upload an image and say “What about this?” It is better to specify exactly what the model should look for.

Better prompts might look like this:

“Review this screenshot and identify interface elements that may confuse users.”
“From this invoice, extract the supplier, customer, due date, total amount and payment reference.”
“Explain this chart so that a person without technical training can understand it.”
“Find mismatches between the product photo and the written product description.”
“List only what is directly visible in the image and separate that from assumptions.”

What matters in company deployment

In companies, multimodality is useful, but it has to be deployed carefully. It is not enough to expose the model to documents and hope that it will solve everything.

The main concerns include:

input quality – blurred scans, poor photos or incomplete documents increase the risk of error,
data protection – documents may contain personal data, trade secrets or sensitive information,
responsibility – it must be clear who reviews the output and who is accountable for decisions,
process integration – the model has to fit into CRM, helpdesk, WMS, DMS or other company systems,
auditability – in important cases it should be clear what source materials the model relied on,
testing – a polished demo is not enough; the model has to perform on real company data.

Multimodal models and AI agents

Multimodal models are closely connected with AI agents. A standard model answers a question. An agent may use that answer as part of a workflow and take another action. If it has tools available, it may create a ticket, fill in a form, draft a response, trigger a search or prepare a task for a human.

A practical example:

A customer sends a photo of a damaged product.
The model identifies it as a probable complaint case.
It compares the image with the order and complaint rules.
It drafts a customer reply.
It creates a ticket with prefilled details.
A human checks the result and sends it.

At that point, this is no longer just “chat”. It is a combination of recognition, analysis and workflow execution.

Risks and unknowns

The limits matter because they show where interpretation can fail and what can change the result.

Inaccurate image interpretation – the model may miss a detail or misread a scene. Mitigation: require human review for important outputs.
Document-reading errors – small text, poor scans or complex tables can produce wrong results. Mitigation: use high-quality source files and verify key numbers.
Hallucinations – the model may add information that is not in the source. Mitigation: explicitly require separation between verified details and assumptions.
Sensitive data exposure – multimodal inputs often contain personal data, faces, contracts or business information. Mitigation: enforce permissions, anonymisation and clear data-handling rules.
Uneven quality by input type – the model may be strong on text and images but weaker on video or complicated charts. Mitigation: test actual scenarios, not only marketing claims.
Prompt dependence – vague instructions lead to weaker answers. Mitigation: use prompt templates and define the expected output clearly.
Legal and accountability issues – it may not be clear who is responsible for a decision influenced by AI output. Mitigation: use the model as an assistant, not as an autonomous decision-maker.
Rapid technology change – capabilities evolve quickly. Mitigation: update internal rules, testing procedures and operating assumptions regularly.

Common mistakes when using multimodal models

The most common mistake is overestimating the model’s capability. The user sees a convincing answer and assumes it must be correct. That is especially risky with documents, technical sources and numerical data.

Another common mistake is uploading poor-quality inputs. A blurred photo, a weak scan or an incomplete screenshot significantly lowers reliability. The model may still answer, but the answer rests on uncertain evidence.

A third frequent problem is a prompt that is too general. If the user writes only “Check this”, the model may not know whether it should evaluate style, content, errors, risks, figures, graphics or legal meaning.

What a good multimodal output looks like

A good output should be specific, traceable and cautious where the source is unclear. The model should be able to state not only its answer, but also what it is relying on and what cannot be confirmed from the source.

A strong answer distinguishes between:

what is directly stated in the document,
what is likely visible in the image,
what is interpretation,
what cannot be seen or confirmed,
which details should be checked by a human.

This matters especially for invoices, contracts, medical material, technical diagrams, accounting files or legal texts.

Why multimodal models change how people work with information

What multimodal models change most is the speed and convenience of working across different source types.

Previously, teams often had to first convert an image into text, then convert video into a transcript, then turn a document into structured data, and only after that continue processing it. A multimodal model can combine part of that chain.

That does not mean specialist tools disappear. OCR, analytics platforms, databases, search engines, DMS, CRM and specialist software still matter. But a multimodal model can serve as a more natural layer between the user and those systems.

The user no longer has to ask in technical terms. They can ask in human language: “What matters on this invoice?”, “What is wrong with this chart?”, “What is the customer complaining about based on this photo?” or “Is this document complete?”

Why this is more than a technical curiosity

Multimodal models are not just a flashy demonstration that AI can describe pictures.

Their real importance lies in bringing previously manual source types into automation. In companies, that may involve documents, product data, complaints, support cases, internal knowledge bases, training materials, technical documentation, quality checks or source analysis. For everyday users, it may involve explaining a photo, chart, form, contract, instruction or screenshot.

That is why multimodality is becoming one of the major directions in AI development.

A model that works only with text is useful. A model that can combine text, images, audio and documents is much closer to how information is actually handled in real workflows.

Related terms

Language model – an AI model that works mainly with text and generates responses in natural language.
Large language model (LLM) – a large model trained on substantial amounts of text data and used for tasks such as chat, summarisation, translation or code generation.
Embedding – a numerical representation of content that makes it possible to compare semantic similarity across text, images, documents or other data types.
OCR – optical character recognition, a technology that converts text from an image or scan into machine-readable form.
Computer vision – the area of AI focused on analysing and interpreting visual input.
Speech-to-text – conversion of spoken language into text.
Text-to-speech – conversion of text into spoken audio.
RAG – an approach in which the model answers with the help of external documents or a knowledge base.
AI agent – a system that not only answers, but can also use tools and perform follow-up actions.

Prompt engineering

Leave a reply

Prompt engineering is the practice of designing prompts for a language model in a deliberate way so that the model produces more precise, useful and contextually appropriate outputs. It is not just about “writing better prompts”. It is about shaping the structure of the input, the order of information, the goal of the task, the constraints, the context and the expected format of the result. In simple terms, prompt engineering is about telling the model what to do in a way that gives it the best chance of understanding the task correctly and producing an output that is actually usable.

At first glance, the term can sound overly technical or even a little overhyped. In practice, though, it describes something very concrete. A language model does not respond with human intuition. It responds based on how the task is framed and what information it receives on input. That is why the same model can answer one version of a task very well and another version poorly, vaguely or in a completely unsuitable way. The difference is often not only the model itself, but also the prompt.

Prompt engineering is deliberate work with AI input. It is not only about what you tell the model, but also in what order, with what context, under what constraints and with what expected output format. The goal is not to trick the model, but to give it the clearest possible working frame.

What prompt engineering really means in practice

In everyday AI use, many people think of a prompt as one question or one command. Prompt engineering goes further. It focuses on how to build the input so the model receives not only a topic, but also a clear objective, clear boundaries and a clear output form.

In practice, that may mean telling the model who the audience is, what style to use, how detailed the answer should be, what structure the output should follow, what source material to rely on, what to leave out and what it absolutely must not ignore.

So this is not just about nicer wording. A well-designed prompt can reduce unwanted improvisation, lower the need for corrections, improve factual usefulness and make the final result more predictable. A badly designed prompt often leads to a fluent answer that still misses the actual purpose of the task, chooses the wrong depth, uses the wrong tone or starts adding details that were never part of the request.

Why prompt engineering is not just about writing a longer prompt

A common misunderstanding is that prompt engineering simply means writing the longest and most detailed prompt possible. That is not the point.

A long prompt can be useful if it is well structured and genuinely relevant. But if it is full of repetition, side notes, mixed priorities and loosely connected instructions, it can confuse the model rather than guide it.

The real value of prompt engineering is not length, but precision and structure. A good prompt makes clear what the model should do, what it should rely on, what it should avoid, what kind of output is expected and where the boundaries of the task are. Very often, a shorter but sharper prompt works better than a long block of text in which the main objective gets buried.

What a well-designed prompt usually contains

A well-designed prompt usually has more than one layer. It does not just name the topic. It gives the model enough structure to understand the task properly.

In most cases, a strong prompt includes:

the goal – what should be produced,
the context – what the model should base its answer on and in what situation it should operate,
the rules – what to preserve, what to avoid, what tone or depth to use,
the output format – whether the result should be a continuous article, bullet list, table, HTML block, summary or something else.

Exclusion conditions are especially important. In other words, not only “what to do”, but also “what not to do”. For example, the prompt may specify that the model should not use a marketing tone, should not invent facts beyond the provided material, should not add a closing summary, should not use unnecessary jargon or should not change the original terminology. These limits often decide whether the output is actually usable.

Correct approach: a good prompt does not only guide the model, it also restricts it. It is not enough to say what to create. It is often just as important to define what the model must not assume, must not change and must not drift into.

What the difference looks like between a weak and a good prompt

The difference becomes obvious in a simple example.

Weak prompt:
Write me an article about DNS.

This is too general. The model does not know who the article is for, how technical it should be, how long it should be, what to exclude or what practical angle matters most.

A much stronger version could look like this:

Better prompt:
Write a factual article in English explaining what DNS is. The text should be intended for a general reader, not for server administrators. Explain the concept clearly, but keep it technically correct. Do not use unnecessary slang, do not write in a marketing tone, do not add a concluding summary, and include a practical explanation of why DNS matters for both websites and email.

In the second case, the model receives a much clearer objective, audience, tone, scope and set of limits. That makes it far more likely that the result will match what the user actually needs.

Why prompt engineering also depends on context and input structure

Prompt engineering is not just about one clever sentence. It also depends on what information the model receives at all, and in what order.

For more complex tasks, simply writing a request is often not enough. The model may also need supporting material, a clear signal about which source is the main reference point and which inputs are only secondary context. That matters especially when working with documents, legal texts, technical specifications, company guidelines or internal knowledge bases.

If the model receives multiple sources without a clear hierarchy, it may mix the main information with less important details or assign too much weight to the wrong part of the input. This is why prompt engineering also concerns the structure of the input, not only the wording of the first instruction.

What the most common prompt mistakes are

One of the most common mistakes is vagueness. The user wants a specific result, but the prompt is written so generally that the model has to fill in a large part of the task by itself.

Another common mistake is overload. The prompt contains too much information, but it is not organised well and different instructions compete with each other.

Conflicting instructions are also frequent. For example, a prompt may ask for a detailed expert-level article and at the same time demand an extremely short answer with no explanation. Or it may ask for a text that should work equally well for complete beginners and specialists without making clear who has priority. Another problem is the lack of boundaries. The model then does not know whether it should improvise, rely only on the provided material, add general knowledge or stick strictly to the structure of the input.

Common mistake – the user knows exactly what they want, but does not actually say it in the prompt. The model then produces a poor result not because it is “stupid”, but because the task left too much room for open interpretation.

This is exactly why exclusion conditions matter.

A prompt is usually stronger when it explicitly says what the model must not do. That may include things like:

do not invent facts beyond the provided source,
do not use bullet points,
do not write in a promotional tone,
do not add a final summary,
do not simplify technical terms incorrectly,
do not mix factual explanation with speculation.

Very often, these “negative” conditions are what prevent the output from going off track.

Why prompt engineering matters in companies and production systems

Prompt engineering is not just a trick for people casually playing with chatbots. In companies and production systems, it is often a very practical discipline.

If a company uses AI for customer support, internal documentation, content classification, answer generation or writing assistance, the quality of the prompt directly affects the quality of the result. A poorly designed prompt can lead to inconsistent answers, an unsuitable tone, incorrect handling of data or outputs that are unusable from a business perspective.

That is why, in production environments, prompt engineering is rarely treated as a one-off phrasing exercise. It becomes part of system design. Teams test which instructions produce stable results, how the model reacts to variations in user input, where it tends to fail and how to define the prompt so the output becomes more reliable and safer.

What prompt engineering cannot solve on its own

It is important not to overstate what prompt engineering can do. Even an excellent prompt will not turn an average model into a perfect system for every task. It will not fix missing data, weak source material or the underlying limitations of the model itself.

Prompt engineering can dramatically improve how a model handles a task, but it is not a replacement for good source data, the right model choice, proper system design or human review of important outputs.

In other words, prompt engineering matters, but it is not magic. It works best when it is part of a broader approach that also includes model selection, source quality, retrieval design, validation and evaluation.

Why prompt engineering matters outside technical roles

This concept is no longer relevant only to developers or AI specialists. It matters in practice to anyone who works with language models regularly and expects usable results. That includes editors, marketers, analysts, lawyers, consultants, managers, content teams and customer support staff.

Anyone who understands prompt engineering will understand more quickly why it is not enough to simply “ask AI something”. They will see why it helps to define the audience, style, structure, boundaries and sources, why exclusion conditions are useful and why good output often comes not from one vague request but from a carefully designed instruction.

Prompt engineering is therefore a practical discipline that sits between the raw capabilities of the model and a genuinely useful result.

Related terms

Prompt – the input or instruction itself. Prompt engineering builds directly on this concept because it is concerned with how prompts should be structured for better results.
Context window – the space into which the prompt must fit together with other instructions, source material and the model’s answer. It matters because even a well-designed prompt still faces technical limits.
Token – the basic unit of text the model processes. Prompt engineering is linked to tokens because prompt length and structure are constrained at the token level, not simply by word count.
System prompt – a higher-level instruction layer that defines general model behaviour. It matters because the final answer often depends not only on the user’s prompt, but on several layers of instruction.
Retrieval – the process of bringing relevant information from documents or databases into the model’s context. It shows that good prompting is not only about phrasing, but also about supplying the right supporting material.
Large language model (LLM) – the type of model prompts are designed for. Without understanding how an LLM works with language, tokens and context, prompt engineering does not fully make sense.

DMARC

Leave a reply

DMARC, short for Domain-based Message Authentication, Reporting and Conformance, is one of the most important technical concepts in email deliverability and domain protection. It is also one of the most misunderstood. In practice, DMARC is not “magic” and it is not just another random DNS detail. It is a policy published in DNS that tells receiving mail servers what to do with messages that claim to come from your domain but do not pass authentication checks in the right relationship to the visible From domain.

If you send newsletters, direct mail, automated campaigns, transactional messages or ordinary company email from your own domain, sooner or later DMARC becomes very hard to ignore. It helps receiving systems recognise whether an email really matches the domain identity it presents to the user. It also gives domain owners visibility through reports, which makes it easier to see who is really sending on behalf of the domain and where weak spots still exist in the sending setup.

DMARC is a DNS-based email policy that helps prevent domain spoofing. It tells receiving servers how to handle messages that appear to come from your domain but fail authentication checks tied to the visible From address. At the same time, it can send reports that help you understand what is really being sent in your domain’s name.

What DMARC is and why people talk about it so much

Interest in DMARC has grown because SPF and DKIM alone are not always enough. You can have both configured and still leave room for confusion if the authenticated domain does not properly match the domain the user sees in the From field.

This is where DMARC brings order. It does not only ask whether a server was allowed to send a message or whether a message was signed. It also asks whether the authentication result actually makes sense in relation to the domain identity shown to the recipient.

That matters mainly because of spoofing, phishing and brand impersonation. If someone tries to send forged email in your domain’s name, DMARC is one of the main ways to tell receiving servers not to treat those messages as normal mail.

In practical terms, DMARC is especially important for:

companies sending newsletters and marketing campaigns,
e-commerce businesses using transactional and automated email,
brands that want to reduce the risk of domain abuse,
organisations working on deliverability and sender reputation,
senders with larger mail volumes who need to meet stricter mailbox-provider expectations.

How DMARC works in principle

DMARC builds on the results of SPF and DKIM, but adds one more condition that is easy to underestimate – alignment. This is the key difference between a simplified explanation and how DMARC really works.

It does not merely check whether SPF or DKIM passed in some technical sense. It checks whether the domain validated by SPF or DKIM is aligned with the domain shown in the From header that the recipient actually sees.

In simplified form, the process looks like this:

the message arrives at the receiving mail server,
the server evaluates SPF and DKIM,
DMARC checks whether the SPF-authenticated or DKIM-authenticated domain aligns with the domain in the From field,
if at least one aligned result passes, the message can pass DMARC,
if not, the receiver looks at the DMARC record of the domain owner to decide how the message should be handled.

This is exactly why DMARC helps against domain impersonation. It is not enough for a message to be signed by some domain or sent from some technically allowed server. The authenticated identity also has to make sense in relation to the visible sender domain.

Important practical point: DMARC does not automatically guarantee inbox placement. It mainly helps with domain authentication, anti-spoofing and sender identity control. Deliverability still depends on other factors such as reputation, list quality, content, complaint rates and recipient behaviour.

What DMARC depends on – SPF, DKIM and alignment

DMARC does not stand on its own. It is a layer built on top of SPF and DKIM. If you have not clearly defined which servers may send on behalf of your domain, or if your messages are not being signed correctly, DMARC has very little solid information to work with.

A useful way to think about the relationship is this:

SPF says which servers are allowed to send email for your domain,
DKIM proves that the message was signed by an authorised domain and was not materially altered in transit,
DMARC checks whether the authenticated result from SPF or DKIM aligns with the domain in the visible From field and defines what should happen if it does not.

In practice, alignment is where many organisations get surprised. A message may “pass something” technically and still fail DMARC because the relationship between the authenticated domain and the visible sender domain does not line up properly.

That is one of the main reasons why DMARC deployments sometimes fail on the first attempt – not because DMARC is inherently mysterious, but because it reveals hidden inconsistencies in the sending infrastructure.

Where DMARC is published and what it looks like

DMARC is published in DNS as a TXT record, usually on the _dmarc subdomain of the main sending domain.

A simple example looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;

It may look short, but this record is doing several important things at once:

it declares that the record is a DMARC policy,
it sets the policy level,
it tells receiving systems where aggregate reports should be sent,
it can control how subdomains are treated,
it can define how strict alignment should be.

That is why copying a DMARC record from somewhere else without understanding it is risky. A badly designed DMARC record may not only fail to help. It can also start blocking legitimate messages from tools or services you forgot were sending on behalf of your domain.

What the policies p=none, p=quarantine and p=reject really mean

This is one of the most practical parts of the whole topic. The p= value defines what the receiver should do with messages that fail DMARC.

p=none – monitor only. The receiver is asked not to change message handling because of DMARC failure. This is typically used at the start of deployment so you can collect reports and see what your domain is actually doing.
p=quarantine – treat failing messages as suspicious. In practice, that often means sending them to spam or another lower-trust location rather than treating them as clean mail.
p=reject – ask the receiving server to reject the message outright if it fails DMARC.

These policies are often best understood as stages of maturity rather than as one quick switch. Many teams begin with p=none, use reports to clean up forgotten senders and alignment problems, move to p=quarantine when the setup is more stable, and only later go to p=reject.

Practical guidance – starting directly with a strict policy can be risky if you have not fully mapped all the systems sending mail on behalf of your domain. DMARC becomes much safer when it is rolled out in stages rather than as a one-step enforcement project.

Why reporting is such an important part of DMARC

One of DMARC’s strongest benefits is not only enforcement, but visibility. The record can ask for reports, most often through the rua tag for aggregate reporting and, where supported, ruf for failure-oriented reporting.

That matters because many organisations do not actually know every service that sends email using their domain. Marketing platforms, CRM tools, old servers, ticketing tools, billing systems and third-party apps often accumulate over time.

DMARC reports help uncover that reality. They can show which senders are authenticating properly, which are failing, and which sources may be spoofing or using the domain without correct setup.

In practice, this makes DMARC much more than a blocking mechanism. It becomes a way to audit your real sending landscape and identify where email authentication still needs work.

What else can be configured in a DMARC record

Beyond the core policy, DMARC records can include additional tags that shape how the policy behaves.

rua – where aggregate reports should be sent.
ruf – where failure reports should be sent, if receivers support them.
sp – a policy specifically for subdomains.
pct – the percentage of failing mail the policy should apply to, useful for staged rollouts.
adkim and aspf – whether DKIM and SPF alignment should be evaluated in relaxed or strict mode.

These details are part of what makes DMARC flexible. But they also make it possible to create a record that looks fine on the surface while behaving differently than intended. That is another reason why DMARC is best implemented with a clear understanding of what each tag is for.

Why DMARC does not solve everything by itself

DMARC is powerful, but it is not a universal email fix.

It does not guarantee inbox placement. It does not fix poor sender reputation. It does not repair broken list hygiene. It does not automatically make recipients trust your emails. And it does not remove every edge case in complex mail flows such as forwarding, mailing lists or older third-party systems that break alignment.

It is better to think of DMARC as a domain identity and anti-spoofing layer. That is already extremely valuable, but it is still only one part of the wider email setup.

What are the limits of DMARC? DMARC helps receivers evaluate whether a message is consistent with your domain identity. It does not tell them whether a message is “good” in every broader sense. Spam reputation, content quality, mailing practices and receiver-side filtering still matter. That is why DMARC should be seen as a critical part of email security and deliverability – but not the whole system.

Where DMARC matters most in practice

DMARC becomes especially important when a domain is used for:

marketing and newsletter sending,
transactional email from e-commerce or SaaS systems,
company mailboxes and day-to-day business communication,
brand protection against spoofing and phishing,
compliance with stricter expectations from large mailbox providers.

That is why DMARC is not only a technical concern for mail administrators. It also matters to marketers, founders, e-commerce operators and anyone responsible for a domain’s public credibility.

Why this term is worth understanding even outside technical roles

DMARC is one of the clearest examples of the fact that email is not only about writing a message and pressing send. Behind the scenes, there is also identity, trust and policy.

If you understand what DMARC does, it becomes much easier to see why an email may be blocked even though it “looked fine”, why a brand can be impersonated through email if authentication is weak, and why one forgotten sending tool can cause trouble across an entire domain.

That is why DMARC is worth understanding even outside technical professions. It sits exactly at the point where email deliverability, domain protection, sender reputation and brand trust all meet.

Related terms

DNS – DMARC is published as a DNS TXT record, so its role only makes full sense in the wider context of how DNS works.
SPF – one of the two core authentication methods DMARC builds on.
DKIM – the other core authentication method DMARC evaluates together with alignment.
Alignment – the rule that checks whether the SPF-authenticated or DKIM-authenticated domain matches the visible From domain closely enough to count as a DMARC pass.
From domain – especially important in DMARC because this is the sender identity the human recipient actually sees.
TXT record – the DNS record type used to publish DMARC.
rua / ruf – DMARC reporting tags used to request aggregate and failure-oriented reports.
p=none, p=quarantine, p=reject – the three main DMARC policy levels that define how failing mail should be handled.
MX records – not part of DMARC itself, but closely related to the wider email infrastructure of a domain.
Nameservers – the authoritative servers that publish the DMARC record and the rest of the domain’s DNS data.

TXT records

Leave a reply

A TXT record is a DNS record used to store text-based information for a domain or subdomain. At first sight, that can sound vague, but in practice TXT records are extremely important. They are commonly used for domain ownership verification, email authentication, service validation and other technical instructions that need to be published through DNS without pointing directly to a server or IP address.

Unlike an A record, which points to an IPv4 address, or an MX record, which tells the internet where incoming email should be delivered, a TXT record does not route traffic in the usual sense. Its role is different. It publishes text data that other systems can read and interpret.

That is exactly why TXT records appear in so many practical situations. You may see them when connecting a domain to Google Workspace or Microsoft 365, when setting up SPF or DMARC, when verifying domain ownership for an external service, or when publishing security-related information connected to email and domain control.

A TXT record is a DNS record that stores text information in DNS. It does not normally point to an IP address or a mail server. Instead, it publishes information that other systems can read and use for verification, authentication or configuration purposes.

What a TXT record actually does in practice

A TXT record allows a domain owner to place text-based information into DNS in a way that other services can query and interpret. The value itself may look like plain text, but in many real-world cases it is not meant for humans to read casually. It is meant for systems and services that expect a specific format.

For example, an email service may look for a TXT record that defines which servers are allowed to send mail for your domain. A cloud service may ask you to place a verification code in a TXT record to prove that you control the domain. A security setup may use TXT records to publish policy information that receiving systems should check before trusting a message.

This is why TXT records are often described as very flexible. They can hold simple text, but in practice they are often used to carry structured technical information.

Why TXT records matter so much

TXT records matter because many modern internet services rely on them as a simple and standard way to publish small pieces of control or verification data.

They are useful because:

they are widely supported – nearly every DNS provider supports TXT records,
they are flexible – the value can hold many different types of information depending on the use case,
they are easy to query – external systems can look them up through DNS without needing direct access to your hosting or email server,
they work well for verification – adding a TXT record is one of the most common ways to prove control over a domain.

This is also why TXT records show up again and again when connecting domains to third-party tools. They are one of the simplest ways to confirm ownership and publish technical instructions without changing how the website itself loads.

A TXT record is often the “proof” or “policy” record of a domain. It is where systems look when they need to check whether a domain owner has published a verification token, an email rule or another text-based technical instruction.

What TXT records are used for most often

The most common use cases are much more practical than the name “text record” may suggest.

Domain verification – many services ask you to add a TXT record with a specific verification string to prove that you control the domain.
SPF – SPF is published as a TXT record and lists which servers are allowed to send email for the domain.
DMARC – DMARC is also published as a TXT record and defines how receiving mail servers should treat messages that fail email authentication.
Other service integrations – various SaaS tools, security platforms and cloud services use TXT records for domain linking and validation.

That is why TXT records are so common in email administration, but not limited to it. They sit at the point where DNS meets identity, trust and service configuration.

What a TXT record looks like

A TXT record usually contains a hostname or DNS name, the record type TXT, and a value written as one or more text strings.

A simple example could look like this:

example.com TXT "verification=abc123xyz"

Or in the case of SPF:

example.com TXT "v=spf1 include:_spf.google.com -all"

And for DMARC:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

To a non-technical user, these may just look like random strings. In practice, each one follows a specific format expected by the service that reads it.

TXT records do not point to a server

This is one of the most important distinctions. A TXT record does not normally point traffic anywhere. It does not say “go to this IP address” the way an A record does, and it does not say “deliver email to this mail server” the way an MX record does.

Instead, it publishes information. That is why TXT records are often misunderstood by people who expect every DNS record to route a service somewhere. TXT records are more about declaration than about routing.

Put simply, a TXT record says: here is a piece of information about this domain. Other systems can now read it and act accordingly.

Can a domain have more than one TXT record?

Yes. A domain can have multiple TXT records. In fact, this is very common.

For example, one domain may simultaneously publish:

a verification TXT record for Microsoft 365,
an SPF record for email sending,
a DMARC record on the _dmarc subdomain,
another verification token for an external marketing or analytics service.

This is one reason why TXT records need to be managed carefully. They are flexible, but they can also become messy if old values remain in DNS long after a service has been removed.

Having multiple TXT records is normal. The problem is not the number itself. The real issue is whether each one is still needed, correctly formatted and consistent with the current domain setup.

How TXT records relate to email

TXT records are especially important in email configuration. This is where many domain owners first meet them.

For example, SPF is published as a TXT record. DMARC is also published as a TXT record. And depending on the provider, some DKIM-related setups also involve TXT publication of the public key, although some providers instead use CNAME-based DKIM delegation.

This matters because email reliability is not only about where mail is delivered. It is also about who is allowed to send it, how the sender is authenticated and whether the domain publishes the expected trust signals for receiving systems.

That is why TXT records are so often involved in deliverability issues. A website can work perfectly while email authentication still fails because a TXT-based SPF or DMARC configuration is wrong or incomplete.

What can go wrong with TXT records

TXT records are simple in concept, but there are still several common mistakes:

the value is pasted incorrectly,
quotation marks or formatting are changed by mistake,
an old TXT record remains in place and conflicts with the new setup,
the record is published on the wrong hostname or subdomain,
the administrator assumes the change is live immediately, even though DNS cache is still serving older data.

Another practical issue is size and structure. Some TXT values are long, especially in email-related use cases. DNS systems may split long TXT content into multiple quoted strings behind the scenes. That is normal, but it is one of the reasons why copying and editing TXT records manually should be done carefully.

Why TXT record changes do not show up immediately

Like other DNS records, TXT records are affected by caching and TTL. That means even after the authoritative record is changed correctly, part of the internet may still see the older value for some time.

This becomes very visible when verifying a domain with a service that keeps saying “record not found” even though the TXT record has already been added. In many cases, the problem is not that the record is wrong. It is simply that the new value has not yet become visible through the relevant DNS resolvers.

That is why TXT record changes should be checked with DNS lookup tools, not only inside the DNS provider’s control panel.

What are the limits of TXT records?

TXT records are very useful, but they are not meant for everything. They are good for relatively small pieces of text-based data, verification strings and technical policy information. They are not designed to replace proper routing records such as A, AAAA or MX, and they are not a place for large amounts of structured application data.

They are also highly context-dependent. A TXT value only makes sense if the system reading it knows how to interpret it. Without that context, it is just text sitting in DNS.

TXT records are excellent for publishing small pieces of verification or policy data, but they are not general-purpose routing records and not a substitute for the other DNS record types a domain still needs for websites, email delivery and core infrastructure.

Why this term is worth understanding even outside technical roles

TXT records are one of the clearest examples of how DNS is used for much more than pointing a website to a server. They show that modern domains also carry proof, trust signals, service validation and policy information in the background.

If you understand what a TXT record does, it becomes much easier to understand why one service asks you to “add this DNS value”, why a domain verification process may fail for a few hours even after the record is added, or why email authentication depends so heavily on correctly published text-based DNS data.

That is why TXT records matter not only to DNS specialists, but also to website owners, marketers, founders and anyone connecting a domain to external services. They are quiet DNS records, but often some of the most operationally important ones.

Related terms

DNS – TXT is one type of DNS record, and its role makes full sense only in the wider context of how DNS works.
Nameservers – TXT records are stored on authoritative nameservers and served from there to the rest of the internet.
Hostname – important because TXT records may be published on the root domain or on specific subdomains, depending on the use case.
A record – useful for contrast, because A points directly to an IPv4 address, while TXT stores text-based data.
AAAA record – similar to an A record, but for IPv6 rather than IPv4.
MX record – another DNS record type, but with a very different function, since MX controls incoming email routing.
SPF – one of the best-known examples of a policy published through a TXT record.
DMARC – another major email policy record published through TXT.
Domain verification – one of the most common reasons third-party tools ask domain owners to add a TXT record.

DNS

Leave a reply

DNS, short for Domain Name System, is one of the core systems that makes the internet usable in everyday life. Its main role is to translate human-readable domain names into technical information that computers can actually work with – most often the IP address of a server. Thanks to DNS, people do not have to remember strings of numbers just to open a website, send an email or connect to an online service. They can simply use an ordinary domain name, while the technical lookup happens in the background.

At first glance, DNS does not look especially visible or important. Most users never notice it at all. They type in a web address, open a page or send an email, and everything seems to happen instantly. In reality, DNS is one of the key layers that keeps the wider internet working in a practical and understandable way. Without it, normal online use would be far less convenient, because people and businesses would have to work directly with technical addresses instead of simple names.

DNS = the internet system that turns domain names into real destinations. DNS is the system that translates a domain name into the technical record a device needs in order to reach the correct server or service. In practice, this usually means an IP address, but DNS can also store other records for email, verification, security and subdomain behaviour.

What DNS actually does in practice

When someone enters a domain name into a browser, the device does not automatically know where it should connect. It first needs to find the relevant DNS data for that domain. DNS provides that answer by returning the technical record linked to the name. Once that record is found, the browser, email system or other application can continue and connect to the right destination.

This entire step usually happens in a fraction of a second. From the user’s point of view, it looks like the page is simply loading. Behind the scenes, however, the domain has just been translated into a real technical target. That is why DNS is often described as one of the hidden foundations of the internet. It is constantly in use, even when people do not realise it.

DNS is not only relevant for websites. It also plays an important role in email delivery, domain verification, security settings, subdomains and other online services that need to know where traffic should go or how a domain should behave.

Why IP addresses alone are not enough

In theory, internet services could work only with IP addresses. In practice, that would be uncomfortable and difficult to manage. People remember names more easily than numeric strings, and domains are far more practical for websites, email services and business operations.

There is also a broader technical reason. One domain does not have to represent only one website on one server. The same domain can be linked to different types of records at the same time. One record may point the website to a server, another may define where email should be delivered, while another may be used for verification or security-related purposes.

That is why DNS is not just a simple lookup tool for matching one name to one IP address. It is a structured system that stores information about how a domain, or part of a domain, should function in real operation.

The practical value of DNS is simple: people work with clear domain names, while the technical side of the internet uses DNS to find the real destination in the background. Without that layer, both users and domain owners would have to manage technical addresses manually, which would be far less practical.

Which DNS records are used most often

DNS is not one single piece of data. A domain can have multiple DNS records, and each type serves a different purpose. Among the most common are the following:

A record – maps a domain or subdomain to an IPv4 address.
AAAA record – maps a domain or subdomain to an IPv6 address.
CNAME record – points one domain name or subdomain to another domain name.
MX record – defines where incoming email for the domain should be delivered.
TXT record – stores text-based information, often used for verification, email settings or domain policies.

This matters because different DNS changes affect different parts of a service. One update may move a website to a new server. Another may change email routing. Another may affect whether a third-party service can verify domain ownership. DNS therefore has a much wider role than many people first expect.

How DNS is related to nameservers

DNS records must be stored somewhere and served from somewhere. That is where nameservers come in. Nameservers are the servers that hold the DNS records for a domain and provide authoritative answers when someone asks for them.

Put simply, DNS is the system, while nameservers are part of the infrastructure that publishes the actual answers. This distinction matters because the two terms are often used as if they meant the same thing, even though they do not.

In practical administration, when someone says they are “changing DNS”, they are usually editing records stored on the authoritative nameservers for the domain, or changing which nameservers are authoritative for that domain in the first place.

What a DNS resolver does and why it matters

When a user enters a domain name, their device usually does not go directly to the authoritative nameserver of that domain. Instead, it relies on a DNS resolver. The resolver performs the lookup on the user’s behalf, follows the DNS chain and returns the answer that the device needs.

The resolver is also important because it uses cache. That means it temporarily stores DNS answers it has already looked up, so it does not need to repeat the full process every time. This makes internet use faster and more efficient, but it also explains why DNS changes do not appear everywhere at once.

If a resolver still has an older answer stored in cache, it may continue returning that older result for some time. This is one of the key reasons why DNS changes can seem inconsistent across locations, devices or providers.

DNS is a layered system, not one central switch that updates instantly everywhere. Records are served by authoritative nameservers, looked up by resolvers and often stored temporarily in cache. That is why different users may see different results for a while after a DNS change.

Why DNS changes do not take effect immediately

One of the most common real-world situations is a DNS update that looks correct in the control panel, but does not seem fully live yet. A website still points to the old server, email still follows the old route or a verification record does not appear to work immediately. In many cases, this is not a mistake. It is simply how DNS behaves.

The main reason is caching and the TTL value, which stands for Time to Live. TTL tells resolvers how long they may keep a DNS answer in cache before they must ask again for a fresh version. A higher TTL often makes normal lookups faster and more efficient, but it can also make updates take longer to become visible everywhere.

That is why DNS changes are often discussed together with propagation, waiting and checking whether the new state has already spread to the resolvers that matter. In practice, a change may be technically correct on the authoritative nameserver and still not be visible to every user at the same moment.

DNS and email – not just websites

Many people mainly associate DNS with websites, but email depends on it just as much. DNS is used to define where incoming messages should go, which systems are allowed to send mail on behalf of a domain and how receiving servers should treat messages that do not pass certain checks.

This is why DNS is closely linked to terms such as SPF, DKIM and DMARC. These settings are not separate from DNS. They are built on DNS records. If they are incorrect, the problem may not show up on the website at all, but instead in email deliverability, trust and anti-spoofing protection.

That is also why DNS problems are often broader than people expect. A domain may appear to work normally in the browser while still having serious email-related DNS issues in the background.

What DNS does not guarantee

DNS is essential infrastructure, but it does not guarantee that the destination service itself will work properly. If a DNS record points to the wrong server, a broken hosting setup or a mail platform that is not configured correctly, the service may fail even though DNS itself is behaving exactly as it should.

The same applies to performance and security. DNS helps route traffic and publish important service information, but it does not solve server speed, application bugs, hosting quality or broader service security on its own. It is a key connecting layer, but it is still only one part of the wider operational picture.

What are the limits of DNS? DNS is crucial, but it is not a guarantee that a service will work well. It can tell a browser or mail system where to go, but it cannot guarantee that the target server is healthy, that the website loads correctly or that the email service is properly configured. DNS is a fundamental layer of internet infrastructure, not a complete service-quality solution.

Why DNS is worth understanding even outside technical roles

DNS is one of those concepts that many people only notice when something stops working. Yet it is useful far beyond technical administration. Once you understand the basic logic of DNS, it becomes much easier to see why a website may not switch to a new server immediately, why email can misbehave after a domain change or why one user may see the updated version of a service while another still sees the old one.

That is why DNS matters not only to developers or infrastructure teams, but also to website owners, marketers, content managers, founders and business operators. You do not need to become a DNS specialist, but understanding the basics helps you make better decisions and communicate more clearly when domain-related issues appear.

DNS is worth understanding because it shows how the internet works beneath the surface. It may seem invisible in day-to-day use, but it plays a central role whenever a domain needs to point to the right place, email needs to be trusted or an online service needs to behave as expected.

Related terms

Nameservers – servers that store DNS records for a domain and provide authoritative answers to DNS queries.
TTL (Time to Live) – the value that tells resolvers how long they may keep a DNS answer in cache before requesting a fresh copy.
DNS resolver – the service that looks up DNS records on behalf of the user and returns the result based on available data and cache.
DNS cache – a temporary stored copy of DNS answers that speeds up browsing and other lookups, but also delays how quickly changes appear everywhere.
MX record – a DNS record that defines where incoming email for a domain should be delivered.
SPF, DKIM, DMARC – email-related authentication and policy records that show DNS is not only about websites, but also about email trust, verification and delivery.

Bagging

Leave a reply

Bagging stands for bootstrap aggregating. It is a machine learning method that does not rely on a single model, but on multiple versions of the same model trained on different samples of the same dataset. Its purpose is not to turn an average model into something extraordinary. Its real value lies in making predictions more stable when the underlying model is too sensitive to the exact data it was trained on. That is why bagging is most commonly associated with models that tend to vary a lot from one training sample to another – especially decision trees.

At first glance, bagging may look like a technique that simply repeats the same process several times. In reality, its strength comes from the fact that each model sees the same problem through a slightly different sample of the data. Those individual views are then combined into a single prediction that is usually more stable and more reliable than the output of one standalone model.

Bagging is an ensemble method that trains multiple versions of the same model on different randomly drawn training samples and then combines their predictions into one final result. In classification, this usually means voting. In regression, it usually means averaging. The goal is to reduce instability and make the final prediction less sensitive to random quirks in the training data.

What bagging actually does

Bagging is built on a simple but very effective idea.

Instead of training one model, you train several models of the same type. Each of them learns from a slightly different training set created from the original data. These are not completely new datasets. They are known as bootstrap samples, which means they are created by random sampling with replacement.

In practice, this means that some records may appear several times in one sample, while others may not appear at all. That small difference is enough to make each model learn a slightly different version of the same problem. Bagging then takes advantage of those differences rather than treating them as a drawback.

Why one model is often not enough

In many tasks, a single model can perform reasonably well and still be unnecessarily sensitive to the exact data it was trained on. Change the training set slightly, and the model may behave differently. This is especially true for unstable models, where even a small change in the data can lead to a noticeably different structure and a different result.

Bagging addresses that weakness by avoiding reliance on a single trained model. Instead, it creates several models, each trained on a different variation of the data. Once their outputs are combined, the influence of random fluctuations becomes weaker. The final prediction is usually more balanced and less likely to overreact to noise in the dataset.

Bagging is not about finding one “best” model. Its strength lies in combining several separate versions of the same model so that the final result is less influenced by chance, noise or oddities in a single training sample.

What bootstrap aggregating means

The name itself captures the logic of the method quite well. Bootstrap refers to the way the training samples are created – by random sampling with replacement. Aggregating refers to combining the outputs of multiple models into one final prediction.

In classification tasks, the usual approach is majority voting. Each model predicts a class, and the final result is the class that appears most often. In regression tasks, the outputs are typically averaged. In both cases, the principle is the same: instead of trusting one model entirely, the final result is based on the combined effect of several models.

Why bagging is so often linked to decision trees

Bagging can be used with different model types, but it is most often discussed in connection with decision trees. The reason is straightforward. Decision trees can be very useful, but they are also quite sensitive to small changes in the data. If the training set changes slightly, the tree may choose a different early split, grow a different structure and end up making different decisions.

That is exactly why bagging works so well with trees. It keeps their natural strength – their ability to capture complex relationships – while reducing their instability. From there, it is only a short step to methods such as random forests, which are built directly on the same idea.

How bagging relates to model variance

In machine learning, bagging is most commonly associated with reducing variance. Put simply, it helps in situations where a model reacts too strongly to the exact data it was trained on and therefore produces results that fluctuate more than they should.

That matters in practice. Most users do not care whether a model has “high variance” in a textbook sense. What matters is whether its output feels dependable and whether it changes too much for the wrong reasons. This is where bagging helps. It does not promise perfection, but it often makes a model more robust and more consistent.

Bagging is not the same as boosting

These two terms are often confused because both belong to the broader family of ensemble methods. In practice, however, they solve different problems in different ways. Bagging builds several models in parallel and combines their outputs. Boosting does the opposite: it builds models sequentially, with each new model focusing more heavily on the mistakes made by the previous ones.

This is the key difference: bagging improves results by combining several independently trained models and reducing variation in their predictions. Boosting follows a different logic – it builds models step by step, with each stage designed to correct earlier mistakes. In simple terms, bagging is mainly about stability, while boosting is mainly about correction. Both can work very well, but they are not interchangeable.

Where bagging is used in practice

Bagging is most useful when a model can extract a meaningful signal from the data, but its output changes too much depending on the exact sample it was trained on.

A typical example is a decision tree. A tree may perform well overall, but even a small change in the training data can lead it to choose a different first split, grow a different structure and produce a different result.

A practical AI example would be an email classification system that sorts incoming messages into categories such as refund request, sales enquiry or technical support. One decision tree might place a lot of weight on words like “return”, while another might focus more on phrases such as “not working” or “order issue”. If the system relied on just one tree, the result could be overly sensitive to the exact shape of the training data. Bagging reduces that risk by building several trees on different samples of the data and combining their outputs through voting.

The same logic applies to regression tasks. Imagine a model that estimates future energy consumption, property prices or the likelihood of customer churn. A single tree may react too strongly to a handful of unusual cases and produce an unstable estimate. If you train several trees on different bootstrap samples and average their predictions, the result is usually more reliable.

That is where bagging becomes practically valuable. It does not introduce a completely new learning logic. Instead, it reduces the influence of chance and of quirks in one particular training sample. The result is a more robust prediction that is less dependent on the model having fitted one specific version of the data too closely.

What are the limits of bagging?Bagging is useful, but it is not a universal answer to every modelling problem. It works best when the underlying model is unstable and has relatively high variance. If the base model is already very stable, the benefit may be limited. In some cases, bagging brings only a modest improvement while significantly increasing computational cost. It also does not fix everything. If the data is poor, the model choice is wrong or the objective is badly defined, combining multiple models will not solve the core problem. Bagging is a strong technique, but it is still only one part of a broader modelling and training strategy.

Where bagging matters outside technical fields

Bagging has practical value far beyond technical or academic work. It is useful wherever prediction stability matters. Typical examples include finance, insurance, marketing, e-commerce and customer service – in other words, areas where models are used to estimate risk, predict customer behaviour, classify requests or forecast demand.

In these settings, the problem is not just whether a model can make a decent prediction once. The real issue is whether its output remains dependable and does not shift too much because of random variation in the training data. Bagging helps by combining several versions of the same model instead of relying on just one. The result is often a more stable and more trustworthy prediction, which in real-world use is often more valuable than a model that appears slightly “smarter” but behaves inconsistently.

This is also why bagging is worth understanding beyond purely technical contexts: it shows that in AI, a more reliable result does not always come from one supposedly superior model. In many cases, it comes from combining several similar models in a way that reduces noise and makes the final output more dependable.

Related terms

Machine learning – bagging belongs to machine learning because it learns from data rather than from hand-written rules. The difference is that instead of relying on one trained model, it works with several variants trained on different samples and combines their outputs.
Decision tree – bagging is most commonly used with decision trees because it helps reduce their natural sensitivity to changes in training data.
Ensemble method – bagging belongs to this family of approaches because it works with multiple individual models and combines their outputs into one final prediction that is usually more stable than the output of a single model.
Model variance – this term helps explain why some models fluctuate too much and why combining them often leads to more consistent results.
Bootstrap – this is the technical foundation of bagging, because it defines how different training samples are created for individual models.
Boosting – this helps distinguish two ensemble methods that are often mentioned together, even though they combine multiple models in very different ways.

Machine learning

Leave a reply

Machine learning is a branch of artificial intelligence in which systems learn from data instead of relying only on fixed, hand-written rules. A model is trained on examples, looks for patterns in those examples and then uses what it learned to make predictions, classifications or estimates on new data. That is the core idea. The system is not told every possible answer in advance. Instead, it learns a useful structure from past observations and applies it to cases it has not seen before.

At first glance, machine learning may sound like a highly technical concept reserved for researchers or developers. In reality, the underlying logic is straightforward. Many real-world problems are too complex to solve with rigid rules alone. It is relatively easy to define a rule for something simple, but much harder to manually describe every possible variation of spam email, customer behaviour, product demand, credit risk or image content. Machine learning is used in such situations because it allows a system to improve its output by learning from examples.

Machine learning is not about a machine “thinking” like a person. It is about training a model on data so it can detect useful patterns and apply them to new cases. The model does not learn in a human way, but it can still become very effective at specific tasks.

What machine learning actually means

Machine learning starts from a simple practical problem. You have data, you have an outcome you care about, and you want a system to discover a useful relationship between the two.

For example, you may want to predict whether a transaction is fraudulent, estimate how many products will be sold next week, classify a support request or recommend an article to a reader. In each case, the model is trained on historical examples. It analyses which patterns in the data tend to be associated with which outcomes.

That is why machine learning differs from traditional rule-based programming. In a rule-based system, a developer must explicitly define what should happen in each situation. In machine learning, the developer still defines the goal, the training process and the model type, but the detailed decision structure is learned from data.

Why rules are often not enough

There are many tasks where strict rules work perfectly well. If a customer adds products to a basket and clicks the payment button, the system does not need machine learning to calculate the total price. A deterministic rule is enough.

But many useful tasks are not so clean. Consider email filtering. A spam message does not always follow one obvious pattern. Some spam emails use suspicious wording, others imitate legitimate communication and others rely on formatting tricks rather than clearly suspicious phrases. Writing a complete manual rule set for every such case quickly becomes inefficient and fragile.

The same applies to product recommendations, demand forecasting, credit scoring, fraud detection and image recognition. These tasks involve patterns that are too varied or too subtle to describe exhaustively by hand. Machine learning becomes useful because it can absorb those patterns from examples rather than from manually written logic.

Machine learning is most valuable when the problem is too variable, too large or too complex for a fixed set of rules. It works especially well where useful patterns exist, but those patterns are difficult to write down manually in advance.

How a machine learning model learns

The learning process usually begins with a dataset. That dataset contains observations, often called examples or records, and each example includes features. Features are the pieces of information the model uses to learn. In a churn model, features may include purchase history, service usage and support contacts. In an image model, they may be visual patterns encoded numerically.

The model is trained by adjusting its internal parameters so that its predictions become closer to the desired outcome. Different models do this in different ways. A decision tree splits data into branches. A linear model assigns weights to variables. A neural network adjusts many layers of internal connections. The details differ, but the goal is the same: improve the model’s ability to generalise from past data to new cases.

This is an important point. A model should not only perform well on data it has already seen. It should also work on unseen data. That is why evaluation matters so much in machine learning. A model that memorises training examples without learning a broader pattern may look good during training and still perform poorly in real use.

Main types of machine learning

Machine learning is not one single method. It is a broad field that includes several different learning setups.

The best known is supervised learning. Here, the model is trained on labelled examples. It sees inputs together with the correct outcome and learns to predict that outcome. This is common in classification and regression tasks.

Another major category is unsupervised learning. In that case, the data has no explicit target label, and the goal is to find structure inside the data itself. That may mean grouping similar customers, detecting anomalies or reducing complexity in the dataset.

There is also reinforcement learning, where a system learns through feedback from actions and outcomes over time. This is used in more specialised areas such as game playing, robotics or decision optimisation.

In practical business settings, most common uses of machine learning fall under supervised learning, because companies usually want to predict something concrete such as demand, risk, conversion, fraud or churn.

Why machine learning includes many different methods

One reason machine learning can seem confusing is that it contains many model families. Decision trees, logistic regression, random forests, boosting methods and neural networks all belong to machine learning, but they do not behave in the same way.

Some models are easier to explain and audit. Others may capture more complex relationships but require more data, more computing power or more careful tuning. Some methods are stable and simple. Others are powerful but sensitive to changes in training data.

This is where terms such as bagging, boosting, variance and bootstrap become relevant. They do not replace machine learning as a field. They describe specific techniques or ideas within it. Bagging, for example, belongs to machine learning because it trains models on data, but it focuses specifically on improving stability by combining multiple models rather than relying on only one.

Where machine learning is used in practice

Machine learning is already part of many everyday systems, even when users do not notice it directly.

It is used in fraud detection to identify suspicious transactions, in streaming platforms to recommend films or songs, in retail to forecast demand, in search engines to rank results, in customer support to sort requests and in healthcare to help identify patterns in medical data. In industrial settings, it can be used for predictive maintenance. In marketing, it can be used for segmentation, scoring or response prediction.

What connects these applications is not the industry, but the structure of the problem. There is data, there is a useful outcome and there is enough repetition for a model to learn something meaningful from examples.

What are the limits of machine learning?Machine learning can be powerful, but it is not a shortcut around poor data, unclear goals or weak system design. If the data is biased, incomplete or badly prepared, the model will learn from those weaknesses as well. It also does not automatically “understand” the problem domain. A machine learning system can be useful, but only when the data, objective and evaluation process are all handled properly.

Why machine learning matters outside technical fields

Machine learning matters far beyond engineering or academic research because many industries now depend on better prediction and better decision support.

In finance, the goal may be risk estimation. In e-commerce, it may be recommendation and demand planning. In customer service, it may be ticket routing. In logistics, it may be forecasting and anomaly detection. In each case, the value is not that the system looks intelligent in an abstract sense. The value lies in improving real decisions, reducing manual effort or identifying patterns at a scale that would be difficult for people alone.

This is also why machine learning should not be understood as one futuristic technology with one fixed meaning. It is a practical field built around a simple idea: if useful patterns exist in data, models can often be trained to detect and apply them in a structured way.

Related terms

Decision tree – a model that makes predictions by splitting data into branches based on conditions.
Ensemble method – an approach that combines multiple models into one final result.
Model variance – describes how much a model’s output changes when the training data changes.
Bootstrap – a sampling technique used to create repeated training samples from the same dataset.
Bagging – a machine learning technique that improves stability by combining multiple models trained on bootstrap samples.
Boosting – an ensemble method that builds models sequentially so later ones focus more on earlier mistakes.

A records

Leave a reply

An A record is a DNS record that translates a domain or hostname into a specific IPv4 address. This is what allows the internet to determine which server it should connect to when someone opens a website, an app or another service available under a specific name. So if a domain leads to a server over IPv4, the A record is what tells DNS which IP address belongs to it.

At first glance, an A record can seem like a basic technical detail that only comes up when hosting is being configured.

In reality, it is one of the most important DNS records of all. As soon as a domain or subdomain points to a specific server, the A record is very often the reason why.

An A record translates a domain name or hostname into an IPv4 address. In other words, when someone enters the name of a website or service, the A record helps determine which exact server the request should actually be sent to.

What an A record actually does in practice

When a user enters a domain into the browser, the device does not automatically know which IP address it should connect to.

First, the name has to be translated into a specific numeric network destination. That is exactly the role of the A record. If the domain or hostname is available over IPv4, the A record returns the matching IPv4 address, for example 203.0.113.10.

This means the A record is not the website itself and not the server itself. It is DNS information that says which IPv4 address belongs to that name.

Why it is called an A record

The letter “A” stands for Address.

It is one of the oldest and most fundamental DNS record types. That is exactly why it appears so often – it solves one of the most basic DNS tasks possible: translating a name into the address of a server.

In practice, the important thing is that an A record does not deal with aliases, email routing or other special DNS functions. Its role is very direct – to say which IPv4 address belongs to a given name.

What an A record looks like

An A record contains two main pieces of information:

the domain or hostname,
the IPv4 address that name should point to.

In practice, this means that a hostname such as www.example.com may have an A record with the value 203.0.113.10. When someone opens that name, DNS returns that IP address and the browser connects to the correct server.

The user enters a domain name or hostname, but the network ultimately needs an IP address. The A record is the DNS step that turns the name into a real technical destination.

What is the difference between an A record and an AAAA record?

An A record and an AAAA record solve a very similar problem, but for different address families.

A record maps a name to an IPv4 address.
AAAA record maps a name to an IPv6 address.

So both records do similar work, but each one is used for a different version of the Internet Protocol. In practice, one domain can have both at the same time. That is common when a service should be reachable over both IPv4 and IPv6.

Where A records are used most often

An A record is used anywhere a domain or subdomain should point directly to a specific IPv4 address of a server.

Typical examples include:

the main website,
subdomains such as www, blog or app,
application servers,
internal or dedicated services accessible through a specific hostname.

That is why A records are so common when setting up hosting, moving a website or pointing subdomains to particular services.

Why a domain can have more than one A record

A domain or hostname does not have to have only one A record.

In some situations, it can have multiple IPv4 addresses at the same time. This is used, for example, for traffic distribution, higher availability or redundancy. DNS can then return multiple answers and the client connects to one of them depending on its own behaviour and network conditions.

So multiple A records are not necessarily a mistake. On the contrary, they may be part of a fully intentional and technically correct setup.

An A record is not the same thing as a CNAME

This distinction is important.

An A record points directly to an IPv4 address. CNAME, by contrast, does not point directly to an IP address at all. It creates an alias from one name to another name. So if you need a name to point directly to a specific IPv4 address, the correct choice is an A record. If you want one name to inherit its destination from another hostname, the correct choice is CNAME.

That is why these two record types should never be treated as interchangeable. They are both important, but they solve technically different tasks.

Important point: an A record leads directly to an IPv4 address. If you need direct routing to a specific server, that is the right choice. If you only need an alias to another hostname, that is where CNAME belongs, not an A record.

How an A record relates to a hostname

An A record is always tied to a specific name – in other words, to a domain or hostname.

That means it does not belong to “the server in general”, but to the specific name under which that server or service should be reachable. One hostname can have one A record, while another hostname can have a different one. This is exactly how DNS distinguishes which service leads to which technical destination.

How an A record relates to hosting

When hosting changes, the A record is very often one of the main things that changes with it.

If you move a website to a new server, you usually receive a new IPv4 address that the domain should point to. That is the address that needs to be written into the A record. If the domain still points to the old IP address, it will continue leading users to the previous server even after the migration.

That is why the A record is one of the first things checked when a website is moved, hosting is changed or old content is still showing after a migration.

Why an A record change does not show up immediately

Like other DNS changes, an A record change does not become visible across the whole internet immediately.

The reason is caching and the TTL value. DNS resolvers keep older answers in memory for some time before they fetch the new version. That means some users may still see the old server for a while even though the A record has already been updated.

That is why A record changes normally come with some propagation time.

What happens if the A record is missing or wrong?

If a domain or hostname needs to be reachable over IPv4 and the A record is missing, DNS will not be able to return the correct IPv4 address. The result may be an unavailable website or another unavailable service.

If the A record is configured incorrectly, the domain may point to the wrong server. This often happens during hosting migrations, manual DNS edits or simple IP-address typing mistakes.

So the practical rule is straightforward: if the domain should lead to a specific server over IPv4, the A record must be correct and current.

Why this term is worth understanding even outside technical roles

The A record is one of those terms that looks technical at first, but in reality it sits behind many everyday situations that people outside IT still have to deal with.

As soon as a website is moved to new hosting, a new subdomain is created or a domain starts pointing somewhere it should not, the A record is often part of the explanation. Once you understand what this record does, it becomes much easier to see why the domain name alone is not enough and why the internet still needs a specific IP address to reach the right server.

That is why the A record matters even outside technical professions. It is one of the simplest but most important examples of how DNS turns a human-readable name into a real network destination.

Related terms

DNS – the A record is one of the most basic DNS record types, and its role only makes full sense in the wider context of DNS.
IP address – the A record translates the name into a specific IPv4 address.
Hostname – the A record is tied to a specific hostname or domain and defines which IPv4 address belongs to it.
AAAA record – the direct counterpart of the A record for IPv6 and the clearest comparison for understanding the difference between the two address families.
Nameservers – authoritative nameservers are where A records are stored and from where the internet looks them up.
CNAME – an important related concept, because unlike an A record, CNAME does not point directly to an IP address, but to another hostname.