🖍️Tomaz Bratanic - Collected Quotes

"A knowledge graph is a data structure that uses nodes to represent concepts and entities and relationships to connect these nodes. [...] Knowledge graphs are highly versatile, capable of storing both structured information (such as employee details, task statuses, and company hierarchies) and unstructured information (such as article contents). This dual capability [...] makes them uniquely suited for complex RAG applications. [...] By integrating structured and unstructured information in the same framework, knowledge graphs enable the seamless blending of both worlds, making them a powerful tool for answering a broad range of questions efficiently and accurately in RAG applications. Moreover, explicit connec-tions between unstructured and structured data unlock advanced retrieval strategies such as linking entities in text to graph nodes or contextualizing structured results with source passages that would be difficult or impossible to achieve using either type of data alone."(Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"An embedding is a way to represent complex data as a set of numbers in a simpler, lower-dimensional space. Think of it as translating data into a format that a computer can easily understand and work with. Embedding models provide a uniform way to represent different types of data. Input to an embedding model can be any complex data, and the output is a vector. For instance, in dealing with text, an embedding model will take words or sentences and turn them into vectors, which are lists of numbers. The model is trained to ensure that these number lists capture essential aspects of the original words, such as their meaning or context." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"Hallucinations occur because LLMs are not reasoning engines. They are probabilistic language models trained to predict what sounds like a good next token, based on patterns in their training data. They don’t know facts the way humans do. Rather, they generate text by guessing the most likely continuation, regardless of whether it’s true. This fundamental difference between statistical pattern matching and actual understanding is what separates LLMs from human cognition." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"In the RAG process, the user starts by asking a question. Behind the scenes, the system turns that question into a search query and retrieves relevant information from sources like company documents, knowledge articles, or databases. Advanced retrieval algorithms find the most suitable content, which is then combined with the original question to form an enriched prompt. This prompt is sent to an LLM, which gener-ates a response based on both the question and the retrieved context. The entire retrieval process is automatic, and no extra input is required beyond the original ques-tion from the user. This makes RAG both seamless and effective, improving factual accuracy while reducing the chance of hallucinated answers." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"Knowledge graphs are increasingly used to store both structured and unstructured data, a scenario that has become even more common with the advent of LLMs. In this context, LLMs can be used to extract structured data from unstructured sources like text documents. However, storing the original unstructured documents and the extracted structured data within the graph preserves the richness of the original data while enabling more precise querying and analysis of the extracted information." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"[...] LLMs are great at understanding natural language and following instructions in the prompt. In the RAG workflow, the goal shifts to task-oriented response generation, where LLMs follow a set of instructions. The process involves utilizing a retrieval tool to fetch relevant documents from a specific knowledge base. The LLM then generates answers based on the provided documents, ensuring responses are accurate, contextually relevant, and aligned with specific guidelines. This systematic approach transforms the answer generation process into a targeted task of inspecting and using the retrieved information to produce the final answer." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"LLMs are rapidly improving, not only in their ability to understand and generate language but also in how effectively they can use external tools for data retrieval, transformation, and manipulation. As these models become more capable, they will be able to perform increasingly complex tasks with minimal prompting. However, their effectiveness still depends on the quality, design, and integration of the tools you provide. It’s your job to implement those tools thoughtfully and efficiently, ensuring they are well suited to your system’s goals and constraints." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"The result from a semantic classification of text is called an embedding. Any text you want to match using vector similarity search must be converted into an embedding. This is done using an embedding model, and it’s important that the embedding model stays the same throughout the RAG application. If you want to change the embedding model, you must repopulate the vector index. Embeddings are lists of numbers, and the length of the list is called the embedding dimension. The embedding dimension is important because it determines how much information the embedding can hold. The higher the embedding dimension, the more computationally expensive it is to work with the embedding, both when generating the embedding as well as when performing vector similarity search."(Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

"While a vector index isn’t strictly required for vector similarity search, it’s highly recommended. A vector index is a data structure (like a map) that stores vectors in a way that makes it easy to search for similar vectors. When using a vector index, the retriever method is often referred to as an approximate nearest neighbor search. This is because the vector index doesn’t find the exact nearest neighbors, but it finds vectors that are very close to the nearest neighbor. This is a tradeoff between speed and accuracy. The vector index is much faster than a brute-force search, but it’s not as accurate." (Tomaz Bratanic & Oskar Hane,"Essential GraphRAG: Knowledge Graph-Enhanced RAG", 2025)

🤖Prompt Engineering: Security (Just the Quotes)

"Prompt injection is a security vulnerability that is specific to AI systems, especially LLM systems, in which malicious users try to manipulate prompts to make a model behave in a certain unintended way. They may try to get it to leak data, execute unauthorized tasks (especially with agentic systems), or ignore constraints. This is possible because LLMs are typically encapsulated inside applications using metaprompts, which are developer-created instructions that define the model’s behavior. Metaprompts usually contain safeguard instructions, such as 'do not use curse words', and placeholders where the input submitted by the user is pasted. The user’s input is combined with the metaprompts into a larger prompt that then goes to the model." (Abi Aryan, "LLMOps: Managing Large Language Models in Production", 2025)

"Authentication and authorization are important parts of any communication between clients and servers. We need to have a clear separation between different roles and to be able to specify what capabilities a particular client is allowed to invoke. MCP, however, is more of a language interoperability protocol - it doesn’t enforce any security principles. [...] Collaboration In MCP, communication between the client and the server is mostly one way, whereas in the real world, you may want collaborative, interactive workflows." (Valliappa Lakshmanan & Hannes Hapke, "Generative AI Design Patterns: Solutions to Common Challenges When Building GenAI Agents and Applications", 2026)

"LangGraph handles the perception, reasoning, and action flow while maintaining memory and context across tasks. In this sense, it functions as both the development environment and the orchestration layer - coordinating the steps of perception, reasoning, and action while managing connections to external systems. Underneath this, emerging standards like MCP ensure that agents can connect securely and consistently to tools and data sources, making agentic architectures portable and scalable across platforms. Taken together, the orchestration layer and emerging interoperability standards like MCP form the foundation for scalable agentic AI. They make it possible for agents to perceive, reason, act, and learn in coordinated ways across complex environments, translating autonomous intelligence into practical, enterprise-grade capability." (Fern Halper, "Data Makes the World Go 'Round", 2026)

"Like penetration testing in cybersecurity - the authorized simulation of attacks to uncover weaknesses in a system before real attackers can exploit them - prompt hacking can be a force for good when done with permission and clear boundaries. Red-team testing is a structured effort to find flaws and vulnerabilities in an AI system, performed in a controlled environment and in collaboration with the system’s developers. Ethical 'red teamers' adopt an attacker’s mindset to systematically probe an AI’s defenses, but they do so to improve safety, not to cause harm. Guides on red teaming recommend starting with baseline tests, defining a threat model, and then iterating with more sophisticated attacks. Sharing findings with the development team helps fix vulnerabilities before malicious actors discover them." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"RAG applications must be built with semantics, metadata, and governance in mind. The retrieved information must be high-quality, secure, and appropriate for the user’s role. Equally important is monitoring and management: checking whether source data has changed, ensuring vector stores remain accurate, and watching for hallucinations or data leakage. Organizations are definitely starting to experiment with RAG models today; some are putting them into production applications. Some believe that using RAG helps mitigate hallucinations because it is grounded in trusted organizational data." (Fern Halper, "Data Makes the World Go 'Round", 2026)

"The Model Context Protocol (MCP) is emerging as a standard for connecting AI models to external tools and data sources. Historically, developers had to build custom connectors for each model and API, limiting portability and slowing innovation. MCP simplifies this by creating a common interface, essentially a universal plug like USB-C, that allows compliant models and tools to communicate seamlessly. Frameworks like LangChain/Graph and others are expected to adopt MCP to handle connectivity under the hood, providing developers with interoperability while maintaining secure and auditable access to enterprise systems." (Fern Halper, "Data Makes the World Go 'Round", 2026)

"The most common form of prompt hacking is prompt injection. This occurs when an attacker embeds malicious instructions inside a seemingly innocuous prompt to override the developer’s intended task. The root of the problem is architectural: current language models treat all text, including system prompts, developer instructions, and user input, as one continuous sequence. There is no built-in notion of 'trusted' versus 'untrusted' input, so a later instruction can supersede an earlier one. The simplest version is direct injection, where the attacker places the malicious directive directly in the user’s input. A classic example exploits the fact that models prioritize more recent or specific instructions [...] Indirect injection hides instructions in external content, such as a web page or document the model is asked to summarize, so the model executes code it wasn’t supposed to see. Specialized variants include code injection, where a code-generation assistant is tricked into outputting malicious commands, and recursive injection, where the output of one model carries an injection to the next in a chain. All of these attacks exploit the model’s inability to separate context from instruction." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"The power of RAG systems stems from their ability to access and process vast amounts of data. However, this very capability introduces significant risks regarding the privacy of individuals and the security of sensitive information. Unlike a simple chatbot, a RAG system often has access to proprietary corporate data, internal documentation, and potentially personal user information within its knowledge base. A data breach or misuse of this information can lead to severe financial, legal, and reputational damage. Furthermore, a global patchwork of stringent regulations now governs how personal data must be handled, making compliance a central pillar of AI system design, not an afterthought. Ethical deployment requires an architecture built on privacy by design and by default, ensuring user trust is maintained through robust technical and procedural safeguards." (Saloni Garg et al, "RAG Artificial Intelligence: Retrieval-Augmented Generation in Generative AI", 2026)

"With autonomous agents there is the risk that they can take action that isn’t governed. These systems introduce autonomy, interdependence between agents, and possibly emergent behavior. [...] Because agents act autonomously, a single misconfigured or misaligned agent can propagate errors at scale. In multiagent environments, one faulty output can trigger many downstream mistakes. Other risks include tool misuse, conflicting goals among agents (and other interoperability issues), and operational opacity, when teams cannot easily determine which agent took which action or why. Governance must extend to agent registration, version control, permissioning, and simulation testing before deployment. Likewise, accountability may also blur. If an agent takes a dangerous action, who is responsible? There are, of course, cybersecurity risks as agents pose a new attack surface."  (Fern Halper, "Data Makes the World Go 'Round", 2026)

🤖Prompt Engineering: Bias (Just the Quotes)

"LLMs can inadvertently produce toxic content or biased language, leak private information, or be vulnerable to jailbreak prompts. These risks carry serious legal and reputational consequences. To mitigate them, evaluation tools must integrate automated filters and classifiers that flag problematic outputs in real time, as we discussed earlier in the chapter. Metrics such as safety scores, toxicity indices, and bias measurements should be collected alongside model metadata for auditing purposes." (Abi Aryan, "LLMOps: Managing Large Language Models in Production", 2025

"LLM-centric workloads change everything. Now the raw material is heterogeneous text, code, images, audio, and chat logs whose value depends on semantic richness - that is, the informational value of the content - rather than a rigid structure. Pipelines must tokenize, chunk, embed, and version this content; store it in vector indexes for similarity search; and apply filters for personally identifiable information, toxicity, and licensing constraints. Instead of ETL jobs, teams run continuous ingestion and reembedding loops so that RAG systems stay fresh, and they log every prompt–response pair so that the inputs and outputs can be evaluated and improve the future performance of this system. Data quality in this context is judged by grounding, factuality, and bias metrics - attributes that require automated red-teaming and humanin-the-loop (HITL) review rather than the data structure violation checks of the past." (Abi Aryan, "LLMOps: Managing Large Language Models in Production", 2025)

"LLMs excel at understanding context and making associations among words, phrases, and concepts to provide relevant information based on the input query or prompt. While structured knowledge bases rely on humancurated data, LLMs can  automatically extract knowledge from unstructured text. When trained on diverse textual sources, they can process a vast amount of information without explicit human intervention. However, this also introduces a challenge, as the model can learn biased or incorrect information from the training data." (Abi Aryan, "LLMOps: Managing Large Language Models in Production", 2025)

"Because LLMs are probabilistic, it’s possible for them to generate responses that are biased, toxic, false, or off-topic for your application. If a user submits prompts to an LLM that contain profanity or hate speech, it increases the chances that the generated content will contain inappropriate language. Such interactions can create legal liability or brand damage. LLMs are also vulnerable to attack by malicious users who attempt to convince the LLM to reveal sensitive corporate data or personally identifiable information (PII)." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Before releasing the fine-tuned model to a production environment, you need to evaluate its performance and make sure it hasn’t picked up any counterproductive constructs, like biased language. Also, whenever a new version of your foundational model is released, you must fine-tune the model again and redo the training. Finally, you need to track the lineage of the training and validation data used to train the fine-tuned model. These are additional tasks that require careful execution, and using in-context learning is far simpler since it only requires you to add a handful of examples." (Valliappa Lakshmanan & Hannes Hapke, "Generative AI Design Patterns: Solutions to Common Challenges When Building GenAI Agents and Applications", 2026)

"Bias can creep in through multiple channels. Training data often reflects the cultures and languages most represented on the internet, which can leave out or misrepresent others. Prompts themselves can encode bias through how tasks or roles are framed. And even the architecture of a model can favor certain patterns of output over others, reinforcing statistical tendencies rather than producing balanced results. As a developer, you can’t eliminate bias entirely. But you can recognize where it comes from, test for it, and design safeguards to minimize harm." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)  

"Generative AI has a lot of problems because it needs a lot of data to work. Generative models like GPT and GANs need a lot of training data to learn patterns and make good outputs. This data dependency can cause problems like overfitting, which happens when the model does well on training data but doesn’t work well with new, unseen data. Also, the quality of the content that is generated is directly related to the diversity and representativeness of the training data. This means that biased or incomplete datasets can lead to outputs that are wrong or unfair." (Saloni Garg et al, "RAG Artificial Intelligence: Retrieval-Augmented Generation in Generative AI", 2026)

"If ethical lapses or AI failures occur, the impact on a business can be significant. Misinformation, biases, or harmful content generated by AI can lead to reputational damage, customer distrust, and potential regulatory scrutiny. The public relations fallout from an AI-driven error or ethical misstep can erode consumer confidence, resulting in lost revenue and lasting harm to brand image. Businesses, therefore, need to proactively address ethical considerations in AI implementation, not only to ensure compliance but also to protect and strengthen their reputation in a highly competitive, and increasingly transparent, marketplace." (Bennie Haelen, "ML and Generative AI in the Data Lakehouse Building and Deploying AI Applications at Scale", 2026)

"[...] LLMs raise serious concerns about ethics, bias and fairness, errors in reasoning, hallucinations, and misuse (e.g., misinformation and disinformation). These concerns are exacerbated by modern LLMs being both literal and figurative 'black boxes': Literal black boxes because many advanced AI systems are proprietary and the weights (trained parameters of the models) are not released to the public; and figurative black boxes because even the open-source AI models are so complicated that understanding them and developing safety guardrails has thus far proven extremely difficult." (Mike X Cohen,"50 ML Projects To Understand LLMs", 2026)

"The promise of AI is its ability to process information objectively and at scale. However, this promise is fundamentally threatened by the twin challenges of bias and misinformation. AI systems are not born in a vacuum; they are created by humans and trained on data produced by humans. Consequently, they are prone to inheriting and even amplifying our prejudices, errors, and the systemic inequalities present in that data. In a RAG system, this risk is a two-fold problem: first in the retrieval of information, and second in the generation of a response based on that retrieval. A failure to address these issues doesn’t just lead to technically incorrect outputs; it can perpetuate social harm, erode public trust, and lead to the widespread dissemination of falsehoods. Therefore, understanding and mitigating bias and misinformation is not an optional add-on but a core requirement for any ethically deployed AI system." (Saloni Garg et al, "RAG Artificial Intelligence: Retrieval-Augmented Generation in Generative AI", 2026)

🖍️Chris Minnick - Collected Quotes

"[...] a transformer is a neural network that uses attention to understand and generate sequences of data efficiently and flexibly, allowing it to capture complex relationships across long inputs. Unlike older models, transformers process all parts of the input in parallel, making them much faster and more scalable than older types of neural networks." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Although GenAI gets most of the attention for its ability to create new content, successful AI applications often combine multiple approaches. Generative models aren’t always the optimal choice for every component of an AI system. Traditional ML models, rule-based systems, and algorithmic approaches can offer significant advantages in speed, accuracy, cost-effectiveness, and reliability when used strategically alongside GenAI." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"As with any software system, designing GenAI interfaces with accessibility in mind is essential to inclusive, humane design. It may also be required by law. AI features in applications often introduce new interaction patterns, dynamic content, and inferred behaviors that, without care, can unintentionally exclude users with visual, auditory, motor, or cognitive impairments. Many accessibility principles extend naturally to AI scenarios, and GenAI can help automate inclusive experiences when responsibly implemented. Generative models may produce rich, interactive content, but AI-only overlays or content modifications risk causing confusion or misrepresentation." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Because LLMs are probabilistic, it’s possible for them to generate responses that are biased, toxic, false, or off-topic for your application. If a user submits prompts to an LLM that contain profanity or hate speech, it increases the chances that the generated content will contain inappropriate language. Such interactions can create legal liability or brand damage. LLMs are also vulnerable to attack by malicious users who attempt to convince the LLM to reveal sensitive corporate data or personally identifiable information (PII)." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Bias can creep in through multiple channels. Training data often reflects the cultures and languages most represented on the internet, which can leave out or misrepresent others. Prompts themselves can encode bias through how tasks or roles are framed. And even the architecture of a model can favor certain patterns of output over others, reinforcing statistical tendencies rather than producing balanced results. As a developer, you can’t eliminate bias entirely. But you can recognize where it comes from, test for it, and design safeguards to minimize harm." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)  

"Deep learning, a subset of ML, employs layers of artificial neural networks to identify patterns in data. A key attribute of deep learning is its ability to enable models to automatically learn hierarchical features from raw data, rather than relying on manually engineered features from structured data. Prior to deep learning, defining relevant features such as edges, color histograms, or keywords was typically necessary to train a model to recognize objects or sentiment. In contrast, deep learning models autonomously learn these features during training by optimizing the parameters of each layer to minimize error on the task at hand." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Drift is the phenomenon in which an AI model becomes less accurate over time because of changes in the statistical properties of data in the real world versus the data the model was trained on. For example, a model trained on customer data with a specific age distribution might encounter a different age distribution in the future. This is known as data drift. AI models can also suffer from concept drift, in which the meaning of a term changes over time. Ongoing evaluations are essential for detecting drift, and both human and automated reviews can be used. Hybrid evaluation strategies encourage combining human judgment on output quality (tone, sensitivity, misinterpretations) with automated checks for syntactic correctness and speed." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Generative models are designed to be persuasive storytellers, not fact checkers. When you ask a model a question, it predicts what words are most likely to follow based on patterns in its training data. Sometimes those patterns reflect reality; other times they include errors or biases. The result is that large language models (LLMs) can produce highly plausible sentences that are utterly untrue. They may cite papers that don’t exist, invent statistics, or confidently answer questions they have no basis to answer. In the AI community, this phenomenon is often called a hallucination, but that term is both imprecise and potentially stigmatizing. Hallucinations refer to sensory experiences without external stimuli and should not be conflated with algorithmic errors. More accurate labels like fabrication, confabulation, and non sequitur highlight that the AI response doesn’t logically follow from its training data." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Hybrid integration combines a client-side model or significant frontend data processing with backend data processing. In practice, hybrid integration often blends the use of two or more different types of AI models. For example, blending the creativity of a generative model with the potential accuracy of reinforcement learning can lead to more trustworthy results than you might get from a generative model by itself. Other combinations of different types of models could include integrating neural networks with knowledge graphs or integrating symbolic AI with machine learning." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"In backend service integration, the application accesses an AI model or API through a server-side service. Using server-side resources to access the model improves the application’s security, simplifies monitoring and logging, and improves the scalability of the application. The trade-off is that it increases the complexity of the backend, and network round trips introduce latency into the application. Backend service integration is the right approach for applications that require access to a powerful AI model and that don’t require much client-side logic, such as search applications, chatbots, and data analysis." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Mixture of experts (MoE) architectures are neural networks that contain many different 'expert' submodels. Instead of using them all at once, the model chooses a few experts to handle each input. [...] A gating network in an MoE architecture handles routine tasks and decides which experts are activated for each prompt. Most MoE language models and their expert submodels are transformer-based. The most important benefit of MoE is that it can be made more capable by adding additional experts, rather than increasing the size of a single model. Because only a subset of experts is activated at a time, unnecessary computation is reduced." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"One of the most important aspects of designing with GenAI is determining when to let the machine act and when to keep a human in the loop. As LLMs and AI agents become increasingly capable of not just generating text but also performing actions (like calling APIs, filling out forms, and triggering workflows), designers and developers face a growing responsibility: deciding what should be automated, not just what can be. Although automation promises speed, efficiency, and scalability, over-automation can lead to unintended consequences and critical errors. This is especially true when actions taken by the AI affect financial, legal, or personal data. The goal of human-centered design isn’t to block AI progress. Instead, it should channel AI in ways that empower users while keeping them informed and in control." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Prompt engineering is the practice of crafting, optimizing, and managing prompts to guide large language models (LLMs) toward producing useful, specific, and high-quality outputs. It ranges from simple one-off instructions to structured templates and programmatic prompt management in production systems. [...] Prompt engineering is all about providing context to better align your question with the type of output you want the LLM to generate." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"RAG is a technique that combines the ability to make use of specialized domain knowledge with the techniques of prompt engineering. In a RAG application, documents that the application should have access to are split into chunks, such as overlapping blocks of text, and embedded as high-dimensional vectors. [...] A RAG application then stores the embeddings created from the documents along with metadata about each embedding, including a link to its source document and position in the document, in a vector database. When a user submits a prompt to an application with RAG capabilities, the application encodes the user’s query using the same embedding model used to encode the documents and finds the closest matches (aka nearest neighbors) between the user prompt and the chunks in the vector database. Finally, a new prompt is created that combines the retrieved snippets of text with a templated instruction. This new prompt is sent to the LLM for inference." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Self-attention is a mechanism where, for each token, the model looks at all other tokens in the input and computes weighted importance scores (attention weights) to decide how much each other token should contribute to its representation. Prior to self-attention, each token would be evaluated sequentially. This capability makes transformers especially good at handling long-range dependencies in text and is one of the reasons they have become the foundation for nearly all modern LLMs." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"Technical features are the design and training decisions that are made that determine aspects such as a model’s use-case suitability and performance metrics. By understanding the basics of these technical features, you can better evaluate, assess, and predict how models will perform. These technical features include architecture, parameter count, training data, fine-tuning and specialized tuning, context window, and unique functionalities." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026)

"The most common form of prompt hacking is prompt injection. This occurs when an attacker embeds malicious instructions inside a seemingly innocuous prompt to override the developer’s intended task. The root of the problem is architectural: current language models treat all text, including system prompts, developer instructions, and user input, as one continuous sequence. There is no built-in notion of 'trusted' versus 'untrusted' input, so a later instruction can supersede an earlier one. The simplest version is direct injection, where the attacker places the malicious directive directly in the user’s input. A classic example exploits the fact that models prioritize more recent or specific instructions [...] Indirect injection hides instructions in external content, such as a web page or document the model is asked to summarize, so the model executes code it wasn’t supposed to see. Specialized variants include code injection, where a code-generation assistant is tricked into outputting malicious commands, and recursive injection, where the output of one model carries an injection to the next in a chain. All of these attacks exploit the model’s inability to separate context from instruction." (Chris Minnick, "A Developer’s Guide to Integrating Generative AI into Applications", 2026) 

⚡️🗒️Power BI: CALCULATE [Notes]

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 31-Oct-2026

[DAX] CALCULATE

• {def} function that evaluates an expression in a modified filter context [4]
• filter arguments are used as the context for evaluating the expression CALCULATE belongs to
• filter arguments for CALCULATE replace all existing filters over the same columns [6]
• the new context effected by the filter argument for CALCULATE affects only existing filters on columns mentioned as part of the filter argument [6]
• filters on columns other than those mentioned in the arguments of CALCULATE remain in effect and unaltered [6]
• creates a filter context that includes a filter for every column of the iterated table
• when a DAX formula is executed, multiple levels of filter contexts are combined [2] 
• requires an active row context [2]
• either CALCULATE is executed or a measure is invoked [2]
• implies a context transition in these conditions [2]
• the row context is transformed into an equivalent filter context [2]
•  most of the time, the context transition happens because a measure is being invoked rather than because of an explicit CALCULATE [2]
• it allows developers to
• add, keep, remove or replace filters
• activate relationships
• perform context transition
• {concept} outer filter context
• the filter context that is active when CALCULATE is invoked[2
• {concept} inner filter context
• the new filter context created by CALCULATE and active only during the execution of its first argument [2]
• leverages the context transition leads to better code [2]
• propagates through relationships, moving from one table to another [2]
• {type} implicit CALCULATE [2]
• functions can conveniently hide CALCULATE or CALCULATETABLE functions from users but still invokes them [2]
• e.g. TOTALYTD
• performs a context transition by transforming any existing row contexts into an equivalent filter context
• the measure referenced is calculated within a filter context created by context transition [2]
• happens immediately before the measure starts being executed, as if CALCULATE automatically surrounds the measure [2]
• {type} explicit CALCULATE
• actively invokes context transition [2]
• {warning} a random CALCULATE added to the code forces the context transition [2]
• may lead to unexpected results  
• {recommendation} don't add CALCULATE unnecessarily [2]
• context transition can lead to situations in which the calculation works but all control over why it works is lost [2]
• {benefit} leverage metrics without changing the underlying data by modifying the filter context 
• allows to create alternative views of the same data model without creating new tables or columns
• measures become flexible and reusable 
• because calculations are performed dynamically at query time
• {benefit} add/remove filters to calculate measures independent of user selections
• KPIs/indicators can remain stable regardless of report slicers
• {benefit} simplify complex row-to-aggregation calculations enable context transition
• allows aggregation logic to operate correctly inside iterators and calculated columns
• reduces complex manual filtering logic
• {benefit} use relationships more effectively by activating inactive relationships
• a single model can support multiple business perspectives without duplicating tables
• {benefit} create dynamic business metrics 
• metrics respond intelligently to slicers, filters, drill-downs, and report interactions.
• {benefit} improve code readability
• measures become easier to understand, maintain, and troubleshoot
• using variables and explicit filter modifications makes business logic more transparent to future developers and analysts
• {benefit} simplify complex DAX
• functions like CALCULATE, variables, and context manipulation reduce nested expressions and repeated calculations
• this generally leads to shorter, more maintainable formulas. 
• {benefit} enable the creation of complex measures that can adapt to changes in filters
• allows one measure to support many analytical scenarios without requiring multiple versions
• measures automatically recalculate based on report context, allowing
• {syntax} CALCULATE(<expression>, <filter1>, <filter2>,...)
• {parameter} expression to compute
• only at the end does CALCULATE compute its first argument after creating the new filter context [2]
• {parameter} filters
• starting from the second argument, are defined the filters used to create/modify the filter context
• the filters are applied before the first argument can be computed
• therefore, they must be evaluated first [2]
• starts evaluating the 'filter' parameters in the order in which they were provided
• accepts any number of arguments as filters. They are all intersected, meaning that all the filters work together at once [2]
• when CALCULATE places a filter on a column that already had filters set by previous functions (or by the visual), the filter placed replaces the previous filter [2] 
• ⇐ behavior can be changed by using KEEPFILTERS
• the filter can be one of three types
• condition
• one or more values are specified for a set of columns [2]
• the conditions are tables
• it evaluates this table and restricts the data context to only the rows that match the rows present in that filter table [2]
• modifier
• instructs CALCULATE to perform an action (akabehave in a certain way) 
• via REMOVEFILTERS or USERELATIONSHIP
• table
• filter is applied to the columns present in the table with an IN condition
• placing a filter on one table automatically propagates its effect to any table with a relationship with the original table, following the cross-filter direction of the relationship [2]
• {warning} filter context can change unexpectedly
• CALCULATE modifies the existing filter context before evaluating an expression 
• {warning} context transition can produce surprising results
• when CALCULATE is used in a row context (calculated columns, iterators such as SUMX()), it automatically performs context transition
• {warning} overriding existing filters
• 
  
• {warning} performance degradation
• complex CALCULATE() measures may repeatedly recalculate filter contexts
• {warning} ambiguous logic from multiple filters
• the filter arguments can interact in ways that are not intuitive

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"

[4] Microsoft Learn (2026) DAX: CALCULATE [link] 

[5] Cooper Dunn (2025) Microsoft DP-600 Exam Practice Tests: 500 Questions for Implementing Analytics Solutions Using Microsoft Fabric

[6] https://learn.microsoft.com/en-us/dax/keepfilters-function-dax

 

⚡️🗒️Power BI: DAX Calculations [Notes]

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 28-Oct-2026

[feature] DAX Calculations

• {concept} calculated table 
• {def} table created by users using DAX [3]
• stored in the data model [3]
• materialized when the model is refreshed [3]
• becomes a regular table that can participate in relationships, filtering, and reporting [3]
•  unlike a visual calculation or a measure [3]
• enables adding new tables based on data loaded into the model [3]
• instead of querying and loading values into new table’s columns from a data source [3] 
• via a DAX formula that defines the table’s values [3]
• {characteristic} locked after loading
• after the table is loaded or refreshed, its results are locked in and cannot be changed until the table is refreshed [3]
• the results are pre-computed and aren’t dynamically determined [3]
• relatively easy to understand [3]
• because the DAX statement can be inspected and the results can be predicted [3]
• the same statement always returns the same result for the same parameters until the table is refreshed [3]
• {concept} calculated column
• {def} a column created using a DAX formula
• behaves like any other column in a table [3]
• it can be used to define relationships [3]
• {characteristic} calculated row by row 
• can be based on 
• simple formulas (e.g. mathematical operations like addition)
• complex formulas (e.g. combinations of functions) 
• {characteristic} stored in the data model
• ⇒ increases the size of the model [4]
• {characteristic} calculated during refresh 
• calculated when the table is first loaded or refreshed [3]
• can be used in rows, columns, filters, or values of a matrix or any other report [3]
• {exception}[DirectQuery|composite models] computed during the execution of a query [2]
• they do not use RAM, but they are also potentially slower [2]
• they are not evaluated and stored ahead of any query [2] 
• {characteristic}static
• its results cannot be changed until the table is refreshed again [3]
• {characteristic} can be resource-intensive
• especially for large datasets [4] 
• {recommendation} should be used judiciously [4]
• {characteristic} can be used in slicers and filters
•  help create categories users can interact with
• {characteristic) can be used for sorting 
• improves report usability
• {characteristic} support hierarchies and grouping
•  helps organize data into business-friendly groups.
• context transition applies as well [3]
• where a row context is present, and whenever a function is used that iterates over multiple values (aka iterators) [3]
• e.g. SUMX 
• always executed in a row context [2]
• it's possible to create a row context programmatically [2]
• {scenario} placing calculated results in a slicer [2]
• {poor practice} define calculated columns to compute formulas on a row-by-row basis and then aggregate the values [2]
• moving the computation time at data refresh can benefit the overall user experience [2]
• many such scenarios can be successfully solved using iterators instead of creating calculated columns [2]
• categorize text or numbers, especially for filter criteria [2]
• {concept} measure
• {def} a DAX calculation that is evaluated at query time based on the current filter context and returns a result based on the current filter context
• works on sets of rows, producing aggregates of values [2]
• requires aggregators [2]
• computed over multiple lines at once [2]
• does not compute its value on a row-by-row basis [2]
• work on aggregated data [2] 
• reusable
• can reference other measures 
• {characteristic} calculated only when needed
• its output is determined not only by its definition but also by the filter context in which it's executed [3]
•  the same definition can have a different meaning based on the filter context [3]
•  the same measure returns different results depending on
• slicers
• filters 
• visual selections
• row/column groups 
• {characteristic} depends on filter context
•  evaluated within that filter context and often summarizes multiple rows [3]
• {characteristic} consumes little storage/memory
•  only the formula definition, not the results 
• {characteristic} typically used in visuals
•  it can be used by other measures, visual-level/page-level/report-level filters
• used to filter what is displayed
•  it can be used for 
• conditional formatting
• dynamic titles
• dynamic tooltips 
• dynamic format strings
• calculations groups 
• visual calculations 
• {characteristic} must be defined in a table
• a dummy table can be defined for managing (all) measures
• can be moved in between tables
• ⇐ a table is merely a container where the measure is organized without affecting its behavior [2]
• {characteristic} cant be used in relationships
• {characteristic} can't be used direct in slicer fields 
• {type} explicit measure
• created explicitly via the UI 
• can be created programmatically
• via Tabular Editor, TMDL, TOM, XMLA Endpoint, Fabric/PBI, CI/CD
•  
• {type} implicit measure
• created (automatically) when a column is added in the values area of a visual [2]
• not always available
• they do not work when calculation groups are present in the model or when they are disabled in the Tabular model [2]
• {downside} do not guarantee full control over the calculation.
• {benefit} smaller semantic models and lower memory usage
•  store only the DAX formula and metadata, not a value for every row
• {benefit} one measures supports multiple scenarios
• automatically respond to slicers, filters, page/report filters, user selection 
• {benefit} best performance
• faster refreshes, smaller model size, better availability 
• {benefit} reusability 
•  less code duplication, easier maintenance, consistent business logic
• {benefit} support advanced analytics solutions
• time intelligence, running totals, ranking, comparisons, etc. 
• {benefit} centralize business logic
• SSoT/consistent logic across reports 
• {benefit} support modern Power BI features
• tooltips, conditional formatting, dynamic titles, visual calculations, calculations groups, KPIs, etc.
• {recommendation} always define an explicit measure instead of using implicit measures [2]
• allows to modify the global behavior of the calculation without breaking existing reports [2]
• {recommendation} consider creating measures instead of calculated models
• measures are preferred whenever a calculation can be express both ways [2]
• {recommendation} limit the use of calculated columns to the few cases where they are strictly needed [2]
• increase model size, increase refresh time, consume RAM 
• {recommendation} consider moving the calculation to the data preparation stage [2]
• data should be transformed as far upstream as possible and as far downstream as necessary [2]
• {recommendation} use DAX Studio early
•  it allows to inspect the query plan, view filter context, analyze storage engine vs formula engine activity, understand why one measure is faster than another, etc. [2]
• {recommendation} break complex measures into layers [2]
• allows to validate each step independently
• 
  

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"
[4] Cooper Dunn (2025) Microsoft DP-600 Exam Practice Tests: 500 Questions for Implementing Analytics Solutions Using Microsoft Fabric

Acronyms:
CI/CD - Continuous Integration/Continuous Development  
DAX - Data Analysis eXpressions
KPI - Key Performance Indicator
RAM - Random Access Memory
SSoT - Single Source of Truth
TMDL - Tabular Model Definition Language
TOM - Tabular Object Model
XMLA - XML for Analysis

 

⚡️🗒️Power BI: Context [Notes]

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 28-Oct-2026

[DAX] Context

• {def} the set of data that a calculation, visual, or DAX expression evaluates at a given moment
• determines which rows are considered when a calculation is evaluated
• the same measure can return different results depending on the context
• enables users to perform dynamic analysis [5]
• used by measures, calculated columns/tables, iterator functions, slicers & filters, relationships, time intelligence, RLS, etc.
• can make it difficult to troubleshoot formulas [5]
• {concept} evaluation context
• {def} the set of conditions and rules that determines which data is used when a DAX formula calculates a result
• both the row context and the filter context contribute to the evaluation context [3]
• the two are very different, serving different purposes, having different features and different behaviors [3]
• {type} filter context
• {def} the set of filters that are active when a calculation is evaluated
• determines which rows of data are visible to a measure at any given moment [2]
• added when a filter constraint is applied on the set of values allowed in a column or table, by using arguments to a formula [5]
• applies or removes filters to/from tables in the semantic model [2]
•  filters tables in a model [2]
•  propagates filters through relationships [2]
•  managed by CALCULATE [2]
• generated not only by the the current visual but also by other visuals [3]
• each visual has its filter context (aka visual filter context) 
• determined by all the other visuals in the report that interact with that current visual and all the report filters applied through the filters pane (visual-, page-, and report-level filters) [2]
• each cell has its filter context (aka cell filter context) 
• the coordinates of the cell itself determine the filter context of a cell, plus the visual filter context [2]
• sources
• visuals (charts, tables, cards, etc.)
• slicers
• report/page filters
• cross-filtering from other visuals
• DAX functions
• e.g. CALCULATE(), CALCULATETABLE()
• {type} row context 
• {def} the context in DAX where an expression is evaluated for a single row at a time, giving DAX access to the values of the current row
• aka 'the current row' 
• used when Power BI is evaluating one row at a time [1]
• needed to obtain the value of a column for a certain row [2]
•  {warning} trying to access the value of a column in a measure without an active row context results in an error [2]
• exists whenever we create a calculated column or whenever we are computing an expression inside an iteration [2]
• calculated columns have an automatic row context [2]
• the row context for a formula includes the values from all columns in the current row [
• automatically follows the relationships between tables to determine which rows in related tables are associated with the current row [5]
• functions that iterate calculations over a table can have multiple current rows and current row contexts [5]
•  can be created formulas that recurse over an inner and outer loop [5]
• certain functions store the row context from the operation that preceded the current operation [5]
• e.g. EARLIER 
• the function stores two sets of context in memory [5]
• one set of context represents the current row for the inner loop of the formula [5]
• another set of context represents the current row for the outer loop of the formula [5]
• measures don't have a row context [2] 
• if is needed to evaluate an expression row by row inside a measure, is needed to start an iteration to create a row context [2]
• when using iterators, the developer is responsible for creating and handling the row context [2]
• iterates over a table and evaluate its column values [2]
• ⇐ one row at a time
• row context is the result of iterating over rows
• row context equals iteration [2] is not exactly a correct statement
• means that DAX evaluates expressions one row at a time
• during the iteration, DAX creates a row context that gives the formula access to the values of the current row
• functions like SUMX and calculated columns rely on this behavior
• the two aren't identical 
• iteration refers to the process of moving through rows
•  row context is knowledge of the current row during that process
• DAX creates a row context for the current row
• functions like a cursor [2]
• during an iteration, it points to a specific row of the table being iterated, telling the DAX formula which row is currently to be considered [2]
• it does not filter [2][3]
• it simply indicates to DAX which row is currently responsible for providing the values to perform the calculation and where the result of the calculation should go [3]
• it's irrelevant whether a column in the table is used in a particular calculation [3]
• all columns of the table are part of the row context when a calculation is performed [3]
• encountered when (aka created via)
• calculated columns
• the formula defines a calculated column [2]
• iterators 
• perform active iteration over a table [2]
• e.g. SUMX, FILTER, ADDCOLUMNS, etc.
• scans the table row by row, and during the iteration, the row context points to the current row [2]
• the row context is needed to obtain the value of a column for a certain row [2]
• iterator functions create row context while moving through rows
• help create multiple nested row contexts [2] 
• increases the complexity of the code [2]
• can transform into filter context through a mechanism called context transition [3]
• defines the value of a column by providing the exact row [2]
• calculated columns are always executed in a row context [2]
• is not the case for measures [2]
• {limitation} doesn't propagate filters through relationships from one table to another [2]
• {recommendation} use RELATED and RELATEDTABLE to direct and move the row context from one table over to another [2]
• allows to leverage the existing model relationships and the VertiPaq storage engine, avoiding expensive manual lookups and row-by-row filtering operations
• {limitation} does not place any filter [2]
• {concept} context transition 
• occurs when a row context is converted into a filter context [1]
• takes any active row context and transforms it into a filter in the filter context [3]
• requires an active row context [2]
• either CALCULATE is executed or a measure is invoked [2]
• implies a context transition in these conditions [2]
• the row context is transformed into an equivalent filter context [2]
• usually the context transition happens because a measure is being invoked rather than because of an explicit CALCULATE [2]
•  leveraging the context transition leads to better code [2]
• without context transition DAX can only see the current row
• with context transition, DAX can use values from the current row to filter entire tables and compute aggregations
• the process is automatically execute by CALCULATE and CALCULATETABLE [2]
• any statement invoking either of these two functions performs a context transition [2]
• this happens regardless of whether [2]
• the functions functions were written explicitly [2]
• CALCULATE or CALCULATETABLE is used explictely [2]
• a function that conveniently hides CALCULATE or CALCULATETABLE functions from users but still invokes them [2]
• e.g. TOTALYTD
• this happens in calculated columns, whenever [2]
• a row context is present
• a function that iterates over multiple values is used (aka iterators)
• SUMX
• [measures] whenever a measure is invoked, the context transition happens immediately before the measure starts being executed, as if CALCULATE automatically surrounds the measure [2]
• {benefit} opens new ways to optimize the code [2]
• eliminates complex lookup logic
• reduces repeated filtering
• leverages relationships
• enables reusable measures
• improves performance with the storage engine
• pushes work toward the VertiPaq storage engine
• ⇐ highly optimized for aggregations
• {concept} visual calculation [>>]
• {def} DAX calculation that runs directly on a specific visual (table, matrix, chart, etc.) [3]
• {concept} visual calculation context
• context used by visual calculations, where calculations are performed after the visual has already been built
• uses the rows and columns that are visible in the visual itself rather than directly querying the underlying model
• allows users to calculate running totals, moving averages, differences, rankings, and other analyses directly within a visual 
• {recommendation} begin/experiment with simple formulas and relationships to see how context works [5]
• fastest ways to understand how evaluation context actually works
• helps to isolate context behavior 
•  many challenges are related to relationships
• {recommendation} learn filter context before row context
•  filter context appears in almost every advanced DAX solution later 
• {recommendation} predict before you run
• discoveries/knowledge results especially when the result differs from expectations
• {recommendation} use simple/small examples
• facilitates review and troubleshooting
• {recommendation} build a playground for learning 
• an experimentation model can prove valuable over time
• {recommendation} use DAX Studio early
•  it allows to inspect query plan, view filter context, analyze storage engine vs formula 
•  

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"

[4] Microsoft Learn (2026) Modify DAX filter context in semantic models [link]

[5] Microsoft Support (202?) Context in DAX Formulas [link]

 

Resources:  

[R1] Microsoft Fabric Community Row vs Filter Context: a Visual Guide [link] 

 

Acronyms:
DAX - Data Analysis eXpressions

RLS - Row Level Security

 

🏭🗒️Microsoft Fabric: Direct Lake [Notes] 🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 13-Oct-2026

[MF] Direct Lake

• {def} Power BI semantic model table storage mode option available in MF [1]
• optimized for large volumes of data to be quickly loaded into memory from Delta tables available in the OneLake [1] 
• leverages VertiPaq query engine [1]
• {benefit} deliver query performance comparable to Import mode 
• without the management overhead of data refresh cycles to load the entire data volume [1]
• similar to Import mode
• {difference}refreshes copies only metadata (aka framing)
•  [Import mode] replicates the data and creates an entire cached copy of the data for the semantic model [1]
•  depends on data preparation being done in the data lake [1]
• {benefit} enables high-performance interactive analysis [1]
•  ideal for semantic models connecting to large data sources
• e.g. lakehouse, warehouse and other data source with Delta tables [1]
• performance depends on well-tuned Delta tables [1]
•  {benefit} performance
• normally outperforms DirectQuery queries when loading and interacting with visuals in reports [1]
• {benefit}maximizes ROI because 
• analyzed data volumes can exceed capacity's max memory limits [1]
• only the needed data to answer a query is loaded into memory [1]  
• {benefit} minimizes data latencies 
•  makes new data available without refresh schedules [1]
• quickly and automatically synchronizing a semantic model with its sources [1]
• {operation} refresh 
• low-cost operation that analyzes the metadata of the latest version of the Delta tables and updates references to the latest files in OneLake
• DL moves data preparation to OneLake
• ⇐ uses the full breadth of Fabric technologies for data prep
• incl. Spark jobs, T-SQL DML statements, dataflows, pipelines, etc.
• {operation} transcoding
• the process of loading data from OneLake only when a query requests a column for the first time 
• {action} the semantic model receives a DAX (or MDX) query 
• {step} determines what columns are needed to produce the result
• {step} determines which columns are already resident in memory [2]
• {step} loads the missing columns from OneLake [2]
•  typically a fast operation, however it can depend on factors 
•  e.g. the cardinality of data stored in the columns
•  remains resident until there's reason for it to be removed (evicted) from memory
• {reason} the model or table was refreshed after a Delta table update at the source [2]
• {reason} no query used the column for some time [2]
• {reason} other memory management reasons [2]
•  e.g. memory pressure in the capacity due to other, concurrent operations [2]
•  SKU determines the maximum available memory for each Direct Lake semantic model on the capacity [2]
• {operation} framing 
• an operation triggered by a refresh of a semantic model [2]
• it usually takes only a few seconds to complete
• ⇐ because it's a low-cost operation where the semantic model analyzes the metadata of the latest version of the Delta Lake tables and updates to reference the latest Parquet files in OneLake [2]
• the process might evict resident table column segments and dictionaries from memory if the underlying data changed [2]
• the point in time of the refresh becomes the new baseline for all future transcoding events [2]
• DL queries only consider data in the Delta tables as of the time of the most recent framing operation [2]
• DL tables are queried to return data based on the state of the Delta table at the point of the most recent successful framing operation [2]
• that time isn't necessarily the latest state of the Delta tables [2]
• the semantic model analyzes the Delta log of each Delta table during framing to drop only the affected column segments and to reload newly added data during transcoding [2]
• {optimization} dictionaries usually aren't dropped when incremental framing takes effect, and new values are added to the existing dictionaries [2]
• helps reduce the reload burden and benefits query performance [2]
• when a Delta table receives no updates, no reload is necessary for columns already resident in memory [2]
•  queries show far less performance impact after framing because incremental framing essentially enables the semantic model to update substantial portions of the existing in-memory data in place [2]
• can fail if a Delta table exceeds the Fabric capacity guardrails [2]
•  e.g. when a Delta table has more than 10,000 parquet files [2]
•  {architecture} Direct Lake on OneLake
•  isn't coupled with the SQL analytics endpoint [2]
•  offers tighter integration with OneLake features such as OneLake security [2]
•  offers more efficient DAX query plans because [2]
• ⇐ isn’t required to check for SQL based security [2]
•  fallback isn't supported [2]
• {architecture} Direct Lake on SQL analytics endpoint
•  a DAX query might use DirectQuery fallback [2]
•  involves seamlessly switching to DirectQuery mode [2]
•  DirectQuery fallback
• retrieves data directly from the SQL analytics endpoint of the lakehouse or the warehouse [2]
•  fallback occurs when SQL based security is detected in the SQL analytics endpoints
•  a DirectQuery operation sends a query to the SQL analytics endpoint. Fallback operations might result in slower query performance [2]
•  {setting} Keep your Direct Lake data up to date
• performs automatic updates of Direct Lake tables [2]
• via semantic model settings >> Refresh 
• {enabled|default} ensures that data changes in OneLake are automatically reflected in the Direct Lake semantic model [2]
•  the semantic model performs a framing operation whenever data modifications in the underlying Delta tables are detected [2]
• {recommendation} leave the setting on, especially when you have a small or medium-sized semantic model
• useful in case of low-latency reporting requirements and Delta tables are modified regularly [2]
•  {disabled} it might be needed to disable automatic updates to allow completion of data preparation jobs or an ETL process before exposing any new data to consumers of the semantic model [2]
•  users can trigger a refresh manually in the Fabric portal [2]
•  via refresh schedule, or programmatically by using the Power BI REST API or TOM [2]
• 
  

References: 
[1] Microsoft Learn (2026) Direct Lake overview [link]
[2] Microsoft Learn (2026) 

Acronyms:
API - Application Programming Interface
DL - Direct Lake 
MDX - Multidimensional Expressions
MF - Microsoft Fabric
REST
SKU - Stock Keeping Unit
TOM - Tabular Object Model
T-SQL - Transact SQL

 

⚡️🗒️Power BI: ALLSELECTED in DAX [Notes]

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 13-Oct-2026

[DAX] ALLSELECTED()

• {def} function that returns all the rows in a table, or all the values in a column [1]
• ignores any filters that might have been applied inside the query [1]
•  removes the corresponding filters from the filter context, restoring the last shadow filter context
• keeps filters that come from outside [1] 
• gets the context that represents all rows and columns in the query, while keeping explicit filters and contexts other than row and column filters 
• does not materialize the resulting table when called directly in a filter argument of CALCULATE or CALCULATETABLE 
• via ALLSELECTED([<tableName> | <columnName>[, <columnName>[, <columnName>[,…]]
• {parameter|optional} tableName
• the name of an existing table 
• cannot be an expression
• {parameter|optional} columnName
• the name of an existing column using standard DAX syntax, usually fully qualified
• cannot be an expression 
• if there is one argument, the argument is either tableName or columnName [1]
• if there is more than one argument, they must be columns from the same table [1] 
• {scenario} used to obtain visual totals in queries [1] 
• {scenario} used as a table expression when it has at least one argument [2] 
• {scenario} used without arguments only as a CALCULATE or CALCULATETABLE modifier [2]  
• {distinction} different from ALL() because 
• it retains all filters explicitly set within the query [1] 
• it retains all context filters other than row and column filters [1] 
• {limitation}[DirectQuery mode] not supported when used in calculated columns or RLS rules [1] 
• only DAX function that leverages shadow filter contexts [3] 
• has a slightly different behavior when
• used in SUMMARIZECOLUMNS 
• mostly produces the expected result [3] 
• removes filters for the currently-iterated group-by column, restoring the original filter set by SUMMARIZECOLUMNS itself [3] 
• SUMMARIZECOLUMNS  can be used in nearly all the visuals [3] 
• inside an iterator
• {warning} can produce weird results [3] 
• does not return the values of a column (or table) filtered outside a visual [3] 
• displays different behaviors, depending on whether it is used in SUMMARIZECOLUMNS or not, and on the presence of shadow filter contexts [3]
• {best practice} don’t create a measure that uses ALLSELECTED within an iteration [3]
•  it can produce unexpected results, poor performance, and difficult-to-understand calculations.
• {best practice} minimize the use of measures that contain ALLSELECTED [3]
• can be safely used only in measures that are directly placed in the reports [3] 
•  

Previous Post <<||>> Next Post

References: 
[1] Microsoft Learn (2026) DAX: ALLSELECTED [link]
[2] DAX Guide (2026) ALLSELECTED DAX Function (Filter) SQL[link]
[3] SQLBI (2026) ALLSELECTED Best Practices [link]

💎🏭SQL Reloaded: QUALIFY in Microsoft Fabric (Before/After) 🆕

One recent addition to T-SQL is the QUALIFY clause, which filters rows returned by a query based on a search condition that can reference window (analytic) functions [1]. The QUALIFY clause allows filtering directly in the block in which the window function is defined. According to the documentation QUALIFY can be used directly after HAVING clause:

SELECT select_list
FROM   table_source
[ WHERE <search_condition> ]
[ GROUP BY group_by_specification ]
[ HAVING <search_condition> ]
[ QUALIFY <filter_condition> ]
[ ORDER BY <order_by_expression> [ , ...n ] ]
[ FOR JSON <options> ]

So, for example, if we consider a fictitious Sales Invoices table, to retrieve the customers who bought a product more than once, we had to apply the constraint outside the block in which the window function was defined:

-- product bought more than once by same customer (before)
SELECT *
FROM (-- calculating resultset
	SELECT customer_id
	, product_id
	, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
	FROM [Sales].[sales_invoices]
) DAT
WHERE total_quantity>1

Now, a constraint can be applied directly in the block with the window function via QUALIFY followed by one or more constraints:

-- product bought more than once by same customer (after) 
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY SUM(quantity) OVER(PARTITION BY invoice_id, product_id)>1

Given the order in which the constraints are processed, QUALIFY allows to reduce redundancy by referencing a new column defined in the SELECT statement (update 19-Oct-2026):

-- product bought more than once by same customer (after) 
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY total_quantity>1

Hopefully this is available on all supported platforms. Otherwise, the logic must be repeated if a second constraint is needed for checking whether the value is within a boundary. Upon case, the logic can become even more complex (e.g. multiple intervals are checked):

-- product bought more than once by same customer (after) 
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY SUM(quantity) OVER(PARTITION BY invoice_id, product_id)>1

  AND SUM(quantity) OVER(PARTITION BY invoice_id, product_id)<10

Imagine how complex can become a query like the following (update 19-Oct-2026):

-- product bought more than once by same customer with interval testing
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY (total_quantity>1 AND total_quantity)<10)

    OR (total_quantity>21 AND total_quantity)<30)

    OR (total_quantity>41 AND total_quantity)<50)

    OR (total_quantity>61 AND total_quantity)<70)  

Notes:
1) Having fewer blocks of code improves in theory code's readability and hopefully maintainability when the code doesn't need to be replicated as in the last example. This approach should improve also performance, however further tests are needed to validate this. 
2) It's useful to include the same logic used in QUALIFY also in the main SELECT statement, at least for troubleshooting purposes. 
3) The syntax seems to be supported only in Fabric warehouse, respectively SQL Endpoints for warehouse, lakehouse and SQL database.4) QUALIFY clause requires at least one window function in the SELECT list, ORDER BY list or QUALIFY expression (see Msg 8826, Level 16).
4) QUALIFY clause requires at least one window function in the SELECT list, ORDER BY list or QUALIFY expression (see Msg 8826, Level 16). (update 19-Oct-2026)
5) One should check also whether the syntax is supported by all the features. For example, it's not supported by UPDATE and DELETE statements in warehouse. The restrictions for SQL Endpoints should be considered as well.
6) Developers must consider also portability of code when it's the case.
7) According to Copilot, QUALIFY is supported in Teradata (originator of the feature), Snowflake, Google BigQuery, Amazon Redshift, Databricks SQL, DuckDB and ClickHouse. (update 19-Oct-2026)
8) Of course, the window functions can be mixed to address different business questions, though it's maybe a good idea to move the DENSE_RANK in SELECT and reference the new column within QUALIFY (update 19-Oct-2026):

