Building a Nutrition RAG System with Chakudya Nutrition Registry

An exploration of Retrieval-Augmented Generation (RAG) and its implementation in Chakudya Nutrition Registry, including semantic retrieval, nutrition data sources, and the `/rag/retrieve` endpoint.

Building a Nutrition RAG System with Chakudya Nutrition Registry

Artificial intelligence is increasingly being used to work with large amounts of information. In nutrition, this can include food composition data, clinical guidelines, research literature, exchange lists, packaged foods, and other nutrition resources.

One approach for connecting this information with generative AI is Retrieval-Augmented Generation (RAG).

While developing Chakudya Nutrition Registry, I explored how RAG can be used to retrieve relevant nutrition knowledge and make it available to applications through an API.

What is RAG?

Retrieval-Augmented Generation, commonly known as RAG, is an approach that combines information retrieval with generative AI.

A typical RAG workflow involves retrieving information relevant to a user's query and then using that information as context for generating a response.

A simplified workflow looks like this:

User question
      ↓
Query processing
      ↓
Information retrieval
      ↓
Relevant knowledge
      ↓
Context
      ↓
AI generation
      ↓
Response

The retrieval and generation components can be implemented separately. This allows the knowledge layer to be maintained independently from the language model.

Why RAG for nutrition?

Nutrition information exists in many different formats and sources.

These may include:

• Food composition tables
• Clinical nutrition guidelines
• Research articles
• Diabetes exchange lists
• Renal exchange lists
• Enteral nutrition resources
• Packaged-food data
• Nutrition reference documents

A nutrition application may need to work with several of these sources at the same time.

Traditional database queries are useful when the structure of the data and the query are known. However, natural-language questions can be more difficult to handle with exact keyword matching alone.

For example:

What foods could be included when planning a meal for someone with diabetes?

The wording of the question may differ from the terminology used in the underlying knowledge.

Semantic retrieval provides another way of finding relevant information by considering the meaning of the query.

Chakudya Nutrition Registry

Chakudya Nutrition Registry is a food and nutrition data platform designed to provide nutrition information through APIs.

The registry brings together several types of nutrition resources, including:

• Malawi food composition data
• Diabetes exchange lists
• Renal exchange lists
• Enteral formula information
• Packaged foods
• External food data sources
• General nutrition textbooks and reference books
• Clinical nutrition guidelines Research articles and scientific literature
• Dietary references
• Nutrition assessment resources
• Therapeutic nutrition references

The platform provides structured endpoints for applications that need specific information.

For example, an application can query a food endpoint when it needs information about a particular food.

However, not every nutrition question can be represented as a simple food lookup.

This is where the RAG component provides another method of accessing the available knowledge.

The /rag/retrieve endpoint

One of the RAG components in Chakudya Nutrition Registry is:

POST /rag/retrieve

This endpoint provides semantic retrieval for nutrition knowledge.

A submitted query is converted into an embedding and compared with information stored in the RAG knowledge base.

Chakudya uses Cohere's embed-multilingual-v3.0 model for embeddings.

This allows the system to perform semantic similarity searches rather than relying only on exact keyword matches.

For example:

"foods suitable for diabetes"

and:

"foods that can be included in a diabetic meal plan"

use different wording but have closely related meanings.

Semantic retrieval can help identify information relevant to both queries.

How the retrieval process works

A simplified representation of the retrieval process is:

Nutrition documents
        ↓
Text extraction
        ↓
Document chunking
        ↓
Embeddings
        ↓
Vector storage
        ↓
User query
        ↓
Query embedding
        ↓
Similarity search
        ↓
Relevant information

Documents are processed into smaller sections so that relevant portions can be retrieved instead of providing an entire document as context.

The text is represented as embeddings and stored for semantic search.

When a query is submitted to /rag/retrieve, the query is embedded and used to identify relevant information from the knowledge base.

The endpoint can return retrieved context that can then be used by another application or AI workflow.

From retrieval to /rag/ask

Chakudya Nutrition Registry also includes a higher-level RAG endpoint:

POST /rag/ask

While /rag/retrieve focuses on semantic retrieval, /rag/ask acts as a broader RAG search orchestrator.

The workflow can include:

User query
     ↓
Intent detection
     ↓
Search across relevant sources
     ↓
Semantic retrieval
     ↓
Structured nutrition searches
     ↓
Reranking
     ↓
Context construction
     ↓
Grounded AI response

The search process can work across multiple nutrition data sources, including the Malawi Food Composition Table, packaged and OCR-derived foods, exchange lists, renal information, enteral formulas, barcode-related data, and external food-data fallbacks.

The retrieved results can then be reranked before being used to construct the context for the generated response.

Chakudya uses Cohere reranking for this part of the workflow, with a heuristic fallback available when required.

Retrieval and generation are separate components

An important part of the architecture is the separation between retrieval and generation.

The /rag/retrieve endpoint focuses on finding relevant information.

A separate application or AI workflow can then decide how that retrieved information should be used.

For example:

Application
     ↓
/rag/retrieve
     ↓
Relevant nutrition knowledge
     ↓
AI model
     ↓
Natural-language response

