How to Count Employees by Department and Filter with HAVING in SQL?

Use GROUP BY and HAVING to find departments with more than 5 employees

Aggregating data by group is one of the most common things you'll do in SQL, and the question "which departments have more than 5 employees?" is a favorite in interviews and real-world reporting alike. It looks simple, but it's the perfect place to learn the difference between WHERE and HAVING. In this post, we'll build the query, explain how it works, and cover the details that often cause mistakes.

The problem

You have an employees table with a department_id column. You want to count the employees in each department and return only the departments that have more than 5 employees.

The solution

SELECT department_id, COUNT(*) AS employee_count
FROM employees
GROUP BY department_id
HAVING COUNT(*) > 5;

How it works

1. GROUP BY department_id places all employees of the same department into one group.
2. COUNT(*) counts the rows in each group, giving the headcount per department.
3. HAVING COUNT(*) > 5 keeps only the groups whose count is greater than 5.

Why HAVING and not WHERE?

This is the key idea. WHERE filters individual rows before grouping happens, so it has no access to aggregate results like COUNT(*). HAVING filters groups after aggregation, which is exactly what we need to filter on a count.

A handy way to remember the order of execution: FROM and WHERE first, then GROUP BY, then HAVING, and finally SELECT and ORDER BY.

Things to watch for

Strictly greater than

The condition > 5 excludes departments with exactly 5 employees. If you want "5 or more," use >= 5. Read the requirement carefully, because this off-by-one detail is a common trap.

NULL departments

Employees whose department_id is NULL are grouped together as their own group. If you don't want that group in your results, filter them out first.

SELECT department_id, COUNT(*) AS employee_count
FROM employees
WHERE department_id IS NOT NULL
GROUP BY department_id
HAVING COUNT(*) > 5;

COUNT(*) versus COUNT(column)

COUNT(*) counts every row in the group, while COUNT(column) skips rows where that column is NULL. For a headcount, COUNT(*) is the right choice unless you have a specific reason to ignore missing values.

Empty departments never appear

A department with zero employees has no rows to group, so it will not show up in the results. That is fine here, since zero is never greater than 5, but keep it in mind if you later need a report that lists every department.

Showing department names

In most databases, department names live in a separate departments table. Join it before grouping to get readable output.

SELECT d.name AS department, COUNT(*) AS employee_count
FROM employees e
JOIN departments d ON e.department_id = d.id
GROUP BY d.id, d.name
HAVING COUNT(*) > 5
ORDER BY employee_count DESC;

What changed?

• The join brings in the department name for display.
• Grouping by both d.id and d.name prevents two different departments with the same name from being merged into one group. Many databases also require every non-aggregated selected column to appear in the GROUP BY.
• ORDER BY employee_count DESC is optional, but it lists the largest departments first, which makes the report easier to scan.

Which version should you use?

Goal	Best approach
Quick answer using IDs	The basic GROUP BY with HAVING query
Readable report with department names	Join to the departments table, then group
Ignore employees without a department	Add WHERE department_id IS NOT NULL

For interviews, start with the basic query, then mention the join and NULL handling to show that you think about real data.

Final thoughts

The pattern GROUP BY ... HAVING COUNT(*) > N is one of the most reusable tools in SQL. It answers questions like "which customers placed more than 3 orders?" or "which products have more than 10 reviews?" with only a change of table and column names. Remember that WHERE filters rows, HAVING filters groups, and you'll avoid one of the most common SQL mistakes.

How to Find Duplicate Records in a SQL Table?

Use GROUP BY and HAVING to detect duplicates, then inspect and clean them up safely

Duplicate rows are one of the most common data quality problems. They creep in through repeated imports, missing constraints, or application bugs, and they quietly distort reports, inflate counts, and break joins. Finding them is also a classic SQL interview question. In this post, we'll look at the simplest way to detect duplicates, the pitfalls to watch for, and a few variations for inspecting and cleaning them up.

The core query

Suppose you have an employees table and want to know which names appear more than once.

SELECT name, COUNT(*)
FROM employees
GROUP BY name
HAVING COUNT(*) > 1;

