Function calling allows Claude to interact with external functions and tools in a structured way. This guide will walk you through implementing function calling with Claude using Python, complete with examples and best practices.

Prerequisites

To get started, you'll need:

• Python 3.7+
• anthropic Python package
• A valid API key from Anthropic

Basic Setup

from anthropic import Anthropic
import json
# Initialize the client
anthropic = Anthropic(api_key='your-api-key')

Defining Functions

function_schema = {
    "name": "get_weather",
    "description": "Get the current weather for a specific location",
    "parameters": {
        "type": "object",
        "properties": {
            "location": {
                "type": "string",
                "description": "City name or coordinates"
            },
            "unit": {
                "type": "string",
                "enum": ["celsius", "fahrenheit"],
                "description": "Temperature unit"
            }
        },
        "required": ["location"]
    }
}

Making Function Calls

A Step-by-Step Guide to LLM Function Calling in Python
Function calling allows Claude to interact with external functions and tools in a structured way. This guide will walk you through implementing function calling with Claude using Python, complete with examples and best practices.
Prerequisites
To get started, you'll need:
Python 3.7+
anthropic Python package
A valid API key from Anthropic

Basic Setup
from anthropic import Anthropic
import json
# Initialize the client
anthropic = Anthropic(api_key='your-api-key')
Defining Functions
function_schema = {
    "name": "get_weather",
    "description": "Get the current weather for a specific location",
    "parameters": {
        "type": "object",
        "properties": {
            "location": {
                "type": "string",
                "description": "City name or coordinates"
            },
            "unit": {
                "type": "string",
                "enum": ["celsius", "fahrenheit"],
                "description": "Temperature unit"
            }
        },
        "required": ["location"]
    }
}
Making Function Calls
def get_weather(location, unit="celsius"):
    # This is a mock implementation but you can all call your API
    return {
        "location": location,
        "temperature": 22 if unit == "celsius" else 72,
        "conditions": "sunny"
    }
def process_function_call(message):
    try:
        # Parse the function call parameters
        params = json.loads(message.content)
        # Call the appropriate function
        if message.name == "get_weather":
            result = get_weather(**params)
            return json.dumps(result)
        else:
            raise ValueError(f"Unknown function: {message.name}")
    except Exception as e:
        return json.dumps({"error": str(e)})
# Example conversation with function calling
messages = [
    {
        "role": "user",
        "content": "What's the weather like in Paris?"
    }
]
while True:
    response = anthropic.messages.create(
        model="claude-3-5-haiku-latest",
        messages=messages,
        tools=[function_schema]
    )
    # Check if Claude wants to call a function
    if response.tool_calls:
        for tool_call in response.tool_calls:
            # Execute the function
            result = process_function_call(tool_call)
            # Add the function result to the conversation
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "name": tool_call.name,
                "content": result
            })
    else:
        # Normal response - print and break
        print(response.content)
        break

Best Practices

1. Clear Function Descriptions

• Write detailed descriptions for your functions
• Specify parameter types and constraints clearly
• Include examples in the descriptions when helpful

1. Input Validation

• Validate all function inputs before processing
• Return meaningful error messages
• Handle edge cases gracefully

1. Response Formatting

• Return consistent JSON structures
• Include status indicators in responses
• Format error messages uniformly

4 . Security Considerations

• Validate and sanitize all inputs
• Implement rate limiting if needed
• Use appropriate authentication
• Don't expose sensitive information in function descriptions

Conclusion

Function calling with Claude enables powerful integrations between the language model and external tools. By following these best practices and implementing proper error handling, you can create robust and reliable function-calling implementations.

In the rapidly evolving landscape of artificial intelligence, Retrieval Augmented Generation (RAG) systems have emerged as a crucial technology for enhancing Large Language Models with external knowledge. However, ensuring the quality and reliability of these systems requires robust evaluation methods. Enter RAGAS (Retrieval Augmented Generation Assessment System), a groundbreaking framework that provides comprehensive metrics for evaluating RAG systems.

The Importance of RAG Evaluation

RAG systems combine the power of retrieval mechanisms with generative AI to produce more accurate and contextually relevant responses. However, their complexity introduces multiple potential points of failure, from retrieval accuracy to answer generation quality. This is where RAGAS steps in, offering a structured approach to assessment that helps developers and organizations maintain high standards in their RAG implementations.