-- first/last customer by product incl. total
SELECT product_id
, SUM(quantity) OVER(PARTITION BY product_id) quantity_total
, FIRST_VALUE(customer_id) OVER(PARTITION BY product_id ORDER BY invoice_date ASC) first_status
, LAST_VALUE(customer_id) OVER(PARTITION BY product_id ORDER BY invoice_date DESC) last_status
FROM [LH_CRM_Data].ERP.[sales_invoices_partitioned4]
QUALIFY DENSE_RANK() OVER(PARTITION BY product_id ORDER BY invoice_date)=1

 9) QUALIFY can be used also in combination with a CROSS/OUTER APPLY. For example, to retrieve the latest invoice details one could write a query like the one below (update 02-Nov-2026):

-- OUTER APPLY + QUALIFY
SELECT top 10 CST.CustomerID
, CST.CompanyName
, DAT.*
FROM [SalesLT].[Customer] CST
   OUTER APPLY (
   SELECT SalesOrderID
   , [ShipDate]
   , ROW_NUMBER() OVER (PARTITION BY SOH.CustomerID ORDER BY ShipDate) Ranking
   FROM [SalesLT].[SalesOrderHeader] SOH
   WHERE CST.CustomerID = SOH.CustomerID
   QUALIFY Ranking = 1
   ) DAT
--WHERE DAT.SalesOrderID IS NOT NULL -- testing
ORDER BY CST.CompanyName

It can be surprising that it works (at least I was positively surprised).
Instead of OUTER APPLY one could use a LEFT JOIN (the two versions return the same results):

-- LEFT JOIN + QUALIFY
SELECT top 10 CST.CustomerID
, CST.CompanyName
, DAT.*
FROM [SalesLT].[Customer] CST
   LEFT JOIN (
   SELECT SalesOrderID
   , CustomerID
   , [ShipDate]
   , ROW_NUMBER() OVER (PARTITION BY SOH.CustomerID ORDER BY ShipDate) Ranking
   FROM [SalesLT].[SalesOrderHeader] SOH
   QUALIFY Ranking = 1
   ) DAT
   ON CST.CustomerID = DAT.CustomerID
--WHERE DAT.SalesOrderID IS NOT NULL -- testing
ORDER BY CST.CompanyName

Happy coding!

References:
[1] Microsoft Learn (2026) SELECT - QUALIFY clause (Transact-SQL) [link]