This returns each name that appears more than once, along with how many times it appears.

How it works

1. GROUP BY name collapses all rows with the same name into a single group.
2. COUNT(*) counts how many rows each group contains.
3. HAVING COUNT(*) > 1 keeps only the groups with more than one row.

Why HAVING and not WHERE?

WHERE filters individual rows before grouping happens, so it cannot see the result of COUNT(*). HAVING filters groups after aggregation, which is exactly what we need here.

Pitfalls to watch for

What counts as a duplicate?

Two employees can share a name without being duplicate records. Before you act on the results, decide which columns define uniqueness. For true duplicates, group by every column that should be unique, such as name and email.

NULL values group together

If several rows have a NULL name, they will show up as a single duplicate group. Decide whether that is meaningful for your data or whether you should exclude them with WHERE name IS NOT NULL.

Case and whitespace matter

In most databases, "Asha" and "asha " are different values, so near-duplicates slip through. Normalize the column first, for example with LOWER(TRIM(name)), to catch them.

Make the output readable

Give the count an alias, such as COUNT(*) AS duplicate_count, so the result is easier to read and sort.

Variation 1: Duplicates across multiple columns

When a single column isn't enough, group by several.

SELECT name, email, COUNT(*) AS duplicate_count
FROM employees
GROUP BY name, email
HAVING COUNT(*) > 1;

Only rows that match on both name and email are reported, which is a much stronger signal of a true duplicate.

Variation 2: See the full duplicate rows

The grouped query shows counts, but often you want to look at the actual rows. Join the results back to the table.

SELECT e.*
FROM employees e
JOIN (
  SELECT name
  FROM employees
  GROUP BY name
  HAVING COUNT(*) > 1
) d ON e.name = d.name;

Now you can compare IDs, dates, and other columns to decide which record to keep.

Variation 3: Flag the extra copies with ROW_NUMBER

A window function can number the rows within each group of duplicates, so every copy after the first stands out.

SELECT *
FROM (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY name ORDER BY id) AS rn
  FROM employees
) t
WHERE rn > 1;

Here, PARTITION BY name restarts the numbering for each name, and ORDER BY id keeps the earliest record as number 1. Any row with rn > 1 is an extra copy. This pattern is especially useful when you want to delete all but one record.

Which approach should you choose?

Goal	Best approach
Detect which values are duplicated	GROUP BY with HAVING
Inspect the full duplicate rows	Join back to the grouped subquery
Remove all but one copy	ROW_NUMBER with PARTITION BY

A word of caution before deleting

Never delete duplicates blindly. Run the SELECT version first and review exactly which rows would be affected. If possible, take a backup or work inside a transaction so you can roll back. Once the data is clean, prevent the problem from returning by adding a UNIQUE constraint or a unique index on the columns that should never repeat.

Final thoughts

The GROUP BY ... HAVING COUNT(*) > 1 pattern is the simplest and most portable way to find duplicates, and it works on virtually every SQL database. Start there to detect the problem, switch to a join when you need to inspect the rows, and use ROW_NUMBER when it's time to clean up. Combine that with a unique constraint, and you'll keep your tables tidy for the long run.

How to Find the Second Highest Salary in SQL (3 Ways)

A classic interview question, explained with a simple query, a LIMIT/OFFSET version, and a window function

"Find the second highest salary from the Employee table" is one of the most common SQL interview questions, and it also appears as LeetCode problem 176. It looks easy, but it hides a few tricky edge cases: duplicate salaries, tables with only one row, and what to return when there simply is no second value. In this post, we'll walk through three solid approaches and when to use each.

The problem

Given an employees table with a salary column, return the second highest distinct salary. If there is no second highest salary, return NULL.

id	name	salary
1	Asha	100
2	Ravi	200
3	Meera	300

The expected answer here is 200.

Approach 1: The nested MAX query

This is the simplest approach and works on virtually every SQL database.

SELECT MAX(salary) AS SecondHighestSalary
FROM employees
WHERE salary < (
  SELECT MAX(salary)
  FROM employees
);

How it works