Core RAGAS Metrics

Context Precision

Context precision measures how relevant the retrieved information is to the given query. This metric evaluates whether the system is pulling in the right pieces of information from its knowledge base. A high context precision score indicates that the retrieval component is effectively identifying and selecting relevant content, while a low score might suggest that the system is retrieving tangentially related or irrelevant information.

Faithfulness

Faithfulness assesses the alignment between the generated answer and the provided context. This crucial metric ensures that the system's responses are grounded in the retrieved information rather than hallucinated or drawn from the model's pre-trained knowledge. A faithful response should be directly supported by the context, without introducing external or contradictory information.

Answer Relevancy

The answer relevancy metric evaluates how well the generated response addresses the original question. This goes beyond mere factual accuracy to assess whether the answer provides the information the user was seeking. A highly relevant answer should directly address the query's intent and provide appropriate detail level.

Context Recall

Context recall compares the retrieved contexts against ground truth information, measuring how much of the necessary information was successfully retrieved. This metric helps identify cases where critical information might be missing from the system's responses, even if what was retrieved was accurate.

Practical Implementation

RAGAS's implementation is designed to be straightforward while providing deep insights. The framework accepts evaluation datasets containing:

Questions posed to the system
Retrieved contexts for each question
Generated answers
Ground truth answers for comparison

This structured approach allows for automated evaluation across multiple dimensions of RAG system performance, providing a comprehensive view of system quality.

Benefits and Applications

Quality Assurance

RAGAS enables continuous monitoring of RAG system performance, helping teams identify degradation or improvements over time. This is particularly valuable when making changes to the retrieval mechanism or underlying models.

Development Guidance

The granular metrics provided by RAGAS help developers pinpoint specific areas needing improvement. For instance, low context precision scores might indicate the need to refine the retrieval strategy, while poor faithfulness scores might suggest issues with the generation parameters.

Comparative Analysis

Organizations can use RAGAS to compare different RAG implementations or configurations, making it easier to make data-driven decisions about system architecture and deployment.

Best Practices for RAGAS Implementation

1. Regular Evaluation Implement RAGAS as part of your regular testing pipeline to catch potential issues early and maintain consistent quality.
2. Diverse Test Sets Create evaluation datasets that cover various query types, complexities, and subject matters to ensure robust assessment.
3. Metric Thresholds Establish minimum acceptable scores for each metric based on your application's requirements and use these as quality gates in your deployment process.
4. Iterative Refinement Use RAGAS metrics to guide iterative improvements to your RAG system, focusing on the areas showing the lowest performance scores.

Practical Code Examples

Basic RAGAS Evaluation

Here's a simple example of how to implement RAGAS evaluation in your Python code:

from ragas import evaluate
from datasets import Dataset
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision
)

def evaluate_rag_system(questions, contexts, answers, references):
    """
    Simple function to evaluate a RAG system using RAGAS

    Args:
        questions (list): List of questions
        contexts (list): List of contexts for each question
        answers (list): List of generated answers
        references (list): List of reference answers (ground truth)

    Returns:
        EvaluationResult: RAGAS evaluation results
    """
    # First, let's make sure you have the required packages
    try:
        import ragas
        import datasets
    except ImportError:
        print("Please install required packages:")
        print("pip install ragas datasets")
        return None

    # Prepare evaluation dataset
    eval_data = {
        "question": questions,
        "contexts": [[ctx] for ctx in contexts],  # RAGAS expects list of lists
        "answer": answers,
        "reference": references
    }

    # Convert to Dataset format
    eval_dataset = Dataset.from_dict(eval_data)

    # Run evaluation with key metrics
    results = evaluate(
        eval_dataset,
        metrics=[
            faithfulness,      # Measures if answer is supported by context
            answer_relevancy,  # Measures if answer is relevant to question
            context_precision  # Measures if retrieved context is relevant
        ]
    )

    return results

