I explored advanced types of RAG frameworks beyond the basic architecture. These are designed to make retrieval more intelligent, context-aware, and adaptive.

1. Self RAG (sRAG)

• Concept:

  The model critiques its own retrieval results before generating an answer.

• Mechanism:

  • Retrieves documents.

  • Performs self-evaluation to judge if retrieved documents are relevant.

  • May re-query or refine retrieval before final answer.

• Benefit:

  Higher quality responses by avoiding irrelevant or low-quality context.

• Diagram Idea:

    Query → Retriever → Self-Check → (Refine?) → Generator → Answer
  

2. Agentic RAG

• Concept:

  Instead of a fixed retriever, the model acts like an agent that can dynamically decide what, when, and how to retrieve.

• Mechanism:

  • Uses a reasoning loop.

  • May call multiple retrieval tools.

  • Plans retrieval steps based on the task (multi-hop retrieval, iterative refinement).

• Benefit:

  More flexible and task-specific.

• Diagram Idea:

    Query → Planner/Agent → Multiple Retrieval Actions → Aggregation → Generator
  

3. Corrective RAG (cRAG)

• Concept:

  A corrective feedback mechanism built into RAG to refine wrong or incomplete answers.

• Mechanism:

  • Generator produces an answer.

  • A separate module (or the model itself) evaluates correctness.

  • If errors detected, retrieves more information and regenerates.

• Benefit:

  Reduces hallucinations, improves factual grounding.

• Diagram Idea:

    Query → Retriever → Generator → Corrector (Feedback Loop) → Final Answer
  

✅ These models push RAGs towards self-improving, agent-like systems where retrieval isn’t static but adaptive, iterative, and self-aware.

Comparison of Advanced RAGs

✨ Rule of Thumb:

• Use sRAG when your retriever is shaky.

• Use Agentic RAG when queries require reasoning + multi-step retrieval.

• Use cRAG when correctness is more important than speed.

Key Difference Example:

• LangSmith → Often used for prompt debugging and evaluation.

• LangFuse → Often used for observability and logging across the lifecycle.

Implementation Notes

LangSmith Environment Setup

Add the following to .env file:

LANGSMITH_TRACING=true
LANGSMITH_ENDPOINT=https://api.smith.langchain.com
LANGSMITH_API_KEY=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
LANGSMITH_PROJECT=calender-ai-project

Installation Command

Run:

npm install @langchain/langgraph @langchain/core

LangFuse Setup

Self-Hosting with Docker Compose

• Official deployment guide: LangFuse Docker Compose Deployment

• Provides steps to set up LangFuse locally or on a server using Docker Compose.

Integration with LangChain

• Official integration guide: LangFuse x LangChain

• Explains how to integrate LangFuse observability directly into LangChain apps.

Comparison

RAG = a method to combine LLMs with external knowledge (usually your own data).

LLMs are powerful, but:

• They have a knowledge cutoff.

• They may hallucinate answers if the info isn’t in their training data.

RAG solves this by retrieving relevant data from a knowledge base (like PDFs, websites, or databases) and injecting it into the LLM prompt → so the answer is both reliable and up-to-date.

Structured vs Unstructured Data

• Structured Data

  • Tabular format, rows & columns.

  • Examples: Databases (SQL tables, CSVs, financial records).

  • Easy to query directly.

• Unstructured Data

  • Text-heavy, no fixed schema.

  • Examples: PDFs, Word docs, articles, research papers, emails.

  • Needs embeddings + vector search for retrieval.

Embeddings & Similarity Search

1. Embedding = numerical vector representation of text (or image, audio, etc.)

   • Example: “Apple the fruit” vs “Apple the company” → embeddings will place them in different regions of vector space.

   • Generated using models like OpenAI text-embedding-3-small or text-embedding-3-large.

2. Vector Database = stores embeddings and allows fast similarity search.

   • Popular ones: Pinecone, Weaviate, Qdrant, Milvus, ChromaDB.