1. The inner query, SELECT MAX(salary) FROM employees, finds the highest salary.
2. The outer query takes the maximum of all salaries that are strictly lower than that value, which is exactly the second highest.

Why it handles the edge cases

• Duplicate top salaries: if two people share the highest salary, the condition salary < MAX(salary) excludes both, so you still get the next distinct value. That is what "second highest" normally means.
• No second salary: if all salaries are identical, or the table has just one row, the outer query finds no rows to aggregate, and MAX returns NULL. That matches the problem's requirement without any extra code.

One practical note: make sure the table name matches your schema. LeetCode calls it Employee, while many tutorials use employees.

Approach 2: LIMIT and OFFSET

If you prefer to think in terms of sorting, you can order salaries from highest to lowest and skip the first one.

SELECT (
  SELECT DISTINCT salary
  FROM employees
  ORDER BY salary DESC
  LIMIT 1 OFFSET 1
) AS SecondHighestSalary;

How it works

• DISTINCT removes duplicate salaries so each value counts once.
• ORDER BY salary DESC puts the highest first.
• LIMIT 1 OFFSET 1 skips the top row and returns the next one.

Why the outer SELECT?

Without the wrapper, a table with no second salary would return an empty result instead of NULL. Wrapping the query as a scalar subquery turns "no rows" into NULL, which is usually what you want.

This syntax works in MySQL and PostgreSQL. Other databases use different keywords, such as TOP in SQL Server or FETCH FIRST in Oracle.

Approach 3: A window function with DENSE_RANK

Window functions give you the most flexible solution.

SELECT MAX(salary) AS SecondHighestSalary
FROM (
  SELECT salary,
         DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
  FROM employees
) t
WHERE rnk = 2;

How it works

DENSE_RANK() assigns a rank to each salary from highest to lowest, and tied salaries share the same rank without leaving gaps. The highest salary gets rank 1, the next distinct salary gets rank 2, and so on. Filtering for rnk = 2 picks out the second highest, and wrapping it in MAX ensures you get NULL when no such rank exists.

Why use it?

This approach scales effortlessly. To find the 3rd or Nth highest salary, you only change the number in WHERE rnk = N. It is also easy to extend to per-department rankings by adding PARTITION BY department.

Which approach should you choose?

Approach	Best for	Portability
Nested MAX	Quick, simple second-highest queries	Works everywhere
LIMIT / OFFSET	Readable, sort-based thinking	MySQL, PostgreSQL
DENSE_RANK	Nth highest, or ranking within groups	Modern databases with window functions

For a straightforward "second highest" question, the nested MAX query is hard to beat. If the interviewer follows up with "now find the Nth highest" or "do it per department," reach for DENSE_RANK.

Common mistakes to avoid

• Using ROW_NUMBER instead of DENSE_RANK: ROW_NUMBER gives tied salaries different numbers, so duplicates at the top would give the wrong answer.
• Forgetting DISTINCT with OFFSET: without it, a duplicated top salary would be returned as the "second" value.
• Not handling the no-result case: always confirm the query returns NULL, not an empty set, when there is no second value.

Final thoughts

The second highest salary problem is a great reminder that simple-looking SQL questions often test your attention to edge cases. Start with the nested MAX query for its clarity, learn the LIMIT/OFFSET version for sort-based thinking, and keep DENSE_RANK in your toolkit for anything more general. Master these three patterns, and a whole family of ranking questions becomes much easier.

Inside ChatGPT: What Happens After You Hit Enter?

A step-by-step look at the journey of a single message, from keystroke to streaming reply

You type a question, press Enter, and within a second words begin to appear on screen. It feels instant and effortless. But in that fraction of a second, your message travels through a surprisingly elaborate pipeline of software and hardware.

One caveat before we begin: the exact internals of ChatGPT are proprietary, so this post describes how chat assistants built on large language models (LLMs) generally work. The broad strokes are shared across the industry, and they're enough to demystify what's going on.

Step 1: Your message goes to a server