# Example usage
if __name__ == "__main__":
    # Sample data
    questions = [
        "What are the key features of Python?",
        "How does Python handle memory management?"
    ]

    contexts = [
        "Python is a high-level programming language known for its simple syntax and readability. It supports multiple programming paradigms including object-oriented, imperative, and functional programming.",
        "Python uses automatic memory management through garbage collection. It employs reference counting as the primary mechanism and has a cycle-detecting garbage collector for handling circular references."
    ]

    answers = [
        "Python is known for its simple syntax and readability, and it supports multiple programming paradigms including OOP.",
        "Python handles memory management automatically through garbage collection, using reference counting and cycle detection."
    ]

    references = [
        "Python's key features include readable syntax and support for multiple programming paradigms like OOP, imperative, and functional programming.",
        "Python uses automatic garbage collection with reference counting and cycle detection for memory management."
    ]

    # Run evaluation
    results = evaluate_rag_system(
        questions=questions,
        contexts=contexts,
        answers=answers,
        references=references
    )

    if results:
        # Print results
        print("\nRAG System Evaluation Results:")
        print(results)  

Attended the FOSS United Chennai Meetup Yesterday!

After, attending Grafana & Friends Meetup, straightly went to FOSS United Chennai Meetup at YuniQ in Taramani.

Had a chance to meet my Friends face to face after a long time. Sakhil Ahamed E. , Dhanasekar T, Dhanasekar Chellamuthu, Thanga Ayyanar, Parameshwar Arunachalam, Guru Prasath S, Krisha, Gopinathan Asokan

Talks Summary,

1. Ansh Arora, Gave a tour on FOSS United, How its formed, Motto, FOSS Hack, FOSS Clubs.

2. Karthikeyan A K, Gave a talk on his open source product injee (The no configuration instant database for frontend developers.). It’s a great tool. He gave a personal demo for me. It’s a great tool with lot of potentials. Would like to contribute !.

3. Justin Benito, How they celebrated New Year with https://tamilnadu.tech
It’s single go to page for events in Tamil Nadu. If you are interested ,go to the repo https://lnkd.in/geKFqnFz and contribute.

From Kaniyam Foundation we are maintaining a Google Calendar for a long time on Tech Events happening in Tamil Nadu https://lnkd.in/gbmGMuaa.

4. Prasanth Baskar, gave a talk on Harbor, OSS Container Registry with SBOM and more functionalities. SBOM was new to me.

5. Thanga Ayyanar, gave a talk on Static Site Generation with Emacs.

At the end, we had a group photo and went for tea. Got to meet my Juniors from St. Joseph’s Institute of Technology in this meet. Had a discussion with Parameshwar Arunachalam on his BuildToLearn Experience. They started prototyping an Tinder app for Tamil Words. After that had a small discussion on our Feb 8th Glug Inauguration at St. Joseph’s Institute of Technology Dr. KARTHI M .

Happy to see, lot of minds travelling from different districts to attend this meet.

Introduction to RAG and GraphRAG

What is RAG?

RAG, or Retrieval-Augmented Generation, is a technique that combines information retrieval with text generation to produce more accurate and contextually relevant responses. It works by retrieving relevant information from a knowledge base and then using that information to augment the input to a large language model (LLM).

What is GraphRAG?

GraphRAG is an extension of the RAG framework that incorporates graph-structured knowledge. Instead of using a flat document-based retrieval system, GraphRAG utilizes graph databases to represent and query complex relationships between entities and concepts.

Applications of RAG and GraphRAG

RAG Applications

1. Question-answering systems
2. Chatbots and virtual assistants
3. Content summarization
4. Fact-checking and information verification
5. Personalized content generation

GraphRAG Applications

1. Knowledge graph-based question answering
2. Complex reasoning tasks
3. Recommendation systems
4. Fraud detection and financial analysis
5. Scientific research and literature review

Pros and Cons of RAG

Pros of RAG

1. Improved accuracy: By retrieving relevant information, RAG can provide more accurate and up-to-date responses.
2. Reduced hallucinations: The retrieval step helps ground the model's responses in factual information.
3. Scalability: Easy to update the knowledge base without retraining the entire model.
4. Transparency: The retrieved documents can be used to explain the model's reasoning.
5. Customizability: Can be tailored to specific domains or use cases.

Cons of RAG

1. Latency: The retrieval step can introduce additional latency compared to pure generation models.
2. Complexity: Implementing and maintaining a RAG system can be more complex than using a standalone LLM.
3. Quality-dependent: The system's performance heavily relies on the quality and coverage of the knowledge base.
4. Potential for irrelevant retrievals: If the retrieval system is not well-tuned, it may fetch irrelevant information.
5. Storage requirements: Maintaining a large knowledge base can be resource-intensive.