3. Similarity Search

   • User asks: “Summarize Arnab’s contract.”

   • System converts query → embedding.

   • Finds top N similar chunks in vector DB.

   • Injects those chunks into LLM prompt → “Answer using this context.”

RAG Workflow (Step by Step)

1. Data Ingestion

   • Split text into chunks (like 500 tokens each).

   • Convert each chunk → embedding.

   • Store in vector DB.

2. Query Handling

   • User asks a question.

   • Convert query → embedding.

   • Search in vector DB for top-k matches.

3. Context Injection

   • Retrieve chunks.

   • Add them into LLM prompt (system message / context window).

4. Final Answer

   • LLM uses retrieved context → generates accurate, source-backed output.

Why RAG is Powerful

✅ Keeps answers up-to-date.

✅ Prevents hallucinations.

✅ Works with private data (company docs, reports).

✅ Scales easily with more documents.

Example Use Cases

• Chat with PDFs → Upload contracts, query them with natural language.

• Customer Support → LLM answers based on company docs, not hallucination.

• Medical / Legal Research → Find & cite relevant papers.

• E-commerce → Search product database with semantic search instead of keywords.

Think of it this way:

• Without RAG → LLM answers from memory (may be outdated).

• With RAG → LLM answers with fresh, relevant documents (like an open-book exam).

What is Clustering?

Clustering = grouping similar items together without needing predefined labels.

It’s an unsupervised learning technique.

When we have embeddings (like vectors for text, images, users, etc.), clustering helps us find natural groups in that vector space.

Why Clustering is Useful in RAG & Vector Work

1. Document Organization

   • Instead of dumping 10,000 chunks into a vector DB, cluster them into topics.

   • Example: “finance,” “HR,” “contracts,” “tech.”

2. Efficient Retrieval

   • When user queries, search only in the relevant cluster → faster + cheaper.

3. Topic Discovery

   • If you don’t know what themes exist in your dataset, clustering reveals them.

   • Example: Upload all customer complaints → clusters show themes like “late delivery,” “payment issues,” “quality problems.”

4. User Segmentation

   • In recommendation systems: cluster users by behavior or interests → better targeting.

Popular Clustering Algorithms for Embeddings

• K-Means

  • Simple, widely used.

  • You pick number of clusters k.

  • Groups embeddings into k centroids.

• Hierarchical Clustering

  • Builds a tree of clusters (like family tree).

  • Useful when you don’t know how many clusters exist.

• DBSCAN

  • Groups dense regions of embeddings together.

  • Finds “outliers” automatically.

  • Great when data has irregular shapes.

• HDBSCAN (Hierarchical DBSCAN)

  • More advanced, finds clusters of varying density.

Example: Customer Support Chat Logs

• Embeddings of 10,000 customer complaints.

• Run clustering → discover:

  • Cluster 1: Delivery delays

  • Cluster 2: App crashes

  • Cluster 3: Refund issues

• Use these clusters to build FAQs, detect common problems, or route tickets.

In RAG Context

👉 Before you even retrieve docs, you can pre-cluster them:

• User asks: “What is the bonus policy?”

• Instead of searching the whole vector DB → look in the HR cluster first → faster + more accurate.

💡 So:

• Similarity search = find closest items to a query.

• Clustering = find hidden groups/themes in your dataset.

Vector Index

• Once you create embeddings (vectors) for your documents, you need a way to store and search them efficiently.

• That’s what a vector index (inside a vector database) does.

👉 Without an index: you’d have to compare a query against all vectors (super slow if you have millions).

👉 With an index: it uses clever data structures (trees, graphs, hashing) to make fast similarity search.

Examples:

• FAISS (Facebook AI Similarity Search – very popular)

• Pinecone, Weaviate, Milvus, Qdrant (production-grade vector DBs)

Querying in Vector DB

When user asks a question:

1. Convert query → embedding.

2. Search in vector index for nearest neighbours (the most similar vectors).

