[{"content":"Started reading The Anthropologists1 a while ago. It follows two foreigners looking for an apartment, envisioning their future in a city that isn\u0026rsquo;t theirs. Everything fell into place as I went through it.\nThe city has shaped them. With people around them they find comfort and a sense of home. Far from their parents, language and culture.\nThe Anthropologists But just imagine our own parents, he said. Imagine our hometowns where everyone is in everyone\u0026rsquo;s business. What would it be like for an auntie to say she\u0026rsquo;s setting boundaries and please don\u0026rsquo;t rely on her for family meals from now on?\nThe auntie uprising! Manu said.\nGood for her, I said. But I could see Ravi\u0026rsquo;s point.\nAnd I secretly hoped those aunties would remain as they were, protecting an ancient order.\nEven though you feel free of all the obligations, you don\u0026rsquo;t want them to change, as they are what reminds you of home. I felt this sense of uneasiness while reading, it was too familiar or relatable. However much you consider it your own, it\u0026rsquo;ll keep reminding you otherwise. It\u0026rsquo;s the mundane in our daily life which keeps us alive. The local tea shop you go to, the small talk you make with the cleaning lady. What you long for is familiarity and a sense of self, you want to believe that there is a world where you are not just a foreigner. You can’t be a native to a place you were not born or brought up in.\nFor last few years I’ve lived life on default mode. A new place and an older me might have more control or a newer form of naïveté. To look at my life in a newer fashion. There would be a lot of things to reminisce and much more to look forward to.\nI haven’t completed the book, neither have moved yet. I’m looking forward to good things in both worlds.\nCame across this book in some article, and it snowballed into me thinking about all this. Basically it didn\u0026rsquo;t hit me until I was in the book.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://abritpal.github.io/posts/between-cities/","summary":"\u003cp\u003eStarted reading \u003ca href=\"https://www.goodreads.com/en/book/show/195391751-the-anthropologists\"\u003eThe Anthropologists\u003c/a\u003e\u003csup id=\"fnref:1\"\u003e\u003ca href=\"#fn:1\" class=\"footnote-ref\" role=\"doc-noteref\"\u003e1\u003c/a\u003e\u003c/sup\u003e a while ago. It follows two foreigners looking for an apartment, envisioning their future in a city that isn\u0026rsquo;t theirs. Everything fell into place as I went through it.\u003c/p\u003e\n\u003cp\u003eThe city has shaped them. With people around them they find comfort and a sense of home. Far from their parents, language and culture.\u003c/p\u003e\n\u003cblockquote class=\"callout callout-quote\"\u003e\n  \u003cp class=\"callout-title\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 24 24\" fill=\"none\"\n         stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\"\n         stroke-linejoin=\"round\" aria-hidden=\"true\"\u003e\n      \u003cpath d=\"M16 3a2 2 0 0 0-2 2v6a2 2 0 0 0 2 2h1a1 1 0 0 1 1 1v1a2 2 0 0 1-2 2 1 1 0 0 0-1 1v2a1 1 0 0 0 1 1 6 6 0 0 0 6-6V5a2 2 0 0 0-2-2zM5 3a2 2 0 0 0-2 2v6a2 2 0 0 0 2 2h1a1 1 0 0 1 1 1v1a2 2 0 0 1-2 2 1 1 0 0 0-1 1v2a1 1 0 0 0 1 1 6 6 0 0 0 6-6V5a2 2 0 0 0-2-2z\" /\u003e\n    \u003c/svg\u003e\u003cspan\u003eThe Anthropologists\u003c/span\u003e\n  \u003c/p\u003e","title":"Between Cities"},{"content":"I\u0026rsquo;m Abrit, an ML Engineer based in Chennai. I build and ship end-to-end ML systems — from model training and fine-tuning with PyTorch and DeepSpeed to production deployment on AWS. My work spans speech/NLP, Gen-AI applications, and large action models.\nI\u0026rsquo;m strong in Infrastructure as Code (CloudFormation, CI/CD pipelines, VPC networking) and care about making ML reproducible, scalable, and cost-efficient. I co-authored a paper with IIT Madras on textless NLP and recently gave a talk on Agentic RAG in Edge Applications.\nCurrently a Machine Learning Engineer at Toyota Connected India.\nElsewhere GitHub · LinkedIn · X · abritpal@gmail.com\n","permalink":"https://abritpal.github.io/about/","summary":"About Abrit Pal Singh","title":"About"},{"content":"This post is based on a talk I gave at Techceleration in October 2025.\nBuilding RAG pipelines in the cloud has become almost routine. Spin up a vector database, wire it to an LLM API, and you’ve a working system by lunch. For most applications, that’s the right call, the cloud gives you the biggest models, effortless scaling, and a mature tooling ecosystem.\nBut it is not always the best choice. Some applications can’t send data off-device, can’t assume a network connection, or can’t absorb the per-call cost at scale. And so often, a region outage is a pointed reminder that “someone else’s computer” is a dependency.\nA familiar feeling for anyone who’s lived through a cloud region outage though, to be clear, edge isn’t a fix for outages so much as a different set of tradeoffs.\nThat’s what I set out to explore in my talk and in this write-up: not whether edge-RAG should replace cloud RAG, but what it actually takes to run agentic RAG on-device: local models, local retrieval, local tool execution and how to tell when that’s the right architecture for the job.\nHere’s a walkthrough of the key ideas:\nWhy Edge-RAG? The instinct to keep everything in the cloud is understandable. Cloud infrastructure is mature, scaling is someone else’s problem, and you get access to the most powerful models available. But there are four compelling reasons to consider moving your RAG pipeline to the edge.\nThe four pillars driving the case for edge-RAG. (Source: Author)\nZero cloud transmission is the first and perhaps most obvious benefit. When your data never leaves the device, you eliminate transmission costs entirely. For applications processing sensitive documents at scale, this adds up fast.\nBuilt-in compliance follows naturally. Regulations like HIPAA and GDPR impose strict requirements on where data can travel and be processed. An on-device pipeline is compliant by design, there’s no data in transit to worry about.\nEnhanced security is the third benefit. When inference and retrieval happen on-device, you eliminate whole class of network-based attacks: there are no API keys to leak, no man-in-the-middle interception of inference calls, and no sensitive data sitting in someone else’s cloud storage waiting to be breached.\nAnd finally, offline capability. In many real-world scenarios such as field operations, areas with unreliable connectivity, or simply situations where you can’t depend on a stable internet connection. An edge-RAG system continues to work without missing a beat.\nThe Tradeoffs Edge-RAG has its own limitations. Moving your pipeline on-device means working within real hardware constraints: limited RAM, weaker GPUs (or none at all), and smaller models that can’t match the reasoning depth of their cloud counterparts. You’re trading raw capability for privacy, latency, and independence. The key is knowing when that trade makes sense and when it doesn’t, which is why the decision framework later in this post matters. Edge-RAG works best when you design for the constraints rather than trying to work around them.\nIn edge deployments, I’ve hit a hard wall trying to accelerate weight tensors on the Hexagon HTP NPU, the DSP’s 32-bit address space caps you at ~2GB per session, so larger models silently fall back to CPU. The QNN HTP backend also rejects most quantized formats, accepting only F16/F32. These are the kind of constraints that you only discover after you’ve already committed to a hardware platform.\nUnderstanding Edge-RAG When I say “edge-RAG,” I’m really describing a spectrum with two main approaches.\nTwo approaches to edge-RAG: fully local vs. hybrid. (Source: Author)\nThe fully local approach puts everything on-device: the language model, the vector store, the embedding model, the agentic reasoning layer, all of it runs locally. This gives you maximum privacy and offline capability, but you’re constrained by the device’s compute and memory.\nThe hybrid approach keeps the agent and retrieval logic on-device while selectively offloading certain components to the cloud. Maybe your embedding model runs locally but complex reasoning tasks get routed to a cloud LLM when connectivity is available. This gives you a middle ground.\nThe Components A complete edge-RAG system has several moving parts.\nThe building blocks of an edge-RAG system. (Source: Author)\nThere’s the language model itself (typically a small language model, or SLM), a local vector store for your embeddings, an agentic layer that handles reasoning and decision-making, and a local tool and system integration layer that lets the agent interact with device capabilities: things like opening apps, toggling settings, or querying local APIs.\nThe agentic layer decides what to do. It selects which tool to call, plans multi-step sequences (e.g., “first open Maps, then search for this address, then start navigation”) and handles error recovery when a step fails. This system can reason, plan and also act. Without it, you just have a retrieval pipeline.\nSupporting these are a context manager / memory buffer for maintaining conversation state, a runtime and optimization layer to squeeze maximum performance out of limited hardware, and optionally a cloud-fallback layer for the hybrid approach.\nThe Flow Simplified flow: from user query to response, all on-device. (Source: Author)\nThe simplified pipeline works like this:\na user query comes in, gets embeddings locally, which is used to retrieve relevant context from the local vector store the retrieved context and the query feed into the agent’s reasoning step, where the on-device LLM decides what to do. It might answer directly or call a local tool, or plan a sequence of actions. finally, the response is generated and local memory is updated. This is a conceptual flow, not an implementation blueprint. I’ve collapsed some steps for readability (a full system like MobileRAG, for instance, separates planning/app-selection from action execution, and adds loops this linear view doesn’t show).\nHow the Demo Works: MobileRAG in Action\nTo make this concrete, I demo-ed a MobileRAG implementation running on Android. MobileRAG is a good example of what edge-agentic-RAG looks like in practice: it uses three types of retrieval working together:\nMobileRAG architecture: MemRAG, InterRAG, and LocalRAG working together to execute a multi-step task on-device. (Source: Loo et al., “MobileRAG: Enhancing Mobile Agent with Retrieval-Augmented Generation”)\nMemRAG stores the agent’s past trajectories such as:\nwhat apps it opened, what actions it took, and what worked. When a new task comes in, the agent checks this memory first. Think of it as muscle memory: if the agent has done something similar before, it recalls the playbook rather than figuring it out from scratch.\nInterRAG handles the cases where the agent doesn’t know something like which app to use. In the diagram, the user asks to add “The Boys” Season 3 to a watchlist. The agent doesn’t know which streaming platform carries the show, so InterRAG searches the web to figure out it’s a Prime Video exclusive. This is the “thinking” step.\nLocalRAG is the on-device knowledge base of installed apps and their capabilities.\nThe agent checks LocalRAG to see if Prime Video is already installed, and if not, plans to download it After completing the task, LocalRAG updates itself automatically, so next time, the agent already knows the path. These three components chain together into a seamless multi-step execution:\nIdentify the right app -\u0026gt; Open it -\u0026gt; Navigate the UI -\u0026gt; Complete the task -\u0026gt; Update local knowledge.\nMy demonstration used two of them, MemRAG and LocalRAG.\nMemRAG pulls the recorded steps for a known task, and LocalRAG identifies which installed app handles it and launches it, after which the task runs to completion. Simple tasks like “search IIT Madras on Google Maps” and “turn on Bluetooth” were processed entirely on-device, with the agentic layer translating natural language intent into system level actions.\nLive demo: natural language commands driving device actions through on-device agentic RAG. (Source: Author)\nBuilding Edge-RAG: Tools and Resources If you’re looking to actually build this, the ecosystem has matured quite a bit.\nKey tools and frameworks for building edge-RAG systems (Source: Author)\nFor the backend layer, Google’s MediaPipe Framework provides a solid foundation for building on-device ML pipelines with pre-built components for common tasks. For runtime and inference, LiteRT Community (previously TFLite) remains a strong choice. For testing, the AI Edge Portal gives you a platform to benchmark and validate your edge models, and if you want an open-source end-to-end solution, IREE.dev is worth exploring. It’s a compiler and runtime stack that can target everything from mobile GPUs to embedded accelerators. When to Use What Not every scenario calls for edge-RAG. Here’s a practical decision framework:\nMatching your use case to the right RAG architecture. (Source: Author)\nIf you need privacy with a small knowledge base, go with fully on-device agentic RAG. If your knowledge base is large but privacy is still critical, a hybrid approach with a local agent and selective cloud retrieval makes sense. For multi-source, complex reasoning tasks, cloud agentic RAG is still the best bet. For offline or cost-sensitive scenarios with simpler queries, standard on-device RAG works well. And when quality and speed are the top priorities, cloud agentic RAG remains the gold standard. Migrating from Cloud to Edge If you’ve already built a cloud RAG pipeline and the decision framework above points you toward the edge, the good news is you won’t be starting over. The building blocks are same, which gives us a good base to modify our architecture for edge.\nWhat transfers cleanly: Your retrieval logic, prompt structure, and the agentic loop itself (reason → retrieve → act → respond) are all portable. A query still gets embedded, context still gets retrieved, and the agent still decides what to do. If you’ve designed your prompts and tool interfaces well, most of that thinking carries over directly.\nWhat needs rework: The hard part is that the assumptions are baked into a cloud deployment.\nIn cloud, memory is effectively infinite, the model is whatever API you point at, and latency is dominated by the network round-trip.\nOn edge, all three flip. You’ll need to swap your frontier model for an SLM and validate that it still handles your tasks (see Strategy 1), replace your managed vector DB with a lightweight local store, and budget real engineering time for the runtime and optimization layer: quantization, caching, and the hardware-specific quirks I mentioned earlier.\nThe components that have no cloud equivalent are on-device tool integrations. The optimization layer are where most of the migration effort actually goes.\nThe honest answer, on difficulty:\nPorting the happy path is often a weekend-task. Getting it fast and reliable on real hardware is where the weeks go. Teams assuming the migration is a model swap is a mistake, when it’s really a re-architecture around constraints and one must plan for the second one.\nOptimizing for the Edge Running RAG on constrained hardware means you can’t afford to be wasteful. I covered four optimization strategies in the talk.\nFour key strategies for optimizing edge-RAG performance. (Source: Author)\nStrategy 1: SLMs Over LLMs The core insight here is that you don’t need a 70B-parameter model for most agentic tasks. Small Language Models (SLMs) in the 1.5B to 8B range are 10-30x cheaper at inference, can be fine-tuned in a few GPU-hours rather than weeks, and are perfectly sufficient for specialized, repetitive tasks like tool calls, formatting, and pattern matching.\nGeneralist versatility vs. specialist precision: LLMs are the jack of all trades, SLMs are the master of one. (Source: Author)\nThink of it as generalist versatility vs. specialist precision. LLMs are the jack of all trades; SLMs are the master of one. For edge agentic workflows, you want the specialist.\nA great example of this in practice is Smolagents from Hugging Face. Using SmolVLM2–2.2B-Instruct as a base model, fine-tuned on the AGUVIS datasets, you can build a capable GUI automation agent in just 2.2B parameters. The model takes a UI screenshot and an instruction, reasons about previous action history, and outputs precise click coordinates, all running on-device.\nSmolagents: a 2.2B parameter model performing GUI automation with step-by-step reasoning. (Source: Hugging Face : SmolVLM2–2.2B-Instruct-Agentic-GUI)\nStrategy 2: Lightweight Retrieval with MiniRAG Traditional vector similarity search can be computationally expensive on edge devices. MiniRAG takes a different approach by using heterogeneous graph indexing combined with lightweight graph-based knowledge retrieval.\nMiniRAG: heterogeneous graph indexing with topology-enhanced retrieval. (Source: Fan et al., “MiniRAG: Towards Extremely Simple Retrieval-Augmented Generation”)\nInstead of relying purely on dense embeddings, MiniRAG builds a graph with chunk nodes and entity nodes connected by entity-entity and entity-chunk edges. At query time, it performs semantic mapping to identify relevant entity types, then uses topology-enhanced graph retrieval to find the most relevant nodes and edges. This structured approach compensates for the limitations of smaller models and provides better reasoning paths with less compute.\nWhat makes this a good fit for the edge is that workload is shifted from the SLM to the connected graph. Dense retrieval depends on how well the embedding model understands meaning, which is exactly where small models struggle. Graph retrieval instead leans on the structure of the graph, so finding the right information becomes a matter of following links between connected nodes rather than relying on the model to infer meaning.\nStrategy 3: On-Demand Embeddings Here’s a practical insight: you don’t need all your embeddings stored and ready to go at all times. The EdgeRAG approach uses a two-level index: large clusters with embeddings that take more than 500ms to generate are cached, while smaller, frequently accessed embeddings are generated on-demand at runtime.\nEdgeRAG’s two-level retrieval: cache large clusters, generate small embeddings on demand. (Source: Seemakhupt et al., “EdgeRAG: Online-Indexed RAG for Edge Devices”)\nThe result:\nUp to 75% reduction in storage requirements while maintaining retrieval speed. The system uses a first-level index to quickly identify relevant clusters, checks an embedding cache, and only generates fresh embeddings when there’s a cache miss.\nStrategy 4: KV Cache Optimization KV (Key-Value) caching is a well-known technique for speeding up autoregressive generation in transformers. On edge devices, the key optimization is in how you manage that cache given limited memory.\nKV caching: store once, reuse across generation steps. (Source: Hugging Face : KV Caching Explained)\nThe approach involves offloading the KV cache to CPU RAM rather than keeping it in GPU memory, using a sliding window mechanism to keep the working set small, and applying delta encoding to reduce the cache’s memory footprint. This frees up precious GPU memory for the model itself and enables longer context windows without running into memory constraints.\nBonus: Cache Architecture Matters as Much as Caching: For multimodal agents, a single cache layer isn’t enough. You need a stack, an input-level cache that deduplicates near-identical inputs (a camera frame where nothing meaningful changed, an audio clip with the same content, a document where only metadata differs), an embedding cache that avoids re-running the encoder on byte-identical inputs, and the KV-cache for the LLM forward pass itself. Each layer protects the one below it: if the input-level cache misses, the embedding cache misses, which means new tokens in the prompt, which means the KV cache misses too. The optimization story is how the caches compose.\nThings to Keep in Mind If I had to distill the talk into a single summary:\nThe five focus areas for practical edge-RAG deployment\nThat last row is perhaps the most important takeaway. The temptation with edge AI is to try to replicate the full sophistication of a cloud pipeline. Instead, accept the constraints upfront, keep your agentic steps simple and decomposed, and prioritize practical deployment over architectural elegance. Complexity that works beautifully in the cloud will break on constrained hardware.\nWrapping Up Edge-RAG is no longer a theoretical exercise. The tools are available. The models are small enough, and the optimization techniques are mature enough to build real, useful agentic systems that run entirely on-device. The effort needed is to understand if the use case demands migration to Edge-RAG.\nFor most applications, the cloud is still the right answer, and that’s fine. But when privacy, compliance, offline capability, or cost at scale move from “nice to have” to “non-negotiable,” edge-RAG goes from an interesting experiment to the obvious choice. Which simply forces one to think what components belong to edge.\nUpdate: What’s Changed Since October 2025 The edge AI landscape has moved fast since this talk. The core thesis still holds, but a few specifics deserve an update.\nSmall models have leapfrogged. Gemma 4 (April 2026) shipped E2B and E4B variants designed explicitly for on-device deployment. Phi-4 added a vision-reasoning variant that decides for itself when to use chain-of-thought. Qwen3 brought in dual-mode reasoning down to the 8B tier. The SLM-over-LLM argument has a lot more evidence behind it than it did when I gave the talk.\nSpeculative decoding is the optimization I should have covered. Using a tiny draft model to predict multiple tokens ahead and verifying them in parallel with the main model has become the dominant inference optimization for edge devices. If I were giving the talk today, it would be Strategy 5.\nThe real bottleneck turned out to be memory bandwidth, not compute. On edge devices, generating each token requires streaming the full model weights through memory. TOPS gets all the marketing attention, but it’s memory bandwidth that determines actual decode speed which reframes how you think about quantization and model selection.\nEverything else: the four pillars, the decision framework, the “keep it simple” principle still holds. If anything, the improving capability of small models makes the case for edge-RAG stronger today than it was seven months ago.\nReferences and Further Reading Small Language Models are the Future of Agentic AI Google AI Edge MobileRAG: Enhancing Mobile Agent with Retrieval-Augmented Generation MiniRAG: Towards Extremely Simple Retrieval-Augmented Generation EdgeRAG: Online-Indexed RAG for Edge Devices KV Caching Explained: Optimizing Transformer Inference Efficiency Bonus Read: Less is More: Recursive Reasoning with Tiny Networks\n","permalink":"https://abritpal.github.io/posts/agentic-rag-in-edge-applications/","summary":"On-Device LLMs, RAG, and the Tools to Make It All Happen","title":"Agentic RAG in Edge Applications"},{"content":"ML Engineer with 3+ years of experience in edge AI deployment, LLM-based agentic systems, and speech processing. Currently focused on on-device LLM deployment and GUI automation for automotive head units on Qualcomm hardware.\nGitHub · LinkedIn · X · abritpal@gmail.com\nExperience Machine Learning Engineer — Toyota Connected India July 2022 – Present · Chennai, Tamil Nadu\nOptimized an on-device multimodal GUI agent (VLM + text LLM via llama.cpp) for an 8-core ARM64 automotive SoC with no usable GPU — recompiled with ARM DOTPROD int8 + KleidiAI kernels for a 6.4× gain in prompt-eval throughput (18→115 tok/s), targeting the compute-bound prefill phase. Designed a multi-layer caching architecture — perceptual screen-similarity cache, content-hashed embedding cache, and KV prefix-cache reuse — cutting end-to-end step latency from ~53s cold to ~7s warm (7–8×) on repeated/looped tasks, with ~95% prompt-token reuse on cache hits. Evaluated integrated GPU offload and rejected it after benchmarking (~2.5× slower than CPU due to shared-RAM SVM and per-kernel dispatch overhead for single-token decode) — kept inference CPU-only and fully local, with no cloud dependency. Packaged the agent as a single statically-linked ARM64 binary (PyInstaller, cross-compiled via Docker buildx/QEMU) with mixed 8/5/4-bit quantization across both models, enabling offline deployment with no Python runtime on-device. Designed and implemented a POC for LAM (Large Action Model) on Android devices for Automation Testing and Computer Use, using Sonnet 3.5 and GPT-4o. Finetuned LLAMA/OpenCUA-7B for Computer Use tasks. Designed a graph-based UI navigation system for LAM using structured JSON scene representations and BFS traversal for generating action trajectories on automotive head units. Built the retrieval and response pipeline for an internal AI-powered chat application (ChatGPT-like interface, data privacy within a VPC), and refactored a Gen-AI app to support multiple LLMs with token-cost estimation. Built a translation application that processes and maintains formatting across PowerPoint, Excel, PDF, and image-based documents. Developed VQ-VAE based models for Acoustic Unit Discovery in end-to-end speech systems, cutting training time 60% with One-Cycle/Warmup LR schedulers; refactored evaluation toolkits (ABX Discriminability, Phoneme Prediction/PER). Paper preprint with IIT Madras: Textless NLP – Zero Resource Challenge with Low Resource Compute. Own CI/CD and IaC pipelines for production environments on AWS. Software Developer — Blod.in July 2020 – July 2021 · Chennai\nBuilt the front-end of a health-tech web application using React.js and Firebase. Worked closely with the back-end team on API integration and contributed to UI/UX decisions.\nFrontend Developer — Freelance Feb 2020 – May 2020\nDesigned and developed the front-end of a student assignment-help platform with React, building screens for tutor and student workflows.\nResearch \u0026amp; Open Source Cohere Aya Expedition — Multilingual LLM Safety Research 2025\nInterpretability research on Tiny Aya (3.35B): replicated and extended Zhao et al. (2025) across six languages — 85% → 11% refusal collapse on template removal, cross-lingual SAE refusal features (AUC 0.93); built the layer-wise type-alignment analysis module.\nPublications Textless NLP – Zero Resource Challenge with Low Resource Compute. arXiv. With IIT Madras. Agent Enhancement using Deep RL Algorithms for Multiplayer Game (Slither.io). Journal. Humor and Offense Detection and Classification using ColBERT Embeddings. ACL Anthology. Humor Detection and Funniness Score Prediction using Deep Learning Techniques. Academia.edu. Talks October 2025, talk about \u0026ldquo;Agentic RAG in Edge Applications\u0026rdquo; at Techceleration #23: Let\u0026rsquo;s Talk Tech, Toyota Connected India. Watch on YouTube.\nSkills Area Tools and frameworks ML/AI Deep Learning, LLMs, Model Quantization, Edge AI Deployment, VQ-VAE, AutoEncoders, Speech Technologies, PyTorch, DeepSpeed, Hugging Face Transformers Cloud \u0026amp; Infra AWS (EC2, Lambda, VPC, CloudFormation, RDS, CodeBuild), GCP, Docker Languages \u0026amp; Tools Python, Git, Qualcomm AI Stack (QNN/Genie SDK), llama.cpp Education Institution Qualification Year SSN College of Engineering BE Computer Science and Engineering June 2022 Tyndale Biscoe School Higher Secondary 2018 ","permalink":"https://abritpal.github.io/cv/","summary":"Experience, research, publications, talks, skills, and education.","title":"Abrit Pal Singh"}]