Pros and Cons of GraphRAG

Pros of GraphRAG

1. Complex relationship modeling: Can represent and query intricate relationships between entities.
2. Improved context understanding: Graph structure allows for better capturing of contextual information.
3. Multi-hop reasoning: Enables answering questions that require following multiple steps or connections.
4. Flexibility: Can incorporate various types of information and relationships in a unified framework.
5. Efficient querying: Graph databases can be more efficient for certain types of queries compared to traditional databases.

Cons of GraphRAG

1. Increased complexity: Building and maintaining a knowledge graph is more complex than a document-based system.
2. Higher computational requirements: Graph operations can be more computationally intensive.
3. Data preparation challenges: Converting unstructured data into a graph format can be time-consuming and error-prone.
4. Potential for overfitting: If the graph structure is too specific, it may not generalize well to new queries.
5. Scalability concerns: As the graph grows, managing and querying it efficiently can become challenging.

Comparing RAG and GraphRAG

When to Use RAG

• For general-purpose question-answering systems
• When dealing with primarily textual information
• In scenarios where quick implementation and simplicity are priorities
• For applications that don't require complex relationship modeling

When to Use GraphRAG

• For domain-specific applications with complex relationships (e.g., scientific research, financial analysis)
• When multi-hop reasoning is crucial
• In scenarios where understanding context and relationships is more important than raw text retrieval
• For applications that can benefit from a structured knowledge representation

Future Directions and Challenges

Advancements in RAG

1. Improved retrieval algorithms
2. Better integration with LLMs
3. Real-time knowledge base updates
4. Multi-modal RAG (incorporating images, audio, etc.)

Advancements in GraphRAG

1. More efficient graph embedding techniques
2. Integration with other AI techniques (e.g., reinforcement learning)
3. Automated graph construction and maintenance
4. Explainable AI through graph structures

Common Challenges

1. Ensuring data privacy and security
2. Handling biases in knowledge bases
3. Improving computational efficiency
4. Enhancing the interpretability of results

Conclusion

Both RAG and GraphRAG represent significant advancements in augmenting language models with external knowledge. While RAG offers a more straightforward approach suitable for many general applications, GraphRAG provides a powerful framework for handling complex, relationship-rich domains. The choice between the two depends on the specific requirements of the application, the nature of the data, and the complexity of the reasoning tasks involved. As these technologies continue to evolve, we can expect to see even more sophisticated and efficient ways of combining retrieval, reasoning, and generation in AI systems.

Today, I want to capture notes that I learnt from trailhead academy on connecting postman to a salesforce org.

To make postman allow changes at Salesforce org, we have to enable CORS policy in Salesforce. See below what does CORS mean.

CORS- Cross Origin Resource Sharing

It is a browser feature that controls how resources are requested from one site to another site. By configuring CORS, it enables special permissions for other external websites to access our salesforce data. In this case, we are enabling CORS for postman to access salesforce.

• From setup ==> search for CORS ==> Add https://*.postman.co and https://*.postman.com URL
• After that, in postman desktop -Do below steps one by one.
• Create a separate workspace for Salesforce APIs to play around.
• Search for Salesforce APIs. It does list out all the available collections.
• Fork “Salesforce Platform API” and it will available to your local postman workspace.
• After that, go to “Authorization” click on “Generate token” and copy “instance” URL.
• Configure “_endpoint” value from variable tab as “instance” URL
• All set and that’s it. You can play around whatever requests that are available.

Today, I want to capture notes that I learnt from trailhead academy on connecting postman to a salesforce org.

To make postman allow changes at Salesforce org, we have to enable CORS policy in Salesforce. See below what does CORS mean.

CORS- Cross Origin Resource Sharing

It is a browser feature that controls how resources are requested from one site to another site. By configuring CORS, it enables special permissions for other external websites to access our salesforce data. In this case, we are enabling CORS for postman to access salesforce.

• From setup ==> search for CORS ==> Add https://*.postman.co and https://*.postman.com URL
• After that, in postman desktop -Do below steps one by one.
• Create a separate workspace for Salesforce APIs to play around.
• Search for Salesforce APIs. It does list out all the available collections.
• Fork “Salesforce Platform API” and it will available to your local postman workspace.
• After that, go to “Authorization” click on “Generate token” and copy “instance” URL.
• Configure “_endpoint” value from variable tab as “instance” URL
• All set and that’s it. You can play around whatever requests that are available.