When you hit Enter, the app sends your text over the internet to the provider's servers. There, it passes through the usual web infrastructure: authentication, rate limiting, and routing to a machine that has capacity to run the model. The model itself is far too large to run on your phone or laptop, so it lives in data centers on specialized chips called GPUs or other AI accelerators.

Step 2: Your prompt is assembled

The model doesn't see just the sentence you typed. The system builds a larger prompt that typically includes:

• Instructions from the provider, which shape the assistant's tone, behavior, and boundaries.
• The conversation so far, since the model has no memory between requests and must be re-shown the earlier messages each time.
• Extras such as saved preferences or tool results, where the product supports them.
• Your new message, placed at the end.

This whole bundle is the model's entire view of the world for this one response. That's why very long chats can eventually hit the context window, the maximum amount of text the model can consider at once.

Step 3: Text becomes tokens

The assembled prompt is split into tokens, small chunks such as whole words, word fragments, or punctuation. "Unbelievable" might become "un," "believ," and "able." Each token is mapped to a number, and each number is then converted into an embedding, a long list of values that captures the token's meaning. From this point on, the model works entirely with numbers.

Step 4: The forward pass through the transformer

Now the heavy lifting begins. The embeddings flow through dozens of stacked transformer layers. In each layer, an attention mechanism lets every token look at every other token and weigh which ones matter for interpreting it. In the sentence "The trophy didn't fit in the suitcase because it was too big," attention helps connect "it" to "trophy."

This step involves billions of multiplications performed in parallel across GPUs, which is why the hardware matters so much. Because the model's knowledge is stored in its billions of weights, every one of them participates in the calculation.

Step 5: The model predicts one token

At the end of the forward pass, the model produces a probability for every token in its vocabulary. Maybe "The" gets 12 percent, "Sure" gets 9 percent, and "A" gets 6 percent, with thousands of others sharing the rest.

The system then samples from these probabilities rather than always taking the top choice. Settings such as temperature control how adventurous that choice is: lower values make output more predictable, higher values make it more varied. This controlled randomness is why asking the same question twice can produce different answers.

Step 6: Repeat, and stream

The chosen token is appended to the text, and the whole process runs again to pick the next token, and the next, until the model emits a special end-of-response signal or hits a length limit. Engineering tricks, such as caching the work already done for earlier tokens, keep this loop fast.

As each token is produced, it's sent straight back to your screen. That's why the reply seems to be typed out live. It really is being generated one piece at a time, and streaming it makes the wait feel much shorter.

Step 7: Safeguards and tools along the way

Around this core loop, products typically add extra layers. Safety systems may check inputs and outputs for harmful content. If the assistant can use tools such as web search, code execution, or file analysis, the model may pause its text, request a tool call, receive the result, and then continue writing with that new information in hand.

What this means for you

Understanding the pipeline explains several everyday quirks:

• Why long chats can drift or forget early details: the context window is finite, and everything must fit inside it.
• Why answers vary between tries: sampling introduces randomness.
• Why the model can be confidently wrong: it generates plausible next tokens, not verified facts.
• Why clear prompts help: your words are the main steering signal the model gets.

The big picture

After you hit Enter, your message is wrapped in context, converted to numbers, pushed through a giant neural network, and turned back into words one token at a time. There's no hidden mind consulting an encyclopedia, just an extraordinarily well-trained pattern predictor running at remarkable speed.

The next time a reply streams onto your screen, you'll know a lot is happening behind that blinking cursor.

What Is a Large Language Model, and How Does It Work?

If you've chatted with Claude, ChatGPT, Gemini, or Llama, you've used a Large Language Model (LLM). These systems write code, draft emails, summarize reports, and translate languages, and they can feel almost magical. But under the hood, the core idea is surprisingly simple. In this post, we'll break down what an LLM is, how it works, and where it falls short.

So, what is an LLM?

A Large Language Model is an AI system trained on enormous amounts of text to understand and generate human language. At its core, it does one thing: given some text, it predicts what text should come next.

That sounds almost too simple. But when you do it at massive scale, with billions of adjustable parameters and trillions of words of training data, the result is a system that can answer questions, reason through problems, and write in nearly any style.