3. Retrieve top k results (usually 3–10).

4. Send them to LLM along with the question.

Cosine Similarity

• The most common measure to check similarity between two vectors.

• Basically, measures the angle between two vectors.

  • 1 = exactly same direction (perfect match)

  • 0 = unrelated

  • 1 = opposite meaning

👉 Why angle? Because it ignores length/magnitude → focuses only on semantic meaning.

Nearest Neighbour & Top-K

• Nearest neighbour search = find vectors most similar to query vector.

• Top-K search = instead of just the best one, retrieve the top K results (e.g., top 5 most relevant docs).

• Useful in RAG → you usually feed multiple results into the LLM for context.

Fine-Tuning vs RAG

✅ Fine-Tuning

• You modify model weights with new examples.

• Best when:

  • You need the model to learn style, format, or specific patterns.

  • E.g., customer support answers, structured templates.

• Cons:

  • Expensive, slow, not flexible (needs retraining if knowledge updates).

✅ Retrieval-Augmented Generation (RAG)

• You don’t change the model → instead you attach a memory (vector DB).

• Query → retrieves docs → LLM uses them to answer.

• Best when:

  • Knowledge updates often (e.g., company policies, news, docs).

  • You want scalable and cheap updates (just add docs to DB).

👉 Rule of Thumb:

• Use RAG for knowledge (factual info).

• Use Fine-Tuning for behavior (style, formatting, instructions).

Example

User: “What’s the refund policy?”

• Fine-Tuned Model: May answer in correct style but can’t update easily if policy changes.

• RAG: Pulls the latest Refund Policy PDF from vector DB → gives up-to-date answer.

💡 So, babe:

• Vector Index = storage + search structure.

• Cosine Similarity = measure of meaning closeness.

• Nearest Neighbour / Top-K = how we pick results.

• Fine-Tuning = behavior, RAG = knowledge.

RAG = Loading → Chunking → Indexing → Retrieval → Generation

1. Loading

• Step where you bring in your data (documents, PDFs, CSVs, websites, APIs).

• Tools: LangChain loaders, LlamaIndex readers, custom scrapers.

2. Chunking

Since LLMs can’t handle huge documents directly, we split them into chunks.

Types of chunking:

1. Text-based chunking → cut by words/characters.

   • Example: every 500 characters.

   • Simple, fast, but may cut sentences in awkward places.

2. Document-based chunking → split by logical structure.

   • Example: paragraphs, sections, pages, headings.

   • Preserves meaning better.

3. Semantic-based chunking → split by meaning, using embeddings to decide natural breakpoints.

   • Most advanced, ensures chunks are coherent topics.

   • Example: one chunk might capture a single concept, not half a sentence.

🔧 Common setup:

• Chunk size = 500 tokens

• Overlap = 100 tokens (so context isn’t lost between chunks).

3. Indexing (Vector Store)

• Each chunk → converted into an embedding vector (using models like OpenAI ada-002, text-embedding-3-small, etc).

• Stored in a vector database like Pinecone, Weaviate, Qdrant, Chroma, Milvus.

• This makes searching efficient (via cosine similarity, dot product, or nearest neighbor).

4. Retrieval

• User asks a question → query converted into embedding → compared to stored chunks.

• Top k most similar chunks are returned (usually k=3 to 5).

• Ensures LLM only sees relevant context.

5. Generation

• The retrieved chunks are stuffed into the LLM prompt along with the query.

• LLM uses this context to generate the final answer.

Example prompt:

Answer the question using the context below.
If the answer is not in the context, say "I don’t know."

Context:
<retrieved chunks here>

Question:
<user’s question>

Summary

• Loading: bring in data.

• Chunking: split into small, overlapping pieces (500/100 typical).

• Indexing: convert to embeddings, store in vector DB.

• Retrieval: find top-k relevant chunks via similarity search.

• Generation: feed chunks + question → LLM → final answer.