In this blog, i write about SLI, SLA, SLO . I got a refreshing session from a podcast https://open.spotify.com/episode/2Ags7x1WrxaFLRd3KBU50K?si=vbYtW_YVQpOi8HwT9AOM1g. This blog is about that.

In the world of service reliability and performance, the terms SLO, SLA, and SLI are often used interchangeably but have distinct meanings. This blog explains these terms in detail, their importance, and how they relate to each other with practical examples.

1. What are SLIs, SLOs, and SLAs?

Service Level Indicators (SLIs)

An SLI is a metric that quantifies the level of service provided by a system. It measures specific aspects of performance or reliability, such as response time, uptime, or error rate.

Example:

• Percentage of successful HTTP requests over a time window.
• Average latency of API responses.

Service Level Objectives (SLOs)

An SLO is a target value or range for an SLI. It defines what “acceptable” performance or reliability looks like from the perspective of the service provider or user.

Example:

• “99.9% of HTTP requests must succeed within 500ms.”
• “The application should have 99.95% uptime per quarter.”

Service Level Agreements (SLAs)

An SLA is a formal contract between a service provider and a customer that specifies the agreed-upon SLOs and the consequences of failing to meet them, such as penalties or compensations.

Example:

• “If the uptime drops below 99.5% in a calendar month, the customer will receive a 10% credit on their monthly bill.”

2. Relationship Between SLIs, SLOs, and SLAs

• SLIs are the metrics measured.
• SLOs are the goals or benchmarks derived from SLIs.
• SLAs are agreements that formalize SLOs and include penalties or incentives.

SLI: Average latency of API requests.
SLO: 95% of API requests should have latency under 200ms.
SLA: If latency exceeds the SLO for two consecutive weeks, the provider will issue service credits.

3. Practical Examples

Example 1: Web Hosting Service

• SLI: Percentage of time the website is available.
• SLO: The website must be available 99.9% of the time per month.
• SLA: If uptime falls below 99.9%, the customer will receive a refund of 20% of their monthly fee.

Example 2: Cloud Storage Service

• SLI: Time taken to retrieve a file from storage.
• SLO: 95% of retrieval requests must complete within 300ms.
• SLA: If retrieval times exceed 300ms for more than 5% of requests in a billing cycle, customers will get free additional storage for the next month.

Example 3: API Service

• SLI: Error rate of API responses.
• SLO: Error rate must be below 0.1% for all requests in a day.
• SLA: If the error rate exceeds 0.1% for more than three days in a row, the customer is entitled to a credit worth 5% of their monthly subscription fee.

Below listed are the high level steps involved to create a basic Django application.

1. install python
2. use venv before installing django =>python -m venv tutorial-env
3. activate the venv: tutorial-env\Scripts\activate
4. install django in the venv=> python -m pip install django
5. check version =>django-admin –version
6. Create a django project => django-admin startproject myApp
7. To start the webserver =>python manage.py runserver
8. From the myApp location, open cmd and type code .=> which will open vs code for this project from VSCode 1. init.py => when the proj receives a request it will understand that this is a package with the help of this init file 2.asgi & wsgi =>Both required during deployment 3.settings.py =>DB, Language, Timezone, Static, URL etc.,
9. URLs.py => will contain the list of urls used for the project
10. outside of myApp, db.sqlite3 will be used by default as a lite weight DB
11. Manage.py =>Very important file
12. Within the project myAPP, we can create multiple application. to create a new app => python manage.py startapp blog 1.migrations => DB related
    1. init => represent that it is a pkg
    2. admin => for admin purposes
    3. apps => app related config eg: name of the app etc.,
    4. models => contents 6.tests => used for testing the app 7.views 10.Register the app: from myApp->setting.py under Installed_Apps ->add the recently created app ‘blog’ 11.Create the first View:(in general we will receive the request and send back the response) from blog->views.py 1.import HTTPResponse => from django.http import HttpRespose a. Create a python function which take request as a parameter and return the HttpResponse=>A static string output 2.under blog, create a python file by name “urls.py” a.within that file add the urlpatterns list similar to myApp->urls.pyb.in this file, import path, and view from the project->from . import views c.to the urlpatterns list add and entry to the python function created under views.py path(“”<“” represents home directory>,views.index,name=”index”) 3.In myApp-> urls.py a. import path,include from django.urls b. under urlpatterns, add path(“”,include(“blog.urls”)) –> including the url from the blog->urls.py
       1. Time to test the changes. Go to the application url. it should show the content from views.py->index function
       2. Alternatively if we want to call the index with a seperate url a. from the myApp->urls.py-> in the urlpatterns.path -> instead of “”, provide “blogs/” b. Test the same with both default application url and url/blogs