How an LLM works, step by step

1. Tokenization: chopping text into pieces

Models don't read words the way we do. Text is first split into small chunks called tokens, which can be whole words, word fragments, or punctuation. For example, "unbelievable" might become "un," "believ," and "able." Each token is then mapped to a number the model can process.

2. Embeddings: turning words into meaning

Each token is converted into a long list of numbers called a vector, which captures something about its meaning. Words with similar meanings end up with similar vectors. This lets the model work with meaning mathematically: "king" and "queen" land near each other, while "king" and "sandwich" do not.

3. The transformer and the power of attention

Nearly all modern LLMs are built on the transformer architecture, introduced in 2017. Its breakthrough idea is attention, a mechanism that lets every token look at every other token in the input and decide which ones matter most.

Consider this sentence: "The trophy didn't fit in the suitcase because it was too big." What does "it" refer to? Attention helps the model link "it" to "trophy" rather than "suitcase." Dozens of stacked transformer layers refine this understanding step by step, building richer and richer representations of the text.

4. Predicting the next token, again and again

Finally, the model outputs a probability for every possible next token. It picks one (with a controlled amount of randomness), adds it to the text, and repeats. That loop, one token at a time, is how a full response gets generated.

How an LLM learns

Pretraining

During pretraining, the model reads trillions of tokens from books, websites, code, and more. For each passage, it tries to predict the next token, compares its guess with the real answer, and nudges its internal weights (billions of numerical parameters) to do slightly better next time. Repeated over countless examples, this process teaches the model grammar, facts, reasoning patterns, and writing styles.

Fine-tuning and alignment

A raw pretrained model simply continues text; it isn't naturally a helpful assistant. To get there, it is further trained on example conversations and refined using human feedback, such as reinforcement learning from human feedback (RLHF). This teaches the model to follow instructions, be helpful, and avoid harmful outputs.

What LLMs are good at

• Flexibility: One model can handle writing, coding, analysis, translation, and more.
• Fluent language: They produce natural, coherent text across many styles and tones.
• Generalization: They can tackle new problems from just a description or a few examples.

Where LLMs fall short

• Hallucinations: LLMs can state false things with total confidence, so important claims are worth verifying.
• Knowledge cutoffs: A model's knowledge stops at its training cutoff unless it's given tools such as web search.
• Different kind of understanding: LLMs learn patterns from text rather than from direct experience of the world, so they don't understand things the way humans do.

A helpful mental model

Think of an LLM as a system that has compressed patterns from a huge portion of written human knowledge into its weights. When you give it a prompt, it draws on those patterns to generate the most plausible continuation. With enough scale and training, "plausible continuation" turns out to cover a surprising amount of useful intelligence.

Final thoughts

LLMs aren't magic, and they aren't mind-readers. They're prediction engines built on a clever architecture and trained on vast amounts of text. Understanding the basics (tokens, embeddings, attention, and next-token prediction) makes it easier to use them well: to write better prompts, spot their mistakes, and appreciate what they can and can't do.

As techniques like retrieval and tool use continue to extend what these models can do, the best way to understand LLMs is to keep experimenting with them.

Want to dig deeper? Future posts could explore attention in detail, how training works, or how tools and retrieval make LLMs more capable.

LLM Fundamentals Interview Questions Part1

1. What Are Foundation Models?

A foundation model is a large AI model trained on broad and diverse datasets that can be adapted to perform multiple tasks.

Instead of being designed for a single purpose, a foundation model learns general patterns and representations from data. Developers can then use or adapt it for specific applications.

Foundation models may be trained to work with different types of data, including:

• Text and natural language

• Source code

• Images

• Audio and speech

• Video and other multimodal inputs

Examples of Foundation Models

Some well-known examples include:

• GPT: A family of models used for language understanding, content generation, reasoning, and coding.

• Claude: AI models used for writing, analysis, and software development.

• Gemini: Models designed for language, reasoning, and multimodal tasks.

• Llama: A family of open-weight language models that developers can adapt and deploy under the applicable license.

• Stable Diffusion: A family of generative models used for image creation.