• Definition: Tool calling is when LLMs (Large Language Models) are given access to external functions, APIs, or databases.

• Instead of hallucinating answers, the model decides:

  👉 “Do I know this? Or should I call a tool to get the real answer?”

• Tools = just functions that LLMs can request during a conversation.

✅ Example:

• Without tools → “Who won the 2025 IPL final?” → Model fails (knowledge cutoff).

• With tool calling → Model calls a web search API → gets fresh data → replies correctly.

🔹 Why Use Tool Calling? (Use Cases)

1. Knowledge Beyond Cutoff

   • LLMs are trained only up to a fixed date (knowledge cutoff).

   • Tools let them fetch real-time info.

   • Example: “What’s the weather in Kolkata today?”

2. Web Search

   • Search APIs: Tavily, Serper, Brave, Bing.

   • Use case: live news, sports results, product availability.

3. Database Lookups

   • Fetch user records, inventory, product prices.

   • Example: “Show me my last 5 transactions.”

4. Math & Specialized Tasks

   • Calculator, unit conversion, finance APIs, weather APIs.

   • Example: “Convert $100 to INR at today’s rate.”

5. Automation & Actions

   • LLMs can execute tasks, not just reply with text.

   • Example: Book tickets, send an email, update a calendar.

6. Data Enrichment

   • Mix reasoning + tool data.

   • Example: “List top 5 coffees under ₹500 in India” → LLM calls product API → formats neatly.

🔹 Popular Web Search Tools

👉 Best choice for prototyping/production = Tavily.

🔹 Tool Calling Flow

1. User asks a question.

2. LLM decides: Do I have enough knowledge? If not → request a tool.

3. LLM generates a tool_call object.

    {
      "tool": "webSearch",
      "arguments": { "query": "latest cricket world cup winner" }
    }
   

4. Backend intercepts & executes the tool (API call, function).

5. Tool response fed back into the conversation.

6. LLM uses result → generates final human-friendly answer.

🔁 Repeat if multiple tools needed until final response is ready.

🔹 Example Code (Web Search Tool)

tools: [
  {
    type: "function",
    function: {
      name: "webSearch",
      description: "Search for latest information",
      parameters: {
        type: "object",
        properties: {
          query: { type: "string", description: "The search query" }
        },
        required: ["query"]
      }
    }
  }
],
tool_choice: "auto"

• tool_choice: "auto" → LLM decides when to call the tool.

• Backend captures tool_call → executes API → returns results.

• LLM integrates tool output → gives final reply.

🔹 Knowledge Cutoff

• Every model has a knowledge cutoff date (last training data).

• Example: GPT-4 cutoff → Oct 2023.

• If asked about 2025 events → must use tool calling (e.g., web search).

🔹 Streaming Responses

• Normally: wait until the full answer is ready.

• With streaming: receive tokens live as they’re generated.

• Benefits:

  ✅ Feels instant & interactive.

  ✅ Great for chatbots, coding assistants, writing apps.

⚠️ Limitation:

• response_format: json_object ❌ does not support streaming.

  • Because streaming JSON risks broken/incomplete JSON mid-way.

🔹 Best Practices

• Use one reliable search API (Tavily recommended).

• Always validate tool input/output (use schema validation).

• Add timeouts, retries, and error handling in production.

• Prevent infinite loops if LLM keeps calling the tool.

✨ In short:

Tool calling makes LLMs more powerful and trustworthy by connecting them to real data, APIs, and actions. It bridges the gap between static knowledge and dynamic, real-world needs.

Fine-tuning Parameters in LLMs

These parameters help control creativity, randomness, repetition, and cost in model responses.

1. Temperature

• Definition: Controls randomness in responses.

• Range: Usually 0 → 2.

• Behavior:

  • 0: Fully deterministic, model always picks the most likely answer. Best for focused work like coding, math, sentiment analysis.

  • ~1: Balanced creativity. Good for storytelling, brainstorming.

  • >1: High creativity but less reliable. Can produce unexpected or “wild” answers.