Locust is an excellent load testing tool, enabling developers to simulate concurrent user traffic on their applications. One of its powerful features is wait times, which simulate the realistic user think time between consecutive tasks. By customizing wait times, you can emulate user behavior more effectively, making your tests reflect actual usage patterns.

In this blog, we’ll cover,

1. What wait times are in Locust.
2. Built-in wait time options.
3. Creating custom wait times.
4. A full example with instructions to run the test.

What Are Wait Times in Locust?

In real-world scenarios, users don’t interact with applications continuously. After performing an action (e.g., submitting a form), they often pause before the next action. This pause is called a wait time in Locust, and it plays a crucial role in mimicking real-life user behavior.

Locust provides several ways to define these wait times within your test scenarios.

FastAPI App Overview

Here’s the FastAPI app that we’ll test,

from fastapi import FastAPI

# Create a FastAPI app instance
app = FastAPI()

# Define a route with a GET method
@app.get("/")
def read_root():
    return {"message": "Welcome to FastAPI!"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}

Locust Examples for FastAPI

1. Constant Wait Time Example

Here, we’ll simulate constant pauses between user requests

from locust import HttpUser, task, constant

class FastAPIUser(HttpUser):
    wait_time = constant(2)  # Wait for 2 seconds between requests

    @task
    def get_root(self):
        self.client.get("/")  # Simulates a GET request to the root endpoint

    @task
    def get_item(self):
        self.client.get("/items/42?q=test")  # Simulates a GET request with path and query parameters

2. Between wait time Example

Simulating random pauses between requests.

from locust import HttpUser, task, between

class FastAPIUser(HttpUser):
    wait_time = between(1, 5)  # Random wait time between 1 and 5 seconds

    @task(3)  # Weighted task: this runs 3 times more often
    def get_root(self):
        self.client.get("/")

    @task(1)
    def get_item(self):
        self.client.get("/items/10?q=locust")

3. Custom Wait Time Example

Using a custom wait time function to introduce more complex user behavior

import random
from locust import HttpUser, task

def custom_wait():
    return max(1, random.normalvariate(3, 1))  # Normal distribution (mean: 3s, stddev: 1s)

class FastAPIUser(HttpUser):
    wait_time = custom_wait

    @task
    def get_root(self):
        self.client.get("/")

    @task
    def get_item(self):
        self.client.get("/items/99?q=custom")

Full Test Example

Combining all the above elements, here’s a complete Locust test for your FastAPI app.

from locust import HttpUser, task, between
import random

# Custom wait time function
def custom_wait():
    return max(1, random.uniform(1, 3))  # Random wait time between 1 and 3 seconds

class FastAPIUser(HttpUser):
    wait_time = custom_wait  # Use the custom wait time

    @task(3)
    def browse_homepage(self):
        """Simulates browsing the root endpoint."""
        self.client.get("/")

    @task(1)
    def browse_item(self):
        """Simulates fetching an item with ID and query parameter."""
        item_id = random.randint(1, 100)
        self.client.get(f"/items/{item_id}?q=test")

Running Locust for FastAPI

1. Run Your FastAPI App
   Save the FastAPI app code in a file (e.g., main.py) and start the server

uvicorn main:app --reload

By default, the app will run on http://127.0.0.1:8000.

2. Run Locust
Save the Locust file as locustfile.py and start Locust.

locust -f locustfile.py

3. Configure Locust
Open http://localhost:8089 in your browser and enter:

• Host: http://127.0.0.1:8000
• Number of users and spawn rate based on your testing requirements.

4. Run in Headless Mode (Optional)
Use the following command to run Locust in headless mode

locust -f locustfile.py --headless -u 50 -r 10 --host http://127.0.0.1:8000`

-u 50: Simulate 50 users.

-r 10: Spawn 10 users per second.

The Client-Server Architecture

