Jekyll2026-07-08T03:56:33+00:00https://farhan0167.github.io/feed.xmlblankA simple, whitespace theme for academics. Based on [*folio](https://github.com/bogoli/-folio) design. Building a minimal agent harness from scratch2026-06-15T09:00:00+00:002026-06-15T09:00:00+00:00https://farhan0167.github.io/blog/2026/highlight-projectReplace this with the story of your highlight project. This post is marked featured: true, so it renders as the large hero at the top of the blog.
Write a few paragraphs about what you built, why, and what you learned.
]]>Ahmad Farhan IshraqWhen machines begin to reason over knowledge2026-06-01T09:00:00+00:002026-06-01T09:00:00+00:00https://farhan0167.github.io/blog/2026/second-highlightThis post is also featured: true. The newest featured post becomes the big hero on the left; the next one (this one) becomes the secondary card on the right.
Swap in your own content.
]]>Ahmad Farhan IshraqNotes on shipping small tools2026-05-20T09:00:00+00:002026-05-20T09:00:00+00:00https://farhan0167.github.io/blog/2026/first-postA normal post. Add featured: true to promote it into the hero row, or leave it out to keep it in the Latest list.]]>Ahmad Farhan IshraqThe weight of good defaults2026-04-10T09:00:00+00:002026-04-10T09:00:00+00:00https://farhan0167.github.io/blog/2026/second-postMore filler. Delete these sample posts once you have your own.Test]]>Ahmad Farhan IshraqBuilding a No Code Platform and the BFS Algorithm2024-12-22T19:58:37+00:002024-12-22T19:58:37+00:00https://farhan0167.github.io/blog/2024/building-a-no-code-platform-and-the-bfs-algorithm
For the past couple of months I’ve been building out a low code/no code AI/ML Platform that lets users deploy their ML models as an API. Imagine the following scenario: you’ve trained a deep learning model and pushed it to Huggingface. While the model is great for what you trained it for, it lives inside a jupyter notebook but you need a deployable API where users can directly interact with your model. Or even better, you want to hook your model up with one of the LLM’s out there but you don’t want to spend time coding up the API, think about integration code, etc. That’s essentially what I’m trying to solve.
From the user point of view, you see a flowchart like tool, where you configure your blocks(in the case of Huggingface, you’d paste in your model card), connect them to their input blocks(they essentially dictate whether your model accepts a text or image input or both), and hit create, which then deploys a docker container running a FastAPI server for you to then query. Under the hood, there is a graph being created with each node in the graph loading up the resources needed to run your workload. And in this article, I want to talk about the breadth first search algorithm and how it powers my project.
Now consider the following workflow that runs a Financial Bert model for Sentiment Analysis. You have 3 blocks — the input block which will take your input text, the ML block and the output block which will display the end result.
The first step, would be to take this UI and translate it into format that would speak to the backend. This could look something like:
{ "input": [ "Input_Block": { "run_config": "All user based config", "connections": [ "process.Financial_BERT" ], "payload": "<Insert Positive news for financial BERT>", "implementation": Input_Implementation_Class() } ], "process": [ "Financial_BERT": { "run_config": "All user based config", "connections": [ "output.Output_Block" ], "payload": "<Insert Positive news for financial BERT>", "implementation": HF_MODEL_Class() } ], "output": [ "Output_Block": { "run_config": "All user based config", "connections": [] } ] }
The next step would be taking the payload of one block, passing it into the implementation of another, and you’d know the next block via the connections list. Now, naively you could implement an iterative loop that starts at the input block, traverses its connection by passing the payload around. It would look something like this:
start_node = workflow['input']['Input_Block']
for connection in start_node['connection']: # pass payload to process.Financial_BERT.implementation
This approach would work only if we had a linear workflow, where 1 block connects to only one block. But in the real world, one could have N blocks connecting to 1 block, wherein the following block expects inputs from all N blocks before running itself.
The orange block needs inputs A,B and C as params so it can run.
So how do we ensure inputs from block A,B and C is passed altogether in the orange block? This where the breadth first search comes to the rescue.
The way the BFS algorithm works is by starting at some node, source, it first looks at all its neighbors and traverses the graph in a layer wise fashion. Here’s an excerpt from a Hackerearth article that sums it up best:
So coming back to our use case, we can do something like this:
We can start at some dummy node, look at all it’s immediate neighbors (A,B, and C) and process them, and only when all 3 are processed is when we move on the next layer where the orange block is and pass the 3 block’s output as the orange block’s input. The way we implement this is through a queue that processes nodes in the order they arrived in. We’ll also keep track of all the nodes we already visited and processed so we don’t end up reprocessing them. Below is a step by step flow of how its implemented.
Step by step flow of how I used BFS to process nodes
Here’s the code block that I used to incorporate BFS in my project:
Now that we have a way to pass payloads from one block to another, there’s a whole world of possibilities of what can be implemented. At the moment otto-m8 (which translates to automate), aims to provide all these blocks which implement some form of Deep Learning model. It supports LLM’s(OpenAI and Ollama) and Hugging Face models. When you create a workflow, you get a deployable Docker container with an exposed REST endpoint. And at its core (obviously an oversimplification) the BFS algorithm paves the way for a user input to pass through all the chained models in your workflow.
Thank you for reading, especially if you’ve followed along all the way. Please feel free to try out otto-m8 which can be found here on Github: https://github.com/farhan0167/otto-m8, and let me know what you think. If you like what I’m doing, please share some feedback and support me with a Github star ⭐️!
]]>Embeddings are Everywhere2023-09-13T18:53:33+00:002023-09-13T18:53:33+00:00https://farhan0167.github.io/blog/2023/embeddings-are-everywhere
Earlier in July, I demoed a PDF QnA Bot, which was able to answer user queries related to an uploaded PDF file by utilizing Word Embeddings. You can check out the application here. Embeddings are everywhere, especially in the realm of natural language processing. But what exactly are embeddings, and why are they so vital in the realm of natural language processing? At its core, an embedding serves as a bridge, connecting the abstract world of human language to the mathematical realm of deep neural networks and language models. In doing so, it transforms words, phrases, or even entire documents into numerical forms that machines can comprehend and manipulate.
As illustrated by the PDF QnA Bot project, embeddings wield substantial power when it comes to conducting semantic searches within vast repositories of organizational documents. They serve as the cornerstone for the development of chatbots capable of ingesting extensive volumes of textual data, enabling them to provide insightful answers to user queries.
However, as organizations navigate the fast changing landscape of AI agents and services, there has been a growing concern of data privacy. There are various AI companies that are offering their own embeddings endpoints that organizations can simply integrate within their own software development pipelines to build chatbots like the one I made earlier. Although, OpenAI does not use data passed or processed within their API’s, there has been a growing trend of organizations trying to leverage open source models to benefit from the same level of performance but with more fine grained control of their proprietary data.
One question that usually pops up is how good is an open source model compared to leading AI platforms like OpenAI and Cohere. Even if an open source model performs on par with these platforms, how can an organization host these models, and can organizations justify the costs associated with hosting these models?
In this notebook, I explore 3 different ways we can generate embeddings of textual data. We start with CohereAI, followed by OpenAI and then an open source model provided by HuggingFace. The objective is to use Clustering and Classification to measure how the three models perform, and also create a cost analysis of using each model.
For this experiment, I’ll mostly refer to CohereAI’s amazing notebooks on their embeddings endpoint. More specifically, their demo uses a dataset that I think would be a great resource to test across different embeddings algorithms.
Dataset
This dataset, ATIS Airline Travel Information System, is a standard benchmark dataset widely used as an intent classification, where intent can be defined as a airline customer’s intent when typing in a question or comment. You can learn more about the dataset here.
df.head() Output: query 0 which airlines fly from boston to washington ... 1 show me the airlines that fly between toronto... 2 show me round trip first class tickets from n... 3 i'd like the lowest fare from denver to pitts... 4 show me a list of ground transportation at bo...
Model Choices
For this experiment, we will analyze 3 models:
OpenAI’s Ada v2 Embeddings model
CohereAI’s Embedding endpoint
Sentence Transformers (open source)
For the open source model we will be using the Sentence Transformers library provided by huggingface to generate our embeddings. We will go with sentence-transformers/all-MiniLM-L6-v2 model, which has about 2.4M downloads on the hub. Or, you can pick from the many other models available here. One thing to note about this is that by default, input text longer than 256 word pieces is truncated.
Experiment Overview
The experiment goes as follows:
Sample a fraction of the dataset, i.e, 25%.
Load the embeddings model from cohere-ai, openai, huggingface and embed the dataset.
Reduce the the dimensionality using PCA to 10, visualize, and then reduce it further to 2.
Perform clustering (2 regions) on a sample of 9 datapoints, visualize and report results across models
Perform classification using an SVM classifier over the whole 25% of the dataset, and report results across models.
Results
Clustering across Models
From left to right: CohereAI, OpenAIHuggingFace Sentence Transformer
When it comes to clustering, we can see from the above results, that the three models output similar clusters, with each model being successful in separating ground transportation to airline queries. However, OpenAI’s embedding model seems to have 3 clusters which seem to capture the data seperation between our 3 classes more perfectly compared to Cohere and the open source model. Nonetheless, it is quite evident that one can go with an open source model with on-par performance to the closed models in the market. There is also the added benefit that we can fine-tune these open source models on our own datasets to perform even better, all the while having full control of how you use your data.
In terms of Classification, all three models performed equally with accuracy around 97%, with the open source model showing a percentage point improvement across all metrics.
What this report goes on to show us that we can achieve similar results when it comes to closed and open ended word embeddings models. On a baseline, all three models did well but one thing to note is that, in this experiment, we saw a decrease in accuracy from 100% to 97% when we changed the sample size. So, it is worthy to note that this experiment isn’t conclusive until we run our experiment on a larger dataset. These results nonetheless should be a great start to considering open source models for organizations that want more control over their data. But one question still remains: How much would it cost us to deploy our own open source embeddings model?
Cost Analysis
We can find the pricing of OpenAI and Cohere which are charged based on the number of tokens embedded.
So, how do we calculate how many tokens we are processing?
This article from OpenAI gives us a general understanding of how to calculate the number of tokens. Here’s a summary:
• 1 token ~= 4 chars in English • 1 token ~= ¾ words • 100 tokens ~= 75 words
models = ['openai', 'cohere-default', 'cohere-custom'] costs = [] for model in models: costs.append(costOfEmbedding(model, 256)*10000) import matplotlib.pyplot as plt import seaborn as sns
plt.figure(figsize=(10,8)) sns.barplot(x=models, y=costs) for i, cost in enumerate(costs): plt.annotate(f' ${cost}', (i, cost), textcoords="offset points", xytext=(0,10), ha='center') plt.title("Cost of Embedding 10,000 documents with 256 words in average") plt.show()
Measuring costs associated with Open Source Models
While closed form models have a pricing catalog, which details how we are charged for embedding per token, with our open source model we need to think about the cost of hosting these models on the cloud.
There are two ways to think about this:
We embed 10,000 document once and store it in a vector database for retrieval. This is a one time process with the assumption we will not need to process future documents.
We not only embed 10,000 documents, but also build a pipeline to embed future documents as they come in. This process assumes that we will own our own embeddings endpoint as a service internally within the organization.
Hosting transformer models on the cloud comes with its fair share of challenges, with the major challenge being the size of these models. Recent transformer models such as Llama2, GPTJ, Falcon-180B, etc are measured in billions of parameters that occupy over 20GB+ memory at the very least. On top of size, these models require advanced GPUs to perform vector calculation. For instance, Google Colab provides us a Nvidia T4 GPU with about 16GB memory, and it is not even sufficient to load up Llama2’s smallest 7B parameter model without some form of quantization tricks. Therefore, when it comes to deploying your own open sourced AI agents internally it becomes paramount to consider whether the costs associated with running these models are worth it. To give you an example, consider this chart below based on AWS Sagemaker pricing:
You can find all the instance pricing here. For Llama2 according to Meta, “The largest model, however, will require very powerful hardware like an A100 80GB.” One thing is quite obvious- the cost of running these transformer models are pretty high compared to just using services from OpenAI or Cohere, where they bare these costs by enjoying economies of scale, or worse losing money (but that will be a discussion for another blog).
Luckily for us though, our open source embedding model is a fairly small model that can be run on a bare metal CPU. To understand the memory utilization of this model, we can reference this great tool by HuggingFace to get an approximation. According to their findings, he minimum recommended vRAM needed for a model is denoted as the size of the “largest layer”, and training of a model is roughly 4x its size (for Adam). When performing inference, expect to add up to an additional 20% to this as found by EleutherAI.
To calculate our vRam requirements, we see that our model is backed by a BERT base model, which is known to have 413.18MB with the largest layer consisting of 84.95MB.
Min vRam Required: 84.95 MB vRam required for inference: 101.94 MB vRam required for training/finetuning: 339.8 MB
As mentioned earlier, luckily our sentence transformer is a small transformer model, so we can use the ml.t2.medium instance type to host our model, which is charged at $0.056 per hour. Assuming, we only embed the first 10,000 documents, we can approximate, in the worst case, that the whole process will take us 2 hours. The whole process could finish up much faster but I could not test this out since I do not 10,000 documents to embed (the dataset used in this example only contains 1000 queries); therefore, let’s just assume it takes us 2hours and plot our results.
What’s interesting about the visualization above is the fact that, for our open source model, the cost is not directly proportional to the number of tokens. Even though the processing time will depend on the number of documents that need to be embedded, the point to be made about this example is that we could’ve embedded about 20,000 documents with the same cost. With 1000 examples or lower, we might not even need to run the embedding process for more than 10mins, which would mean we’ll end up paying close to nothing.
Furthermore, with the cost of open source model already substantially below those of OpenAI and Cohere, we can take it a step further. Since we also want our embeddings model to embed future models, we can leverage AWS Sagemaker’s Serverless Inference. This documentation should be a great guide for the following assesment. With Serverless Inference, you only pay for the compute capacity used to process inference requests, billed by the millisecond, and the amount of data processed.
You can choose a Serverless Inference endpoint memory size from 1024 MB (1 GB) up to 6144 MB (6 GB), of which we decided to use only 4GB. Although I am not calculating the costs associated with running our embedding model on serverless inference (we can do this for a future post), we can still get an understanding by closely following the example provided with the DistilBERT example, which is model half the size of the BERT model used in our embedding model.
So we can implicitly make the conclusion that the cost of running a serverless endpoint will be cheaper compared the other closed source models out there. It is also important to note that the serverless inference will not work for transformer models such as the Llama2 as they require GPUs and much higher memory requirements, which the serverless solution doesn’t currently support.
Conclusion
To sum it all up, in this experiment, we have went from using closed source models from OpenAI and Cohere, and compared both performance and costs with its open sourced counterpart. For organizations that are considering having more control over their data, an open source model could be a great option.
However, I do want to point out some limitations about the open source model:
The sentence transformer used here can only process input sentences of length 256 word, whereas the OpenAI and Cohere model is limited to the token limit of around 2000–4000 tokens. However, this can be mitigated by exploring this code block to use models that can handle larger input sequences. However, this could also in fact increase the model size, which might not be suitable for Serverless Inference.
The transformative power of AI is poised to reshape the business landscape in unprecedented ways. With the continuous emergence of new AI models and resources at an unprecedented pace, organizations are facing both a wealth of opportunities and a challenging terrain to navigate. To thrive in this evolving landscape, businesses will require individuals who possess a deep understanding of the diverse options available, ranging from open source to closed source solutions, like we did today. As AI continues to advance, those who can adeptly harness its capabilities will not only ensure their success but also shape the future of their industries. The journey ahead demands adaptability, expertise, and a commitment to embracing the ever-changing world of AI, where innovation is the key to sustainable growth and competitiveness.
]]>Tracking Prices on Amazon: A Serverless Approach2023-06-15T00:11:04+00:002023-06-15T00:11:04+00:00https://farhan0167.github.io/blog/2023/tracking-prices-on-amazon-a-serverless-approach
So here’s the problem statement- you are on Amazon and notice this pair of AirPods Pro selling at a 12% discount from list price, and you wonder whether you could snatch a higher discount. You want to track the price change over time, and want to be notified when the price drops by a certain threshold. You also don’t just want to run a script manually everyday; instead you want a system that runs in the background and notifies you of these changes.
I’ve been studying for the AWS Solutions Architect Associates exam for the past month, and I thought of solving this problem by picking up on the materials I’ve touched throughout that journey. This article is not about how to build a React application or about a walkthrough on scrapping. This article is about how I use different AWS resources and combine them together.
A Simple Architecture
To achieve our goal, we need 3 essential tools:
A Frontend for the clients to interact with the system
A compute engine or backend to scrape a given link from Amazon, and
A database to store all the tracking information
We can visualize this architecture to look as follows:
The frontend is built using React, and I integrate AWS Amplify to utilize Amplify’s user authentication feature. The React application is then deployed on Amazon S3. Amazon S3 is AWS’s proprietary object storage platform, and while we are aware of using it as a place to store files, images, logs, etc. we can also leverage S3’s web hosting feature to host static built websites.
With a frontend in place, we now need to interact with the backend. For this application, we want users to be able to track 3 items and be able to monitor price changes daily by logging into the frontend. To achieve this, we can utilize an EC2 instance, which hosts a Flask application that provides the client 2 endpoints- one to get items, and the other to post items.
For the AirPods, I would post the link of the product to the Flask endpoint, and the Flask application will scrape the given link for the price, and store it in DynamoDB. Once stored in the database, users can simply use the get-items endpoint to see their tracked items. And then for every day after an item was posted, the Flask application will run a process to re-scrape price information on a daily interval, and match price changes against the target price users have set- if the price drops to target, the Flask application will notify the users.
This architecture would serve us well but this can become quite expensive to run. EC2 instances are charged based on the instance type, RAM, storage, etc, per hour. For instance, if we run this on a an instance type t3.medium it will cost us $ 0.052/Hour, and could cost us an upward of $ 37.96/Month. This is expensive, and the costs could balloon up as we add more users and possibly more instance to distribute load. It’s not sustainable to pay this much for a service that will perform functions like get/store items, and run a 1 time scraping job at 9am in the morning. We can do better.
A Cost Optimized Serverless Architecture
The main idea here is to leverage the AWS Serverless approach. AWS Serverless is a cloud computing model that allows us to build and deploy applications without worrying about server management. It offers scalability, cost-effectiveness, and rapid deployment, making it an ideal choice for our use case. And most importantly, we will only be charged for every time the system is used, as opposed to on a per hour basis.
System Breakdown
The system is broken into 4 different Lambda functions, with each of these functions doing a specific task. The client interacts with AWS API Gateway, which replaces the Flask endpoints- store and get items. At the very basic level, the get-items endpoint queries Lambda function-3 that queries the DynamoDB table for all the tracking items that belong to the user.
Initially, I only had one Lambda function, the Lambda function-1, in place to handle this endpoint. This function takes in the url and scrapes that particular link using the ScrapingBee API, to get the price and product name and store it in DynamoDB. However, I ran into a timeout issue. It turned out that the API Gateway has a 29s timeout window whereas the Lambda function would take about a minute to to finish scraping. So in 29s the API Gateway would timeout and send an error code back to the client, while the Lambda function would successfully execute in 1 minute and store the item in the database.
And that’s why I introduce the SNS module, a service that provides message delivery from publishers to subscribers. So we decouple the application by moving the Lambda function-1 to Lambda function-2, and have Lambda function-1, process the API request and publish the scraping job to SNS. Lambda-function-1 can now simply return the same message it received back to the client, so that the client is able to see that the items to track is there.
This implementation introduced a new challenge. With the decoupling in place, whenever a client puts in a request to store an item, the first lambda function would respond with the tracking details of the product which the client could render. However, since that item takes about 2minutes-5minutes to process by the other lambda function, the database still isn’t aware of this new item. Therefore, the minute the client refreshes their browser, the new item disappears. To solve this issue, I leverage caching. When the first lambda responds, I immediately store all the items data on the client’s local storage with a timeout of 5–15 minutes. This would allow the client to see their newly put item and after 15minutes, they would start seeing the item from the database all the while the idea of database store is abstracted away. This also enables us to reduce the load on the AWS services in the backend with caching.
The EventBridge Scheduler
With items readily available in DynamoDB, we can now implement an EventBridge scheduler to trigger an event daily to invoke Lambda function-4 to: extract all the urls available in the table, scrape the price for that day, and compare it against the original price. Currently, the function determines whether the price extracted on a given day the scheduler runs is the target price the customer has set. If there’s a match, we can utilize another SNS module to utilize Amazon Simple Email Service to email users to notify them of it.
The new prices are appended in the following way in the priceCh` array:
With this priceCh array, the frontend can now visualize price change over time(last item in array is the current day price)that looks like this:
Closing Remarks
I’m still working on this project to finish up a few issues and future directions this can take, which could be summarized as:
Instead of checking whether current price equals target price, we can implement a target window, where users are notified when the price drops to within a 5% range of the target price.
We can enable a feature that customers can select when posting an item to track, wherein when a price drops to target range, we authorize Stripe to make payments towards buying it directly instead of having to do it manually.
Thanks for sticking it out till the end. If you enjoyed reading about this system design walkthrough please drop in a like to show your support. And I’m also open to receiving feedback on how this could have been done differently.
]]>Adversarial Attacks on CNN2023-06-14T14:21:06+00:002023-06-14T14:21:06+00:00https://farhan0167.github.io/blog/2023/adversarial-attacks-on-cnnCan Deep Neural Networks misclassify? How this simple idea of adversarial attack on CNN is now being used as a Defense against generative AI
I recently came across this article, where a group of University of Chicago researchers are creating The Glaze Project which aims to prevent the use of artist’s work to train generative AI models like Stable Diffusion. Generative AI has exploded in popularity over the last year, especially since the launch of LensaAI, Dall-E and other generative AI models that produce art from text prompts. Concerns over these apps started appearing in the news following their rise in popularity, and a divide emerged between one party arguing why it was not a copyrights issue and the other arguing why it was.
I don’t wan’t to talk about any of that but about the Glaze Project. Last semester, I took a Cybersecurity class in Machine Learning, where we were introduced to the idea of Sign based gradient descent attacks. Put simply, given an image, attackers can modify the image using gradient methods to perturb the image such that a AI algorithm would misclassify. The catch is, to the human eye, you would see no reason to believe the model’s prediction because to the human eye the picture looks just fine.
In a more technical sense, here is an example of what I mean by a gradient based attack:
Here, starting with the image of a panda, the attacker adds small perturbations (distortions) to the original image, which results in the model labelling this image as a gibbon, with high confidence.
For those of us who’s worked with Deep Neural Networks aka AI models, what we are really trying to do is minimizing some loss function with respect to an input. In a gradient based attack, what we want to do is maximize that loss. We can do this by finding how much each pixel in the image is contributing to the loss function and compute the sign of the gradient. And then we’ll take the image and add a small epsilon to the gradient, resulting in a image that is perturbed.
So how does it effect Generative AI models?
Since generative models rely on advances in convolutional neural networks, on a very high level your text prompt of “generate an image of a panda” will be fed into some CNN model that knows what a panda looks like. But if we apply the gradient based attack on our images, what supposedly looks like panda to us, looks like a gibbon to AI. Therefore when an outsider will scrape this image of what looks like a panda, they’ll in fact train their models to construct a gibbon. While this is a over simplification, the idea of this gradient based attack has seen many iterations over the past years and there are better attacks to fool neural networks. You can read more about the technical details of the UChicago work here
And without further talk, I want to demonstrate the idea of a gradient based attack we learnt in class so you can get a hands on for what I just discussed.
import tensorflow as tf import matplotlib as mpl import matplotlib.pyplot as plt
# Helper function to preprocess the image so that it can be inputted in model def preprocess(image): image = tf.cast(image, tf.float32) image = tf.image.resize(image, (299, 299)) image = tf.keras.applications.mobilenet_v2.preprocess_input(image) image = image[None, ...] return image
# Helper function to extract labels from probability vector def get_imagenet_label(probs): return decode_predictions(probs, top=1)[0][0]
Original image
#you can insert any image from the web to play around: url = "https://www.ontheblufflabradors.com/wp-content/uploads/2021/02/25B182D2-3801-4E6E-8EB0-51D8B3B0C59D-1000x1000.jpeg" response = requests.get(url) img = Image.open(BytesIO(response.content)).convert('RGB')
The first step is to create perturbations which will be used to distort the original image resulting in an adversarial image. As mentioned, for this task, the gradients are taken with respect to the image.
def create_adversarial_pattern(input_image, input_label): with tf.GradientTape() as tape: tape.watch(input_image) prediction = pretrained_model(input_image) loss = loss_object(input_label, prediction)
# Get the gradients of the loss w.r.t to the input image. gradient = tape.gradient(loss, input_image) # Get the sign of the gradients to create the perturbation signed_grad = tf.sign(gradient) return signed_grad
The resulting perturbations can also be visualised.
# Get the input label of the image. You can find them here: https://gist.github.com/yrevar/942d3a0ac09ec9e5eb3a target_index = 270 #270 is a 'white wolf, Arctic wolf, Canis lupus tundrarum' label = tf.one_hot(target_index, image_probs.shape[-1]) label = tf.reshape(label, (1, image_probs.shape[-1]))
perturbations = create_adversarial_pattern(image, label) plt.imshow(perturbations[0] * 0.5 + 0.5); # To change [-1, 1] to [0,1]
Let’s try this out for different values of epsilon and observe the resultant image. You’ll notice that as the value of epsilon is increased, it becomes easier to fool the network. However, this comes as a trade-off which results in the perturbations becoming more identifiable.
As you can see, by adding the perturbation, and image which still looks like a Labrador is being classified as ice bear and star fish depending on the value of epsilon. While in this example, one can visibly note that the image has been altered, recent progress in this space has produced perturbation that is invisible to the naked eye.
Iterative Fast Gradient Sign Method
We can take our fast gradient sign method and extend it a bit further by mounting an iterative fast gradient sign attack. The idea is simple, we do exactly what we did previously but this time we take small values of epsilon and repeat the process some n number of times. This allows us to use small epsilon values instead of large values used in the previous method, i.e epsilons = [0,0.44, 0.6]
def IFGSM(img,label, alph, step_size): #convert input image dtype to tensor
adv_x = img #repeat the create_adversarial_pattern step_size amount of times for step in range(step_size): signed_grad = create_adversarial_pattern(adv_x, label) adv_x = adv_x + alph*signed_grad adv_x = tf.clip_by_value(adv_x,-1,1) return adv_x
#lets use smaller values of epsilon to see how we are doing epsilons = [ 0.345, 0.358,0.369] descriptions = [('Alpha = {:0.3f}'.format(eps)) for eps in epsilons]
for i, eps in enumerate(epsilons): adv_x_ifgsm = IFGSM(image,label, eps,2) display_images(adv_x_ifgsm, descriptions[i])
It’s funny to see how the model see’s a football helmet and shower cap because as far as I see, I see a dog.
To conclude, when we came across this in class, this was introduced to us as an attack on AI models, and we learnt about ways we can defend from these attacks. The field has evolved a lot since the fast gradient method was introduced but it was interesting to see that methodologies like these are being used to defend.