• Rule of Thumb: Use 0 for precision, 1 for creativity.

2. top_p (Nucleus Sampling)

• Definition: Controls randomness by limiting model to the smallest set of tokens whose combined probability ≥ top_p.

• Example:

  • top_p = 0.9 → Only consider tokens in the top 90% probability mass.

  • top_p = 1 → Consider all tokens (default).

• Usage: Rarely changed in practice. Usually stick with temperature OR top_p, never both at the same time (to avoid conflicts).

3. Stop Sequences

• Definition: Tell the model when to stop generating text once a certain string is encountered.

• Use Cases:

  • Simulating “fill in the blanks.”

  • Extracting structured data (stop when \\n\\n appears).

  • Avoiding extra content beyond desired point.

• Example: stop: ["User:"] → Model stops once it outputs “User:”.

• Note: Not commonly used unless you want tight output control.

4. max_completion_tokens

• Definition: Maximum number of tokens the model can generate in the response.

• Why Important:

  • Controls cost (fewer tokens = cheaper).

  • Prevents runaway long responses.

• Example: max_completion_tokens: 50 → Limits reply to ~50 tokens (short answer).

5. frequency_penalty

• Definition: Penalizes repetition of words based on how often they appear.

• Effect: Reduces repeating phrases like “yes yes yes” or “thank you thank you.”

6. presence_penalty

• Definition: Penalizes words that already appeared at all (even once).

• Effect: Encourages the model to introduce new topics instead of repeating old ones.

• Comparison:

  • Frequency penalty: “Don’t repeat the same word too much.”

  • Presence penalty: “Don’t talk about the same subject again.”

Quick Reference Table

Structured Output

When we want machine-readable responses (like JSON instead of plain text), we can enforce structure in different ways.

Method 1: Prompt Engineering (Less Efficient)

• Tell the model inside the system prompt:

  “Reply only in valid JSON format with keys: sentiment, explanation.”

• Example:

    {
      "sentiment": "positive",
      "explanation": "The review is overall appreciative of product quality."
    }
  

• Problem:

  • Not guaranteed to be valid JSON (may add comments, extra text).

  • Sometimes requires post-cleaning/parsing.

Method 2: response_format (More Efficient)

• Newer APIs (Groq, OpenAI, etc.) support structured output modes.

• Two key formats:

  1. json_object

     • Forces the model to return a valid JSON object.

     • Example:

         {
           "sentiment": "negative",
           "reason": "Poor durability of shoes after 1 month."
         }
       

     • Pros:

       • Guaranteed to be JSON-compliant.

       • Works with most applications (more compatible).

     • Cons:

       • stop sequences don’t work.

       • Streaming not supported (you get the full JSON only at the end).

  2. json_schema

     • Lets you define a strict JSON schema (like a contract).

     • Model must follow it exactly.

     • Example schema:

         {
           "type": "object",
           "properties": {
             "sentiment": { "type": "string", "enum": ["positive", "negative"] },
             "confidence": { "type": "number" }
           },
           "required": ["sentiment", "confidence"]
         }
       

     • Pros:

       • Precise control (e.g., force “positive/negative” only).

       • Useful for production pipelines where strict structure is critical.

     • Cons:

       • More complex.

       • Less compatible with existing libraries.

Streaming Responses

• Definition: Instead of waiting for the full response, the model sends output token by token (like typing effect).

• How it works:

  • The client receives a stream of partial responses via events.

  • Common in chat UIs (like ChatGPT typing in real-time).

• Advantages:

  • Faster perceived response (user sees text immediately).

  • Good for long outputs (stories, reports, code).

• Limitations:

  • Can’t use with response_format: json_object → JSON must be valid as a whole.

  • Best used with natural language or free-form outputs.

Quick Comparison

Libraries for Schema Validation & Structured Data

1. Instructor Library