This means the retrieval layer does not have to be limited to a chatbot.

It can potentially be used by different types of nutrition software, including:

• Nutrition education applications
• Research tools
• Clinical software
• Nutrition search systems
• AI assistants
• Meal-planning applications

RAG and structured nutrition data

RAG does not replace structured nutrition databases.

The two approaches serve different purposes.

A structured food database can answer questions such as:

How much protein does this food contain?

A retrieval system can help find information related to a broader question such as:

What nutrition information is relevant to this dietary condition?

The two approaches can therefore work together.

Structured nutrition data
          +
Nutrition knowledge
          +
Semantic retrieval
          +
Artificial intelligence

This allows applications to use precise structured data when appropriate and semantic retrieval when a broader knowledge search is needed.

Nutrition data sources

One of the important aspects of a nutrition RAG system is the information available to retrieve.

Chakudya Nutrition Registry is designed around nutrition resources that can include local and external sources.

The system can work with information related to:

• Malawi Food Composition Table
• Diabetes exchange lists
• Renal exchange lists
• Enteral formulas
• Packaged foods
• OCR-derived food information
• Barcode-related food information
• External food databases

External sources can also be used as fallbacks in the wider food-search architecture, including USDA FoodData Central, Open Food Facts, and FatSecret.

This allows the system to combine locally relevant nutrition information with broader food-data coverage.

Why local nutrition data matters

Chakudya Nutrition Registry also focuses on nutrition data relevant to Malawi.

Many digital nutrition systems depend heavily on international datasets. These resources are useful, but local food composition data and dietary information can provide additional context for applications serving Malawian users.

A local nutrition data layer can make it easier for developers to build applications that work with foods and nutrition information relevant to the local population.

The RAG component provides another layer through which this knowledge can be accessed.

Source and context matter

Retrieval quality depends on the quality of the information being retrieved.

For a nutrition system, important considerations include:

• Reliability of the source
• Quality of document processing
• Quality of embeddings
• Retrieval relevance
• Metadata and source information
• Freshness of the underlying knowledge
• How retrieved information is presented to the AI model

RAG does not by itself guarantee that a generated response is correct.

The retrieved information still needs to come from appropriate sources, and generated responses may require validation depending on the application.

This is particularly important when developing systems that may be used in nutrition or healthcare contexts.

What I learned from building the system

Working on the RAG component highlighted several parts of AI application development that are easy to overlook.

The language model is only one part of the system.

Other components include:

Data
  ↓
Knowledge processing
  ↓
Indexing
  ↓
Retrieval
  ↓
Reranking
  ↓
Context construction
  ↓
AI generation
  ↓
Response

Each stage can affect the quality of the final result.

This approach also changes how an AI application can be designed. Instead of treating the language model as the entire system, it can be treated as one component within a larger information architecture.

The role of RAG in the wider Chakudya project

The RAG system is one part of the broader Chakudya Nutrition Registry architecture.

The registry provides both structured and knowledge-oriented access to nutrition information.

A simplified view is:

Food data
Exchange lists
Renal information
Enteral formulas
Packaged foods
Nutrition knowledge
        ↓
Chakudya Nutrition Registry
        ↓
Structured APIs + RAG
        ↓
Nutrition applications

Developers can therefore choose the appropriate interface depending on the type of information their application needs.

A structured endpoint may be appropriate for a precise food lookup.

The /rag/retrieve endpoint may be appropriate when searching for relevant knowledge based on a natural-language query.

The /rag/ask endpoint can provide a higher-level workflow that combines retrieval and response generation.

RAG query caching

Another part of the implementation is query caching.

The RAG retrieval process uses an embedding request before searching the knowledge base. Repeated or similar queries can therefore result in repeated processing.

Chakudya includes a Cloudflare KV-backed query cache for /rag/retrieve.

The cache can store complete retrieval responses for a limited period.

This can reduce repeated embedding requests and database searches for identical or normalized queries.

The result is an architecture that considers not only retrieval quality, but also performance and resource usage.

Looking ahead

The development of the RAG component is part of a broader effort to make nutrition data more accessible to software.

Future nutrition applications could combine:

• Local food composition data
• Clinical nutrition resources
• Research literature
• Semantic search
• Structured APIs
• Artificial intelligence

Such systems could support different areas of nutrition education, research and digital health.

The quality of these applications will depend not only on the AI model, but also on the quality, organization and provenance of the underlying nutrition information.

Conclusion

RAG provides an architecture for connecting generative AI with external knowledge sources.

In Chakudya Nutrition Registry, the /rag/retrieve endpoint provides a semantic retrieval layer that applications can use to find relevant nutrition information.

The /rag/ask endpoint builds on this retrieval capability by orchestrating searches across different nutrition sources, reranking results, and using the retrieved information as context for response generation.

This architecture allows structured food data, nutrition knowledge, semantic search, and AI to work together while keeping the retrieval layer separate from the language model.

Chakudya Nutrition Registry is an ongoing project exploring how food data, nutrition knowledge, APIs, semantic retrieval, and artificial intelligence can work together, with a particular focus on making locally relevant nutrition information accessible from Malawi and beyond.