Once upon a time in the electronic city of Banglore, there was a popular digital tea kadai. This cafe was unique because it didn’t serve traditional coffee or pastries. Instead, it served data and services to its customers developers, businesses, and tech enthusiasts who were hungry for information and resources.

The Client:

One day, a young developer named Dinesh walked into tea kadai. He was working on a new app and needed to fetch some data from the cafe’s servers. In this story, Dinesh represents the client. As a client, his role was to request specific services and data from the cafe. He approached the counter and handed over his order slip, detailing what he needed.

The Server:

Behind the counter was Syed, the tea master, representing the server. Syed’s job was to take Dinesh’s request, process it, and deliver the requested data back to him.

Syed had access to a vast array of resources stored in the cafe’s back room, where all the data was kept. When Dinesh made his request, Syed quickly went to the back, gathered the data, and handed it back to Dinesh.

The client-server architecture at Tea Kadai worked seamlessly.

Dinesh, as the client, could make requests whenever he needed, and

Syed, as the server, would respond by providing the requested data.

This interaction was efficient, allowing many clients to be served by a single server at the cafe.

Docker’s Client-Server Technology

As Tea Kadai grew in popularity, it decided to expand its services to deliver data more efficiently and flexibly. To do this, they adopted a new technology called Docker, which helped them manage their operations more effectively.

Docker Client:

In the world of Docker at Tea Kadai, Dinesh still played the role of the client. But now, instead of just making simple data requests, she could request entire environments where he could test and run his applications.

These environments, called containers, were like personalized booths in the cafe where Alice could have her own setup with everything she needed to work on her app.

Dinesh used a special tool called the Docker Client to place his order. With this tool, he could specify exactly what he wanted in his container like the operating system, libraries, and applications needed for his app. The Docker Client was her interface for communicating with the cafe’s new backend system.

Docker Server (Daemon):

Behind the scenes, Tea Kadai had installed a powerful system known as the Docker Daemon, which acted as the server in this setup. The Docker Daemon was responsible for creating, running, and managing the containers requested by clients like Dinesh.

When Dinesh sent his container request using the Docker Client, the Docker Daemon received it, built the container environment, and handed it back to Dinesh for use.

Docker Images:

The Tea Kadai had a collection of premade recipes called Docker Images. These images were like blueprints for creating containers, containing all the necessary ingredients and instructions.

When Dinesh requested a new container, the Docker Daemon used these images to quickly prepare the environment.

Flexibility and Isolation:

The beauty of Docker at Tea Kadai was that it allowed multiple clients like Dinesh to have their containers running simultaneously, each isolated from the others. This isolation ensured that one client’s work wouldn’t interfere with another’s, just like having separate booths in the cafe for each customer. Dinesh could run, test, and even destroy his environment without affecting anyone else.

At the end,

In the vibrant city of Banglore, Tea Kadai thrived by adopting client-server architecture and Docker’s client-server technology. This approach allowed them to efficiently serve data and services while providing flexible, isolated environments for their clients. Dinesh and many others continued to come to tea kadai, knowing they could always get what they needed in a reliable and innovative way.

Introduction:

Welcome to the world of Transformers, where cutting-edge natural language processing models are revolutionizing the way I interact with data. In this series of blogs, I will embark on a journey to explore and understand the capabilities of the TAPAS (Tabular Pre-trained Language Model) model, which is designed to extract valuable insights from tabular data. To kick things off, I'll delve into the basics of TAPAS and see it in action on a real-world dataset.

Understanding TAPAS:

TAPAS is a powerful language model developed by Google that specializes in processing tabular data. Unlike traditional models, TAPAS can handle structured data seamlessly, making it a game-changer for tasks involving tables and spreadsheets. With a token size of 512k, TAPAS can process large datasets efficiently, making it a valuable tool for data analysts and scientists.

My Dataset:

For this introductory exploration, I will work with a clinical trial dataset [Clinicaltrails.gov]. To start, I load the dataset and create a data frame containing the "label" column. This column contains information about gender distribution in clinical trials. I'll be using this data to ask questions and obtain insights.

from transformers import pipeline,TapasTokenizer, TapasForQuestionAnswering
import pandas as pd
import datasets

# Load the dataset (only once)
dataset = datasets.load_dataset("Kira-Asimov/gender_clinical_trial")