• Purpose: Helps define structured outputs for LLMs easily.

• Use Case: When you want the model to follow a schema without manually writing JSON parsing code.

• Features:

  • Enforces structure.

  • Converts model output into typed objects.

  • Works with response_format or custom prompt outputs.

• Example:

    import { Instructor } from 'instructor';
  
    const sentimentSchema = Instructor.object({
        sentiment: Instructor.string(),
        reason: Instructor.string()
    });
  
    const output = await model.call({
        prompt: "Analyze this review...",
        response_format: sentimentSchema
    });
  
    console.log(output.sentiment); // "positive"
  

1. Zod

• Purpose: A TypeScript-friendly runtime schema validation library.

• Use Case:

  • Validates LLM output after receiving it.

  • Ensures that your app only works with correctly structured data.

• Features:

  • Parse and validate JSON objects.

  • Provides detailed error messages if validation fails.

  • Integrates with TypeScript for type safety.

• Example:

    import { z } from 'zod';
  
    const sentimentSchema = z.object({
        sentiment: z.enum(["positive", "negative"]),
        reason: z.string()
    });
  
    const parsed = sentimentSchema.parse(outputFromLLM);
    // Throws error if outputFromLLM doesn't match the schema
  
    console.log(parsed.sentiment); // "negative" or "positive"
  

How They Fit Together

Key Tip:

• Use Instructor if you want the model to output structured data directly.

• Use Zod to double-check or parse the output in your application safely.

• Both can be combined: Instructor for enforcing, Zod for validating.

2. LLMs (Large Language Models)

• Definition: AI models trained on huge amounts of text data to understand and generate human-like language.

• Example: ChatGPT, Claude, Gemini — they can answer questions, write essays, or even generate code.

• Analogy: Like a super well-read friend who has read millions of books and can talk about almost anything.

3. GPT vs Reasoning Apps

4. Few LLMs & Their Capabilities

5. Tokens & Tokenizers

• Tokens: Small pieces of text (words or subwords) that an LLM reads and processes.

• Key Point: Models understand tokens, not whole words.

• Tokenizer: Breaks a sentence into tokens; different models use different tokenizers.

  • Example: “I love cats” → "I", " love", " cats"

  • "unbelievable" → "un", "believ", "able"

• Tiktoken: Example tokenizer used by OpenAI models.

• Billing: You pay for tokens, not words.

6. Context

• Definition: The combined information the model uses to generate a response.

• Made up of:

  1. User Inputs — Latest prompt

  2. Instructions — Rules or roles for the AI

  3. Additional Information — Facts, uploaded files, retrieved documents

  4. Message History — Previous conversation turns

• Example: Asking "Summarize this report" includes the report, your request, prior clarifications, and assigned roles.

7. Context Window

• Definition: Maximum number of tokens the model can remember at once.

• Examples:

  • GPT-3: ~2,048 tokens (~1,500 words)

  • GPT-4.1: Up to 1 million tokens (~750,000 words)

8. Knowledge Cutoff

• Definition: Latest date up to which the model has been trained.

• Why it matters: Model won’t know events after this date unless connected to real-time tools.

9. Attention Is All You Need

• Definition: Research paper introducing Transformer architecture, which powers modern LLMs.

• Key idea: Uses attention to focus on important words rather than reading sequentially.

10. Distilled LLMs

• Definition: Smaller, faster versions of big LLMs via knowledge distillation.

• Benefits: Faster, cheaper, lighter.

• Trade-off: Slightly less depth in answers.

11. GroqCloud

• Definition: Cloud platform providing ultra-fast inference using Groq chips.

12. Inference

• Definition: Time it takes for a model to process input and produce output.

• Factors: Model size, hardware, task complexity.

13. Prompt Engineering

• Definition: Crafting prompts to improve answer quality, accuracy, and consistency. Good prompt engineering ensures the model outputs what you want in a clear, reliable way.

Types of Prompting & When to Use

Elements of a Prompt