These models provide reusable capabilities that can support many different applications.

2. How Do Foundation Models Work?

Foundation models generally involve several stages, from training to application development.

Step 1: Data Collection and Preparation

Models are trained on large datasets containing relevant information, such as text, code, images, or other data.

The quality, diversity, and suitability of training data influence the capabilities and limitations of the resulting model.

Step 2: Model Training

During training, the model learns patterns and relationships in the data.

For example, a language model learns statistical relationships between tokens and can use those relationships to generate text.

Training large foundation models can require substantial computing resources, specialized hardware, and extensive engineering expertise.

Step 3: Model Adaptation

Once a foundation model is available, developers can adapt it to their needs using techniques such as:

• Prompt engineering: Providing carefully designed instructions and context.

• Fine-tuning: Further training a model on selected examples for a particular task or behavior.

• Retrieval-Augmented Generation (RAG): Supplying relevant external information to the model at inference time.

• Tool calling: Allowing the model to request actions from approved tools or external systems.

Step 4: Application Development

Developers integrate the model into applications such as chatbots, business assistants, search systems, coding tools, and AI agents.

The final application typically combines the model with application logic, data sources, security controls, and evaluation mechanisms.

3. Foundation Models vs. Traditional AI Development

Before foundation models became widely available, many AI projects relied on specialized models built for individual tasks.

For example, a team might develop one model for text classification, another for sentiment analysis, and another for document processing.

Foundation models offer a more reusable starting point.

Traditional AI development	Foundation-model-based development
Often requires task-specific model development	Starts with a pretrained general-purpose model
May require substantial labeled data	Can often begin with prompting and limited examples
Usually targets a narrower task	Can support multiple tasks
Focuses heavily on model training	Emphasizes integration, adaptation, and evaluation
Requires task-specific maintenance	Requires model and application lifecycle management

Foundation models do not eliminate the need for traditional machine learning. Specialized models can still be more appropriate when accuracy, cost, speed, or predictable behavior are critical.

4. How Have Foundation Models Changed AI Engineering?

Foundation models have changed both the technical architecture of AI applications and the responsibilities of AI engineers.

4.1 Faster Application Development

Developers can use existing models through APIs or deploy suitable models in their own infrastructure.

This reduces the need to train large models from scratch and allows teams to focus on solving business problems.

4.2 New Application Architectures

Modern AI applications often combine a foundation model with external data, business logic, and tools.

For example, an enterprise assistant might use an LLM to understand a question, a retrieval system to find relevant documents, and an application service to enforce access permissions.

This approach enables more useful applications than relying on a model's pretrained knowledge alone.

4.3 Greater Importance of Evaluation

A working AI demonstration is not necessarily a reliable production system.

AI engineers must evaluate:

• Answer accuracy and relevance

• Hallucination rates

• Response consistency

• Latency and throughput

• Token usage and operating costs

• Safety and security

Evaluation must continue after deployment because model behavior, data sources, and user requirements can change.

4.4 Multimodal Applications

Modern foundation models increasingly support multiple types of input and output.

Applications can use these capabilities for tasks such as interpreting images, transcribing speech, answering questions about documents, and creating conversational voice assistants.

This allows developers to create richer user experiences without building every capability independently.

4.5 New Security and Operational Challenges

Foundation models also introduce new engineering challenges, including:

• Prompt injection and malicious input

• Protection of confidential data

• Unintended or incorrect outputs

• Model versioning and monitoring

• Inference latency and cost management

• Bias and responsible AI practices

Consequently, production AI engineering requires more than selecting a capable model. It requires a secure, observable, and well-tested system.

5. Practical Example: Building an AI Company Policy Assistant

Consider an organization that wants an AI assistant capable of answering employee questions about company policies.

Employees might ask questions such as:

• How many annual leave days do I receive?

• What is the work-from-home policy?

• How do I submit an expense reimbursement request?

Traditional Approach

A team might build a specialized question-answering system using task-specific data, rules, or models. Updating the system as policies change could require additional development and maintenance.

Foundation Model Approach

