Stay Updated with Our Latest Blogs
Subscribe to our blog and get the latest insurance tips, guides, and industry updates delivered to your inbox
Subscribe to our blog and get the latest insurance tips, guides, and industry updates delivered to your inbox
KshemaGPT is Kshema General Insurance's AI assistant built to make insurance simple, fast, and useful for farmers, individuals, and businesses. Designed with crop-insurance knowledge and practical policy guidance, KshemaGPT helps users understand PMFBY and other crop schemes, check policy features, explore parametric options, and get clear next steps — all in plain English. This introduction explains what KshemaGPT does, who it helps (especially farmers), and how you can use it to get quick, accurate insurance information.
KshemaGPT is a modular, multi-agent AI system designed to support Indian farmers with crop insurance, weather insights, and region-specific farming advice. Built on open-source models and fine-tuned for rural needs, it’s transforming how farmers access support.
What KshemaGPT is: an AI assistant trained on Kshema insurance products and crop-insurance (PMFBY) rules.
Who benefits most: farmers, agents, and customers looking for fast answers on crop, health, motor, fire, and surety bond insurance.
Quick actions you can take: get eligibility checks, claim guidance, policy comparisons, and contact/next-step recommendations.
Limitations: not a substitute for official policy documents; for binding quotes or final claim decisions, contact Kshema support.
Answer-first takeaway: Use KshemaGPT for fast, accurate guidance on PMFBY and crop insurance queries, basic product comparisons, and practical steps to file claims or buy policies online.
AI is more than just a buzzword. It is a transformative technology that can change lives. At Kshema, we recognise the potential of AI and we are harnessing it to
What began as an internal experiment to experience and assess the question answering capabilities on a crop policy document, later became a full-scale multi-agent LLM stack built on top of multiple open-source tools. The current version of KshemaGPT can address various questions about Kshema’s crop insurance policies — Prakriti, Sukriti, Samriddhi, policy status , crop specific suggestions, etc. KshemaGPT can also offer both preventive and prescriptive suggestions regarding potential localised calamities.
KshemaGPT leverages a multi-agent framework to handle different aspects of agricultural assistance. Each agent is designed for a specific function, ensuring modularity, efficiency, and scalability.
Initially, we started with a simple tool-calling architecture where the tools were:
However, as we added more tools like User Data Agent, Crop Agent, and Climate Agent, the tool-calling approach became inefficient. This led us to switch to a hierarchy-based routing mechanism. Now, the first level of routing directs queries to one of the following:
Further routing is handled within each of these components, which is explained in their respective sections.
KshemaGPT leverages a multi-agent framework to handle different aspects of agricultural assistance. Each agent is designed for a specific function, ensuring modularity, efficiency, and scalability.
Initially, we started with a simple tool-calling architecture where the tools were:
However, as we added more tools like User Data Agent, Crop Agent, and Climate Agent, the tool-calling approach became inefficient. This led us to switch to a hierarchy-based routing mechanism. Now, the first level of routing directs queries to one of the following:
Further routing is handled within each of these components, which is explained in their respective sections.
We call it the “Supervisor”. This agent leverages Qwen-2.5 model, which we fine-tuned on a tool calling dataset. This enables the supervisor to efficiently classify and determine which of the four primary agents should handle an incoming query. The hierarchical approach has significantly improved efficiency and accuracy, ensuring that each request is routed to the most relevant module for further processing.
The RAG Agent enhances KshemaGPT’s responses by retrieving relevant information from a curated knowledge base before generating answers. Initially, we placed all policy documents into a single collection within the Vector DB. This approach worked well when we had a limited number of documents, but as the collection grew, we started noticing a serious issue — mis retrieval. Many policy documents share common terms, leading the system to retrieve information from the wrong policies.
To fix this, we took a structured approach:
To determine which collection to retrieve from, we leveraged the tool-calling capability of Llama 3.1. Each collection is presented as a tool, and the model selects the most appropriate one based on the query. If none of the tools are called, we provide a predefined response such as, "Sorry, I do not have information to answer the question".
This approach ensures accurate retrieval and prevents the model from generating misleading responses due to incorrect document selection. With this restructuring, retrieval precision has drastically increased, reducing errors and making policy guidance far more reliable.
Parsing PDF files accurately is one of the most underrated yet critical components of building a high-quality RAG system. Policy documents, crop reports, government guidelines — most of them come in the form of PDFs. And PDFs are rarely simple. They often include complex layouts, headers and footers, background watermarks, multi-column formatting, tables, and embedded images.
We began with popular libraries like PyPDF, which worked well for clean text-based PDFs. But it quickly showed its limitations when handling more structured documents. We moved to PyMuPDF, which gave us more structured outputs like JSON and Markdown. Then we tried LLM-Sherpa, a rule-based system that specialises in identifying sections, sub-sections, and tables. This got us closer to usable structured data but still fell short when documents were less consistent.
The real bottleneck came when we encountered scanned PDFs — files that were essentially images of text. None of our earlier tools could parse these, so, we experimented with Optical Character Recognition (OCR)-based solutions. Our first pick was Qwen-2VL, an OCR model capable of generating Markdown output. It was promising but came with trade-offs: going beyond HD image resolution made it painfully slow, while reducing resolution led to poor parsing quality.
Eventually, we landed on GOT-OCR-2.0, a pruned and fine-tuned variant of Qwen-2VL. It struck the perfect balance — accurate OCR, robust layout detection — and it produced LaTeX outputs that preserved document structure exceptionally well. GOT-OCR-2.0 also excelled in extracting tables, headings, and sections, making it the most production-ready solution we tested.
In short, the PDF Parsing Agent had to evolve from being a simple text extractor to a sophisticated document understanding module. It’s the foundation that enables the RAG Agent to retrieve truly meaningful information.
Chunking plays a critical role in the success of any RAG system. It determines how large documents are split into manageable and meaningful segments for embedding and retrieval.
In the early stages, when we used text-based parsing tools like PyPDF, PyMuPDF, and LLM-Sherpa, we tried several chunking strategies:
Each had its limitations — either by breaking up semantically-related content or by producing overly long/short segments.
Once we moved to OCR-based PDF parsing, we were no longer dealing with plain text. We had to chunk either Markdown or LaTeX outputs, which required a different strategy altogether.
When we finally settled on GOT-OCR -2.0 for parsing, we adopted a simple rule-based approach: chunking LaTeX at section-level boundaries. While this meant that some chunks could be large, it worked well for our use case. Policy documents are usually structured with clear section headings, and keeping each section intact ensures that semantic coherence is preserved.
This approach has proven both scalable and effective in practice, giving the RAG system high-quality inputs that translate into better retrieval and generation.
We call it the “Supervisor”. This agent leverages Qwen-2.5 model, which we fine-tuned on a tool calling dataset. This enables the supervisor to efficiently classify and determine which of the four primary agents should handle an incoming query. The hierarchical approach has significantly improved efficiency and accuracy, ensuring that each request is routed to the most relevant module for further processing.
The RAG Agent enhances KshemaGPT’s responses by retrieving relevant information from a curated knowledge base before generating answers. Initially, we placed all policy documents into a single collection within the Vector DB. This approach worked well when we had a limited number of documents, but as the collection grew, we started noticing a serious issue — mis retrieval. Many policy documents share common terms, leading the system to retrieve information from the wrong policies.
To fix this, we took a structured approach:
To determine which collection to retrieve from, we leveraged the tool-calling capability of Llama 3.1. Each collection is presented as a tool, and the model selects the most appropriate one based on the query. If none of the tools are called, we provide a predefined response such as, "Sorry, I do not have information to answer the question".
This approach ensures accurate retrieval and prevents the model from generating misleading responses due to incorrect document selection. With this restructuring, retrieval precision has drastically increased, reducing errors and making policy guidance far more reliable.
Parsing PDF files accurately is one of the most underrated yet critical components of building a high-quality RAG system. Policy documents, crop reports, government guidelines — most of them come in the form of PDFs. And PDFs are rarely simple. They often include complex layouts, headers and footers, background watermarks, multi-column formatting, tables, and embedded images.
We began with popular libraries like PyPDF, which worked well for clean text-based PDFs. But it quickly showed its limitations when handling more structured documents. We moved to PyMuPDF, which gave us more structured outputs like JSON and Markdown. Then we tried LLM-Sherpa, a rule-based system that specialises in identifying sections, sub-sections, and tables. This got us closer to usable structured data but still fell short when documents were less consistent.
The real bottleneck came when we encountered scanned PDFs — files that were essentially images of text. None of our earlier tools could parse these, so, we experimented with Optical Character Recognition (OCR)-based solutions. Our first pick was Qwen-2VL, an OCR model capable of generating Markdown output. It was promising but came with trade-offs: going beyond HD image resolution made it painfully slow, while reducing resolution led to poor parsing quality.
Eventually, we landed on GOT-OCR-2.0, a pruned and fine-tuned variant of Qwen-2VL. It struck the perfect balance — accurate OCR, robust layout detection — and it produced LaTeX outputs that preserved document structure exceptionally well. GOT-OCR-2.0 also excelled in extracting tables, headings, and sections, making it the most production-ready solution we tested.
In short, the PDF Parsing Agent had to evolve from being a simple text extractor to a sophisticated document understanding module. It’s the foundation that enables the RAG Agent to retrieve truly meaningful information.
Chunking plays a critical role in the success of any RAG system. It determines how large documents are split into manageable and meaningful segments for embedding and retrieval.
In the early stages, when we used text-based parsing tools like PyPDF, PyMuPDF, and LLM-Sherpa, we tried several chunking strategies:
Each had its limitations — either by breaking up semantically-related content or by producing overly long/short segments.
Once we moved to OCR-based PDF parsing, we were no longer dealing with plain text. We had to chunk either Markdown or LaTeX outputs, which required a different strategy altogether.
When we finally settled on GOT-OCR -2.0 for parsing, we adopted a simple rule-based approach: chunking LaTeX at section-level boundaries. While this meant that some chunks could be large, it worked well for our use case. Policy documents are usually structured with clear section headings, and keeping each section intact ensures that semantic coherence is preserved.
This approach has proven both scalable and effective in practice, giving the RAG system high-quality inputs that translate into better retrieval and generation.
A RAG system is incomplete without a solid Vector DB for storing and retrieving vector embeddings. When we started, we faced the classic dilemma: Which Vector DB to choose? There were numerous options, both open-source and proprietary, each with its strengths and limitations.
Our first pick was Chroma DB, mainly because of its simplicity. It was easy to set up and integrate, and we had our first version up and running in no time. However, as our dataset grew and queries became more complex, we hit two major roadblocks — persistence and scalability. Since Chroma DB is an in-memory database, it struggled with handling large datasets efficiently. Restarting the service meant losing embeddings, which was unacceptable.
We then switched to Milvus, which is arguably the most performant open-source Vector DB available today. Milvus is GPU-accelerated, supports distributed deployments, and is built specifically for large-scale vector search. It provided both the persistence and scalability we needed for a production-grade RAG system. It also integrates well with other open-source tools in the AI ecosystem.
We were using mxbai-embed-large as our embedding model when working with Chroma. It worked decently for smaller datasets but didn’t scale well as our document collection expanded. When we transitioned to Milvus, we also decided to experiment with the more sophisticated embedding model BAAI/bge-m3. The new model provided richer embeddings, leading to better retrieval accuracy.
To further refine the search results, we introduced the reranking model BAAI/bge-reranker-v2-m3, which helped us retrieve the most relevant top-k results. The reranking step significantly improved answer precision.
With Milvus, query latency dropped, retrieval quality improved, and the system became more robust. Looking back, while Chroma DB was an excellent starting point, Milvus, combined with a powerful embedding and reranking pipeline, has been the key to making KshemaGPT scalable and future-proof.
KshemaGPT is an AI-driven conversational assistant built to explain Kshema’s insurance products, with a strong focus on crop insurance (including PMFBY) and parametric offerings. It helps answer common customer questions, outlines policy features, and suggests next steps. KshemaGPT does not provide binding quotes or make final claim adjudications.
KshemaGPT is an AI-driven conversational assistant built to explain Kshema’s insurance products, with a strong focus on crop insurance (including PMFBY) and parametric offerings. It helps answer common customer questions, outlines policy features, and suggests next steps. KshemaGPT does not provide binding quotes or make final claim adjudications.
Farmers can ask KshemaGPT whether their crop and location are eligible under PMFBY or Kshema’s parametric insurance products. The assistant also explains the documents typically required for enrollment.
KshemaGPT provides step-by-step guidance for filing crop insurance claims, including typical documentation such as yield or area records, digital photographs, and expected timelines for inspections and payouts.
The assistant shares practical advice on record-keeping, early loss reporting, and how parametric triggers work, such as rainfall or NDVI-based thresholds.
KshemaGPT explains the differences between crop insurance, parametric insurance, and traditional indemnity covers, including trigger mechanisms, payout speed, and the best-fit user profile.
KshemaGPT summarizes premium-influencing factors and required inputs, and then directs users to Kshema’s digital purchase flow or an authorized agent for binding quotes.
Example prompt: “I farm 5 acres of paddy in [district]. Am I eligible for PMFBY and how do I enroll?” KshemaGPT responds with eligibility details, required documents, and enrollment steps.
Example prompt: “My crop was damaged by unseasonal rain. How do I file a PMFBY claim?” KshemaGPT provides a claim checklist and recommended next actions.
Example prompt: “Tell me about Kshema General Insurance careers.” KshemaGPT shares information on role types, application links, and company values.
KshemaGPT provides informational guidance and operational steps but does not issue binding policy documents or make final claim decisions. While it may reference PMFBY rules, official verification is always through policy documents and Kshema customer support.
Some responses may include AI-derived phrasing such as “I can only assist with PMFBY scheme & crop-insurance-related inquiries. This is an AI-generated response.” Users should always confirm critical details with Kshema’s official support channels.
KshemaGPT processes user inputs to provide relevant answers. Any personal data shared for quotes or claims follows Kshema’s privacy policy and is handled through secure submission channels.
KshemaGPT is available via the Kshema website chat, mobile application, and customer support portal. Insurance agents may also have access through dedicated internal tools.
For accurate responses, users should provide clear details such as crop type, land area, location, and date of loss when asking questions.
If you need a binding quote or to file a claim
When a binding quote or formal claim submission is required, KshemaGPT guides users to the appropriate human-assisted channels, including policy purchase pages or claim registration links.
Report inaccuracies
Users can flag incorrect or unclear responses through Kshema’s feedback or support mechanisms to help improve the accuracy and usefulness of KshemaGPT.
KshemaGPT explains the differences between crop insurance, parametric insurance, and traditional indemnity covers, including trigger mechanisms, payout speed, and the best-fit user profile.
KshemaGPT summarizes premium-influencing factors and required inputs, and then directs users to Kshema’s digital purchase flow or an authorized agent for binding quotes.
Example prompt: “I farm 5 acres of paddy in [district]. Am I eligible for PMFBY and how do I enroll?” KshemaGPT responds with eligibility details, required documents, and enrollment steps.
Example prompt: “My crop was damaged by unseasonal rain. How do I file a PMFBY claim?” KshemaGPT provides a claim checklist and recommended next actions.
Example prompt: “Tell me about Kshema General Insurance careers.” KshemaGPT shares information on role types, application links, and company values.
KshemaGPT provides informational guidance and operational steps but does not issue binding policy documents or make final claim decisions. While it may reference PMFBY rules, official verification is always through policy documents and Kshema customer support.
Some responses may include AI-derived phrasing such as “I can only assist with PMFBY scheme & crop-insurance-related inquiries. This is an AI-generated response.” Users should always confirm critical details with Kshema’s official support channels.
KshemaGPT processes user inputs to provide relevant answers. Any personal data shared for quotes or claims follows Kshema’s privacy policy and is handled through secure submission channels.
KshemaGPT is available via the Kshema website chat, mobile application, and customer support portal. Insurance agents may also have access through dedicated internal tools.
For accurate responses, users should provide clear details such as crop type, land area, location, and date of loss when asking questions.
If you need a binding quote or to file a claim
When a binding quote or formal claim submission is required, KshemaGPT guides users to the appropriate human-assisted channels, including policy purchase pages or claim registration links.
Report inaccuracies
Users can flag incorrect or unclear responses through Kshema’s feedback or support mechanisms to help improve the accuracy and usefulness of KshemaGPT.
Additional useful checklist (plain text):
KshemaGPT is a practical, farmer-focused AI assistant designed to make insurance information accessible and actionable — especially for crop insurance and PMFBY-related needs. Use it to get quick eligibility checks, claim guidance, and product comparisons; then follow its links or contact Kshema support to complete purchases or file formal claims. Try asking KshemaGPT a specific question about your crop, location, or loss now — and if you need a binding quote or claim resolution, reach out to Kshema customer support for the final step.
KshemaGPT is Kshema General Insurance’s AI assistant that provides farmers with quick guidance on PMFBY, crop and parametric insurance, claim steps, and enrollment requirements. It helps you check eligibility, assemble documents, and understand timelines though it does not replace official policy documents or final claim decisions.
No. KshemaGPT can estimate premiums and explain the factors that affect cost, but for a binding quote you must use the official Kshema quote/purchase flow or contact an authorized agent. KshemaGPT will guide you to that next step.
KshemaGPT functions like a focused farmer assistant for Kshema products — you can think of it as a 'Farmer GPT' for Kshema. It supports PMFBY-specific queries and crop-insurance-related questions and will provide scheme-specific guidance where applicable.
KshemaGPT’s answers are generated by AI and aim to be accurate and helpful, but they are informational. For critical matters like claim submission, policy wording, or payout disputes, always verify with Kshema’s official documentation or customer support before taking final action.
KshemaGPT explains how parametric triggers (like rainfall thresholds or NDVI indices) work, typical payout mechanics, and the advantages for quick disbursal. It can help determine whether a parametric product might be suitable based on your crop and location and direct you to Kshema’s parametric product details.
KshemaGPT is Kshema General Insurance’s AI assistant that provides farmers with quick guidance on PMFBY, crop and parametric insurance, claim steps, and enrollment requirements. It helps you check eligibility, assemble documents, and understand timelines though it does not replace official policy documents or final claim decisions.
No. KshemaGPT can estimate premiums and explain the factors that affect cost, but for a binding quote you must use the official Kshema quote/purchase flow or contact an authorized agent. KshemaGPT will guide you to that next step.
KshemaGPT functions like a focused farmer assistant for Kshema products — you can think of it as a 'Farmer GPT' for Kshema. It supports PMFBY-specific queries and crop-insurance-related questions and will provide scheme-specific guidance where applicable.
KshemaGPT’s answers are generated by AI and aim to be accurate and helpful, but they are informational. For critical matters like claim submission, policy wording, or payout disputes, always verify with Kshema’s official documentation or customer support before taking final action.
KshemaGPT explains how parametric triggers (like rainfall thresholds or NDVI indices) work, typical payout mechanics, and the advantages for quick disbursal. It can help determine whether a parametric product might be suitable based on your crop and location and direct you to Kshema’s parametric product details.
Wait for Part 2 to know more about KshemaGPT.
“We do not assume any liability for any actions undertaken based on the information provided here. The information gathered from various sources and are displayed here for general guidance and does not constitute any professional advice or warranty of any kind.”
We call it the “Supervisor”. This agent leverages Qwen-2.5 model, which we fine-tuned on a tool calling dataset. This enables the supervisor to efficiently classify and determine which of the four primary agents should handle an incoming query. The hierarchical approach has significantly improved efficiency and accuracy, ensuring that each request is routed to the most relevant module for further processing.
Crop Insurance