When to Use Each Prompt

• Zero-shot: Quick answers, testing ideas, or general questions.

• Few-shot: When style, accuracy, or specific formatting matters.

• CoT: Multi-step reasoning or tasks needing logic explanations.

• Negative prompting: Only to steer away from specific unwanted behaviors; combine with positive instructions.

Types of Prompting with Examples

1. Zero-shot Prompting

(No examples are given; just instructions and input.)

✅ Example 1:

Prompt:

“Translate the following sentence into French: I love learning new things.”

Output:

“J’aime apprendre de nouvelles choses.”

✅ Example 2:

Prompt:

“Write a tweet about coffee in less than 15 words.”

Output:

“Coffee: the fuel that turns thoughts into action. ☕🔥”

2. Few-shot Prompting

(A few examples are provided before asking the model to generate new outputs.)

✅ Example 1:

Prompt:

“Classify the sentiment of the following reviews as Positive, Neutral, or Negative.

• ‘The food was delicious and service was amazing!’ → Positive

• ‘The movie was okay, nothing special.’ → Neutral

• ‘The product broke the first day I used it.’ → Negative

  Now classify: ‘The delivery was quick but packaging was bad.’”

  Output:

  “Neutral”

✅ Example 2:

Prompt:

“Convert numbers to words.

• 42 → forty-two

• 103 → one hundred three

• 999 → nine hundred ninety-nine

  Now convert: 275”

  Output:

  “two hundred seventy-five”

3. Chain-of-Thought (CoT) Prompting

(Ask model to “think step by step” for reasoning tasks.)

✅ Example 1:

Prompt:

“If a train travels 60 km in 1 hour, how far will it travel in 4.5 hours? Think step by step.”

Output (CoT):

• Speed = 60 km/h

• Time = 4.5 hours

• Distance = 60 × 4.5 = 270 km

  Final Answer: 270 km

✅ Example 2:

Prompt:

“A shopkeeper bought 50 apples at ₹20 each. He sold them at ₹25 each. What is his profit? Think step by step.”

Output (CoT):

• Cost price per apple = ₹20

• Selling price per apple = ₹25

• Profit per apple = 25 – 20 = ₹5

• Total apples = 50

• Total profit = 50 × 5 = ₹250

  Final Answer: ₹250

4. Negative Prompting

(Steer the model away from unwanted behavior.)

✅ Example 1:

Prompt:

“Write a professional email to a client about project delay. Do not use any casual words like ‘hey,’ ‘buddy,’ or emojis.”

Output:

“Dear Client,

We regret to inform you that the project will be delayed by two weeks…”

✅ Example 2:

Prompt:

“Summarize this article in 100 words. Do not add your own opinions or analysis.”

Output:

“A summary of the article without extra interpretation.”

General Tips for Effective Prompting

1. Start simple and iterate

   • Test a basic prompt first, then refine.

   • Example: “Summarize this article” → “Summarize in 100 words with bullet points.”

2. Clearly state instructions

   • Avoid ambiguous language.

   • Example: “Write a professional email to a client summarizing the update in three bullet points.”

3. Use separators

   • Helps model distinguish instructions, data, and expected output.

   • Examples: """ or ###

4. Be specific and detailed

   • Include style, tone, format, and length.

   • Example: “Write a 150-word summary in a casual tone suitable for teenagers.”

5. Provide examples of desired output

   • Guides the model on style and content.

   • Example: Show one sample summary before asking for another.

6. Avoid negative instructions when possible

   • Instead of “Do not include slang,” say “Use professional language.”

7. Move from simple to complex

   • Break tasks into steps.

   • Example: First list key points, then expand each into paragraphs.

8. Reduce fluff

   • Avoid vague or overly descriptive language; keep prompts concise but clear.

9. Leverage leading words for code generation

   • Words like Write, Generate, Create help the model understand intent for code tasks.

   • Example: “Generate a Python function that sorts a list of numbers in ascending order.”