# Create the clinical_trials_data DataFrame with just the "label" column (only once)
clinical_trials_data = pd.DataFrame({
    "id": dataset["train"]["id"],
    "label": dataset["train"]["label"],
})

clinical_trials_data = clinical_trials_data.head(100)

Asking Questions with TAPAS:

The magic of TAPAS begins when I start asking questions about our data. In this example, I want to know how many records are in the dataset and how many of them are gender-specific (Male and Female). I construct queries like:

"How many records are in total?"
"How many 'Male' only gender studies are in total?"
"How many 'Female' only gender studies are in total?"

Using TAPAS to Answer Questions:

I utilize the "google/tapas-base-finetuned-wtq" model and its associated tokenizer to process our questions and tabular data. TAPAS tokenizes the data, extracts answers, and even performs aggregations when necessary.

counts = {}
answers = []

def TAPAS_model_learning(clinical_trials_data):
    model_name = "google/tapas-base-finetuned-wtq"
    model = TapasForQuestionAnswering.from_pretrained(model_name)
    tokenizer = TapasTokenizer.from_pretrained(model_name)


    queries = [
        "How many records are in total ?",
        "How many 'Male' only gender studies are in total ?",
        "How many 'Female' only gender studies are in total ?",
    ]

    for query in queries:
            model_name = "google/tapas-base-finetuned-wtq"
            model = TapasForQuestionAnswering.from_pretrained(model_name)
            tokenizer = TapasTokenizer.from_pretrained(model_name)
            # Tokenize the query and table
            inputs = tokenizer(table=clinical_trials_data, queries=query, padding="max_length", return_tensors="pt", truncation=True)

            # Get the model's output
            outputs = model(**inputs)
            predicted_answer_coordinates, predicted_aggregation_indices = tokenizer.convert_logits_to_predictions(
                inputs, outputs.logits.detach(), outputs.logits_aggregation.detach()
            )

            # Initialize variables to store answers for the current query
            current_answers = []

            # Count the number of cells in the answer coordinates
            count = 0
            for coordinates in predicted_answer_coordinates:
                count += len(coordinates)
                # Collect the cell values for the current answer
                cell_values = []
                for coordinate in coordinates:
                    cell_values.append(clinical_trials_data.iat[coordinate])

                current_answers.append(", ".join(cell_values))

            # Check if there are no matching cells for the query
            if count == 0:
                current_answers = ["No matching cells"]
            counts[query] = count
            answers.append(current_answers)
    return counts,answers

Evaluating TAPAS Performance:

Now, let's see how well TAPAS performs in answering our questions. I have expected answers for each question variation, and I calculate the error percentage to assess the model's accuracy.

# Prepare your variations of the same question and their expected answers
question_variations = {
    "How many records are in total ?": 100,
    "How many 'Male' only gender studies are in total ?": 3,
    "How many 'Female' only gender studies are in total ?":9,
}



# Use TAPAS to predict the answer based on your tabular data and the question
predicted_count,predicted_answer = TAPAS_model_learning(clinical_trials_data)
print(predicted_count)
# Check if any predicted answer matches the expected answer
for key,value in predicted_count.items():
    error = question_variations[key] - value


    # Calculate the accuracy percentage
    error_percentage = (error / question_variations[key]) * 100

    # Print the results
    print(f"{key}: Model Value: {value}, Excepted Value: {question_variations[key]}, Error Percentage: {error_percentage :.2f}%")

Results and Insights:

The output reveals how TAPAS handled our queries:

For the question "How many records are in total?", TAPAS predicted 69 records, with an error percentage of 31.00% compared to the expected value of 100 records.

For the question "How many 'Male' only gender studies are in total?", TAPAS correctly predicted 3 records, with a perfect match to the expected value.

For the question "How many 'Female' only gender studies are in total?", TAPAS predicted 2 records, with a significant error percentage of 77.78% compared to the expected value of 9 records.

Conclusion and Future Exploration:

In this first blog of our TAPAS exploration series, I introduced you to the model's capabilities and showcased its performance on a real dataset. I observed both accurate and less accurate predictions, highlighting the importance of understanding and fine-tuning the model for specific tasks.

In our future blogs, I will delve deeper into TAPAS, exploring its architecture, fine-tuning techniques, and strategies for improving its accuracy on tabular data. Stay tuned as I unlock the full potential of TAPAS for data analysis and insights.