The team can start with an existing language model and combine it with Retrieval-Augmented Generation (RAG).

A typical workflow looks like this:

1. Store approved company policies in a document repository.

2. Split documents into searchable sections.

3. Convert sections into embeddings and index them in a vector database or another retrieval system.

4. Retrieve relevant sections when an employee asks a question.

5. Provide the question and retrieved information to the language model.

6. Generate an answer grounded in the retrieved documents.

7. Display appropriate source references so the employee can verify the answer.

Example architecture:

Employee Question → Application API → Document Retrieval → Foundation Model → Answer with Sources

This design can make company information easier to access while reducing the need to train a custom language model.

However, RAG does not guarantee correct answers. Engineers must validate retrieval quality, enforce document-level permissions, test for hallucinations, and monitor the system in production.

6. Important Technologies in Foundation-Model Engineering

AI engineers commonly work with several complementary techniques.

Large Language Models (LLMs)

LLMs are language-focused foundation models designed to process and generate natural language. Many can also work with code and structured information.

Retrieval-Augmented Generation (RAG)

RAG combines information retrieval with generation. It helps applications provide models with relevant external information, including information that may not have been part of their training data.

Fine-Tuning

Fine-tuning adapts a pretrained model through additional training. It can improve performance on particular tasks, formats, or behaviors when suitable data and evaluation methods are available.

AI Agents and Tool Calling

Agentic systems use models to select steps or request actions through tools. Depending on their design, they may retrieve information, call APIs, or complete multi-step workflows.

These systems need controlled permissions, validation, and limits on what actions they can take.

7. Challenges and Limitations of Foundation Models

Despite their capabilities, foundation models have important limitations.

Hallucinations: Models can generate plausible but incorrect information.

Cost: Model inference can become expensive at high usage volumes, especially for large models and long prompts.

Latency: Complex requests and large inputs may increase response times.

Privacy: Sensitive information must be handled according to the application's security and data-governance requirements.

Bias: Training data and model behavior can introduce unwanted biases.

Dependence on providers: Hosted models can involve pricing changes, rate limits, availability constraints, and version changes.

AI engineers should select models based on measured performance, business requirements, and operational constraints rather than assuming that the largest model is always the best choice.

8. The Future of AI Engineering

Foundation models are encouraging a shift from building individual predictive models toward engineering complete AI-powered systems.

Future AI engineering work will increasingly involve:

• Designing reliable RAG pipelines

• Building and evaluating AI agents

• Integrating AI with existing business applications

• Developing multimodal user experiences

• Improving model efficiency and inference costs

• Implementing AI security and governance

• Monitoring quality throughout the model lifecycle

The most successful AI systems will combine model capabilities with reliable data, sound software engineering, clear evaluation criteria, and appropriate human oversight.

How to install Azure Service Fabric in local machine.

In this Post, I will guide you how to install Azure Service Fabric in your local Machine.

First download Service Fabric run time from below link.

https://download.microsoft.com/download/b/8/a/b8a2fb98-0ec1-41e5-be98-9d8b5abf7856/MicrosoftServiceFabric.9.1.1583.9590.exe

Then download Service fabric SDK from below link.

https://download.microsoft.com/download/b/8/a/b8a2fb98-0ec1-41e5-be98-9d8b5abf7856/MicrosoftServiceFabricSDK.6.1.1583.msi

Now Install each above downloaded file as below.

1. Service Fabric Runtime

     Open  CMD in administrative mode and paste the command as below

     C:\Users\sony\Downloads>MicrosoftServiceFabric.9.1.1583.9590.exe /accepteula

2. Service Fabric SDK

Click on Service Fabric SDK msi package and Install it.

Once Installed, go to

C:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup folder and open DevClusterSetup.ps1 file in Power Shell(Open PS in admin mode) and execute this file. 

Or paste below code in Power Shell 

& "$ENV:ProgramFiles\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1"

Once DevClusterSetup.ps1 file execute successfully, it will create service fabric cluster in your local machine.

Service Fabric Cluster:-

What is the difference between round and ceiling in SQL Server?

In SQL Server, both the ROUND and CEILING functions are used to perform mathematical rounding of numerical values, but they have different behaviors:

1. ROUND:

   • The ROUND function is used to round a numeric value to a specified number of decimal places.
   • It performs "normal" rounding, which means that if the decimal part is equal to or greater than 0.5, it rounds up; otherwise, it rounds down.
   • It can be used with both positive and negative numbers.
   • The ROUND function takes two arguments: the numeric value to be rounded and the number of decimal places to round to.

   Example:

   
   SELECT ROUND(3.14159, 2); -- Returns 3.14 

2. SELECT ROUND(3.6); -- Returns 4 
3. SELECT ROUND(-3.6); -- Returns -4

4. CEILING:

   • The CEILING function is used to round a numeric value up to the nearest integer that is greater than or equal to the original value.
   • It always rounds up, regardless of the decimal part of the number.
   • It is commonly used when you want to ensure that a value is rounded up to the nearest whole number, even if the decimal part is very small.
   • The CEILING function takes a single argument, which is the numeric value to be rounded up.

   Example:

   SELECT CEILING(3.14159); -- Returns 4
   SELECT CEILING(3.6); -- Returns 4
   SELECT CEILING(-3.6); -- Returns -3

In summary, the key difference between ROUND and CEILING in SQL Server is in how they handle rounding. ROUND performs standard rounding based on the decimal part of the number, while CEILING always rounds up to the next integer, regardless of the decimal part. Your choice between them depends on the specific rounding behavior you need for your calculations.

How to implement Azure Application Insight in Web app?

Azure Application Insights is a powerful service for monitoring and gaining insights into the performance and usage of your web applications. To implement Application Insights in a web app, follow these steps:

Step 1: Create an Application Insights resource

Log in to the Azure portal (https://portal.azure.com).

Click on "+ Create a resource" on the left-hand menu.

Search for "Application Insights" in the Azure Marketplace.

Select "Application Insights" from the search results.

Click the "Create" button to create a new Application Insights resource.

Fill in the required details like Subscription, Resource Group, Region, and give it a name. You can also configure the pricing tier based on your needs. Click "Review + create" and then "Create" to provision the resource.

Step 2: Instrument your Web App

Now that you have an Application Insights resource, you need to instrument your web app to send telemetry data to it. This involves adding the Application Insights SDK to your application code. The exact steps may vary depending on the technology stack of your web app.

Below are some common scenarios:

ASP.NET Core Application (C#):

Open your ASP.NET Core project in Visual Studio.

Install the Microsoft.ApplicationInsights.AspNetCore NuGet package if not already installed:

Install-Package Microsoft.ApplicationInsights.AspNetCore

In the Startup.cs file, add the following code in the ConfigureServices method to configure Application Insights:

services.AddApplicationInsightsTelemetry(Configuration["ApplicationInsights:InstrumentationKey"]);

In the appsettings.json file, add your Application Insights Instrumentation Key:

"ApplicationInsights": {

  "InstrumentationKey": "YOUR_INSTRUMENTATION_KEY"

}

Node.js Application:

Install the applicationinsights npm package:

npm install applicationinsights --save

In your Node.js code, require and configure Application Insights using your Instrumentation Key:

const appInsights = require("applicationinsights");

appInsights.setup("YOUR_INSTRUMENTATION_KEY").start();

Other Platforms: Application Insights has SDKs and integrations for various platforms. You can find specific instructions for your technology stack in the official documentation.

Step 3: Verify Integration

After instrumenting your web app, you can verify if telemetry data is being sent to Application Insights:

Run your web app.

In the Azure portal, navigate to your Application Insights resource.

Go to the "Overview" or "Logs" section to see telemetry data, including requests, exceptions, and performance metrics.

Step 4: Analyze and Monitor

With Application Insights set up, you can use it to:

• Monitor application performance and detect issues.
• Create custom dashboards and alerts.
• Analyze user behavior and track conversions.
• Debug and diagnose problems using distributed tracing.

Application Insights is a powerful tool for gaining insights into your web app's behaviour and performance, helping you improve its reliability and user experience.