Large language models (LLMs) are trained on massive textual data to generate creative and contextually relevant content. Since enterprises are utilizing LLMs to handle information effectively, they must understand the structure behind these powerful tools and the challenges associated with them.
One such component worthy of attention is the llm context window. It plays a crucial role in the development and evolution of LLM technology to enhance the way users interact with information.
In this blog, we will navigate the paradox around LLM context windows and explore possible solutions to overcome the challenges associated with large context windows. However, before we dig deeper into the topic, it’s essential to understand what LLM context windows are and their importance in the world of language models.
What are LLM context windows?
An LLM context window acts like a lens providing perspective to a large language model. The window keeps shifting to ensure a constant flow of information for an LLM as it engages with the user’s prompts and inputs. Thus, it becomes a short-term memory for LLMs to access when generating outputs.
A visual to explain context windows – Source: TechTarget
The functionality of a context window can be summarized through the following three aspects:
Focal word – Focuses on a particular word and the surrounding text, usually including a few nearby sentences in the data
Contextual information – Interprets the meaning and relationship between words to understand the context and provide relevant output for the users
Window size – Determines the amount of data and contextual information that is quickly accessible to the LLM when generating a response
Thus, context windows bae their function on the above aspects to assist LLMs in creating relevant and accurate outputs. These aspects also lay down a basis for the context window paradox that we aim to explore here.
What is the context window paradox?
It is a dilemma that revolves around the size of context windows. While it is only logical to expect large context windows to be beneficial, there are two sides to this argument.
Curious about the Curse of Dimensionality, Context Window Paradox, Lost in the Middle Problem in LLMs and more? Catch Jerry Liu, Co-founder and CEO of LlamaIndex, simplifying these complex topics for you.
Tune in to our podcast now!
Side One
It elaborates on the benefits of large context windows. With a wider lens, LLMs get access to more textual data and information. It enables an LLM to study more data, forming better connections between words and generating improved contextual information.
Thus, the LLM generates enhanced outputs with better understanding and a coherent flow of information. It also assists language models to handle complex tasks more efficiently.
Side Two
While larger windows give access to more contextual information, it also increases the amount of data for LLMs to process. It makes it challenging to identify useful knowledge from irrelevant details in large amounts of data, overwhelming LLMs at the cost of degraded performance.
Thus, it makes the size of LLM context windows a paradoxical matter where users have to look for the right trade-off between improved contextual information and the high performance of LLMs. It leads one to decide how much information is a good amount for an efficient LLM.
Before we elaborate further on the paradox, let’s understand the role and importance of context windows in LLMs.
Why do context windows matter in LLMs?
LLM context windows are important in ensuring the efficient working of LLMs. Their multifaceted role is described below.
Understanding language nuances
The focused perspective of context windows provides surrounding information in data, enabling LLMs to better understand the nuances of language. The model becomes trained to grasp the meaning and intent behind words. It empowers an LLM to perform the following tasks:
Machine translation
An LLM uses a context window to identify the nuances of language and contextual information to create the most appropriate translation. It caters to the understanding of context within an entire sentence or paragraph to ensure efficient machine translation.
Question answering
Understanding contextual information is crucial when answering questions. With relevant information on the situation and setting, it is easier to generate an informative answer. Using a context window, LLMs can identify the relevant parts of the conversation and avoid irrelevant tangents.
Coherent text generation
LLMs use context windows to generate text that aligns with the preceding information. By analyzing the context, the model can maintain coherence, tone, and overall theme in its response. This is important for tasks like:
Chatbots
Conversational engagement relies on a high level of coherence. It is particularly used in chatbots where the model remembers past interactions within a conversation. With the use of context windows, a chatbot can create a more natural and engaging conversation.
Here’s a step-by-step guide to building LLM chatbots.
Creative textual responses
LLMs can create creative content like poems, essays, and other texts. A context window allows an LLM to understand the desired style and theme from the given dataset to create creative responses that are more relevant and accurate.
Contextual learning
Context is a crucial element for LLMs which becomes more accessible with context windows. Analyzing the relevant data with a focus on words and text of interest allows an LLM to learn and adapt their responses. It becomes useful for uses like:
Virtual assistants
Virtual assistants are designed to help users in real-time. Context window enables the assistant to remember past requests and preferences to provide more personalized and helpful service.
Open-ended dialogues
In ongoing conversations, the context window allows the LLM to track the flow of the dialogue and tailor its responses accordingly.
Hence, context windows act as a lens through which LLMs view and interpret information. The size and effectiveness of this perspective significantly impact the LLM’s ability to understand and respond to language in a meaningful way. This brings us back to the size of a context window and the associated paradox.
The context window paradox: Is bigger, not better?
While a bigger context window ensures LLM’s access to more information and better details for contextual relevance, it comes at a cost. Let’s take a look at some of the drawbacks for LLMs that come with increasing the context window size.
Information overload
Too much information can overwhelm a language model just like humans. Too much text leads to an information overload that includes irrelevant information that can become a distraction for an LLM.
It makes it difficult for LLMs to focus on key knowledge aspects within the context, making it difficult to generate effective responses to queries. Moreover, a large textual dataset also requires more computational resources, resulting in more expense and slower LLM performance.
Getting lost in data
Even with a larger window for data access, an LLM can process limited information effectively. In a wider span of data, an LLM can focus on the edges. It results in LLMs prioritizing the data at the start and end of a window, missing out on important information in the middle.
Moreover, mismanaged truncation to fit a large window size can result in the loss of essential information. As a result, it can compromise the quality of the results produced by the LLM.
Poor information management
A wider LLM context window means a larger context that can lead to poor handling and management of information or data. With too much noise in the data, it becomes difficult for an LLM to differentiate between important and unimportant information.
It can create redundancy or contradictions in produced results, harming the credibility and efficiency of a large language model. Moreover, it creates a possibility for bias amplification, leading to misleading outputs.
Long-range dependencies
With a focus on concepts spread far apart in large context windows, it can become challenging for an LLM to understand relationships between words and concepts. It limits the LLM’s ability for tasks requiring historical analysis or cause-and-effect relationships.
Thus, large context windows offer advantages but with some limitations. The best approach is to find the right balance between context size, efficiency, and the specific task at hand is crucial for optimal LLM performance.
Techniques to address context window paradox
Let’s look at some techniques that can assist you in optimizing the use of large context windows. Each one explores ways to find the optimal balance between context size and LLM performance.
Prioritization and attention mechanisms
Attention mechanism techniques can be used to focus on crucial and most relevant information within a context window. Hence, an LLM does not have to deal with the entire flow of information and can only focus on the highlighted parts within the window, enhancing its overall performance.
Strategic truncation
Since all the information within a context window is not important or equally relevant, truncation can be used to strategically remove unrelated details. The core elements of the text needed for the task are preserved while the unnecessary information is removed, avoiding information overload on the LLM.
Retrieval augmented generation (RAG)
This technique integrates an LLM with a retrieval system containing a vast external knowledge base to find information specifically relevant to the current prompt and context window. This allows the LLM to access a wider range of information without being overwhelmed by a massive internal window.
Prompt engineering
It focuses on crafting clear instructions for the LLM to efficiently utilize the context window. Clear and focused prompts can guide the LLM toward relevant information within the context, enhancing the LLM’s efficiency in utilizing context windows.
Here’s a 10-step guide to becoming a prompt engineer
Optimizing training data
It is a useful practice to organize training data, creating well-defined sections, summaries, and clear topic shifts, helping the LLM learn to navigate larger contexts more effectively. The structured information makes it easier for an LLM to process data within the context window.
These techniques can help us address the context window paradox and leverage the benefits of larger context windows while mitigating their drawbacks.
The Future of Context Windows in LLMs
We have looked at the varying aspects of LLM context windows and the paradox involving their size. With the right approach, technique, and balance, it is possible to choose the optimal context window size for an LLM. Moreover, it also highlights the need to focus on the potential of context windows beyond the paradox around their size.
The future is expected to transition from cramming more information into a context window to ward smarter context utilization. Moreover, advancements in attention mechanisms and integration with external knowledge bases will also play a role, allowing LLMs to pinpoint truly relevant information regardless of window size.
Ultimately, the goal is for LLMs to become context masters, understanding not just the “what” but also the “why” within the information they process. This will pave the way for LLMs to tackle even more intricate tasks and generate responses that are both informative and human-like.
Large Language Models are growing smarter, transforming how we interact with technology. Yet, they stumble over a significant quality i.e. accuracy. Often, they provide unreliable information or guess answers to questions they don’t understand—guesses that can be completely wrong. Read more
This issue is a major concern for enterprises looking to leverage LLMs. How do we tackle this problem? Retrieval Augmented Generation (RAG) offers a viable solution, enabling LLMs to access up-to-date, relevant information, and significantly improving their responses.
Tune in to our podcast and dive deep into RAG, fine-tuning, LlamaIndex and LangChain in detail!
RAG is a framework that retrieves data from external sources and incorporates it into the LLM’s decision-making process. This allows the model to access real-time information and address knowledge gaps. The retrieved data is synthesized with the LLM’s internal training data to generate a response.
The challenge of bringing RAG based LLM applications to production
Prototyping a RAG application is easy, but making it performant, robust, and scalable to a large knowledge corpus is hard.
There are three important steps in a RAG framework i.e. Data Ingestion, Retrieval, and Generation. In this blog, we will be dissecting the challenges encountered based on each stage of the RAG pipeline specifically from the perspective of production, and then propose relevant solutions. Let’s dig in!
Stage 1: Data Ingestion Pipeline
The ingestion stage is a preparation step for building a RAG pipeline, similar to the data cleaning and preprocessing steps in a machine learning pipeline. Usually, the ingestion stage consists of the following steps:
Collect data
Chunk data
Generate vector embeddings of chunks
Store vector embeddings and chunks in a vector database
The efficiency and effectiveness of the data ingestion phase significantly influence the overall performance of the system.
Common Pain Points in Data Ingestion Pipeline
Challenge 1: Data Extraction:
Parsing Complex Data Structures: Extracting data from various types of documents, such as PDFs with embedded tables or images, can be challenging. These complex structures require specialized techniques to extract the relevant information accurately.
Handling Unstructured Data: Dealing with unstructured data, such as free-flowing text or natural language, can be difficult.
Proposed solutions
Better parsing techniques:Enhancing parsing techniques is key to solving the data extraction challenge in RAG-based LLM applications, enabling more accurate and efficient information extraction from complex data structures like PDFs with embedded tables or images. Llama Parse is a great tool by LlamaIndex that significantly improves data extraction for RAG systems by adeptly parsing complex documents into structured markdown.
Chain-of-the-table approach:The chain-of-table approach, as detailed by Wang et al., https://arxiv.org/abs/2401.04398 merges table analysis with step-by-step information extraction strategies. This technique aids in dissecting complex tables to pinpoint and extract specific data segments, enhancing tabular question-answering capabilities in RAG systems.
Mix-Self-Consistency:
Large Language Models (LLMs) can analyze tabular data through two primary methods:
Direct prompting for textual reasoning.
Program synthesis for symbolic reasoning, utilizing languages like Python or SQL.
According to the study “Rethinking Tabular Data Understanding with Large Language Models” by Liu and colleagues, LlamaIndex introduced the MixSelfConsistencyQueryEngine. This engine combines outcomes from both textual and symbolic analysis using a self-consistency approach, such as majority voting, to attain state-of-the-art (SoTA) results. Below is an example code snippet. For further information, visit LlamaIndex’s complete notebook.
Challenge 2: Picking the Right Chunk Size and Chunking Strategy:
Determining the Right Chunk Size: Finding the optimal chunk size for dividing documents into manageable parts is a challenge. Larger chunks may contain more relevant information but can reduce retrieval efficiency and increase processing time. Finding the optimal balance is crucial.
Defining Chunking Strategy: Deciding how to partition the data into chunks requires careful consideration. Depending on the use case, different strategies may be necessary, such as sentence-based or paragraph-based chunking.
Proposed Solutions:
Fine Tuning Embedding Models:
Fine-tuning embedding models plays a pivotal role in solving the chunking challenge in RAG pipelines, enhancing both the quality and relevance of contexts retrieved during ingestion.
By incorporating domain-specific knowledge and training on pertinent data, these models excel in preserving context, ensuring chunks maintain their original meaning.
This fine-tuning process aids in identifying the optimal chunk size, striking a balance between comprehensive context capture and efficiency, thus minimizing noise.
Additionally, it significantly curtails hallucinations—erroneous or irrelevant information generation—by honing the model’s ability to accurately identify and extract relevant chunks.
According to experiments conducted by Llama Index, fine-tuning your embedding model can lead to a 5–10% performance increase in retrieval evaluation metrics.
Use Case-Dependent Chunking
Use case-dependent chunking tailors the segmentation process to the specific needs and characteristics of the application. Different use cases may require different granularity in data segmentation:
Detailed Analysis: Some applications might benefit from very fine-grained chunks to extract detailed information from the data.
Broad Overview: Others might need larger chunks that provide a broader context, important for understanding general themes or summaries.
Embedding Model-Dependent Chunking
Embedding model-dependent chunking aligns the segmentation strategy with the characteristics of the underlying embedding model used in the RAG framework. Embedding models convert text into numerical representations, and their capacity to capture semantic information varies:
Model Capacity: Some models are better at understanding broader contexts, while others excel at capturing specific details. Chunk sizes can be adjusted to match what the model handles best.
Semantic Sensitivity: If the embedding model is highly sensitive to semantic nuances, smaller chunks may be beneficial to capture detailed semantics. Conversely, for models that excel at capturing broader contexts, larger chunks might be more appropriate.
Challenge 3: Creating a Robust and Scalable Pipeline:
One of the critical challenges in implementing RAG is creating a robust and scalable pipeline that can effectively handle a large volume of data and continuously index and store it in a vector database. This challenge is of utmost importance as it directly impacts the system’s ability to accommodate user demands and provide accurate, up-to-date information.
Proposed Solutions
Building a modular and distributed system:
To build a scalable pipeline for managing billions of text embeddings, a modular and distributed system is crucial. This system separates the pipeline into scalable units for targeted optimization and employs distributed processing for parallel operation efficiency. Horizontal scaling allows the system to expand with demand, supported by an optimized data ingestion process and a capable vector database for large-scale data storage and indexing.
This approach ensures scalability and technical robustness in handling vast amounts of text embeddings.
Stage 2: Retrieval
Retrieval in RAG involves the process of accessing and extracting information from authoritative external knowledge sources, such as databases, documents, and knowledge graphs. If the information is retrieved correctly in the right format, then the answers generated will be correct as well. However, you know the catch. Effective retrieval is a pain, and you can encounter several issues during this important stage.
Common Pain Points in Data Ingestion Pipeline
Challenge 1: Retrieved Data Not in Context
The RAG system can retrieve data that doesn’t qualify to bring relevant context to generate an accurate response. There can be several reasons for this.
Missed Top Rank Documents: The system sometimes doesn’t include essential documents that contain the answer in the top results returned by the system’s retrieval component.
Incorrect Specificity: Responses may not provide precise information or adequately address the specific context of the user’s query
Losing Relevant Context During Reranking: This occurs when documents containing the answer are retrieved from the database but fail to make it into the context for generating an answer.
Proposed Solutions:
Query Augmentation: Query augmentation enables RAG to retrieve information that is in context by enhancing the user queries with additional contextual details or modifying them to maximize relevancy. This involves improving the phrasing, adding company-specific context, and generating sub-questions that help contextualize and generate accurate responses
Rephrasing
Hypothetical document embeddings
Sub-queries
Tweak retrieval strategies:Llama Index offers a range of retrieval strategies, from basic to advanced, to ensure accurate retrieval in RAG pipelines. By exploring these strategies, developers can improve the system’s ability to incorporate relevant information into the context for generating accurate responses.
Small-to-big sentence window retrieval,
recursive retrieval
semantic similarity scoring.
Hyperparameter tuning for chunk size and similarity_top_k: This solution involves adjusting the parameters of the retrieval process in RAG models. More specifically, we can tune the parameters related to chunk size and similarity_top_k.
The chunk_size parameter determines the size of the text chunks used for retrieval, while similarity_top_k controls the number of similar chunks retrieved.
By experimenting with different values for these parameters, developers can find the optimal balance between computational efficiency and the quality of retrieved information.
Reranking: Reranking retrieval results before they are sent to the language model has proven to improve RAG systems’ performance significantly.
By retrieving more documents and using techniques like CohereRerank, which leverages a reranker to improve the ranking order of the retrieved documents, developers can ensure that the most relevant and accurate documents are considered for generating responses. This reranking process can be implemented by incorporating the reranker as a postprocessor in the RAG pipeline.
Challenge 2: Task-Based Retrieval
If you deploy a RAG-based service, you should expect anything from the users and you should not just limit your RAG in production applications to only be highly performant for question-answering tasks.
Users can ask a wide variety of questions. Naive RAG stacks can address queries about specific facts, such as details on a company’s Diversity & Inclusion efforts in 2023 or the narrator’s activities at Google.
However, questions may also seek summaries (“Provide a high-level overview of this document”) or comparisons (“Compare X and Y”).
Different retrieval methods may be necessary for these diverse use cases.
Proposed Solutions
Query Routing: This technique involves retaining the initial user query while identifying the appropriate subset of tools or sources that pertain to the query. By routing the query to the suitable options, routing ensures that the retrieval process is fine-tuned to the specific tools or sources that are most likely to yield accurate and relevant information.
Challenge 3: Optimize the Vector DB to look for correct documents
The problem in the retrieval stage of RAG is about ensuring the lookup to a vector database effectively retrieves accurate documents that are relevant to the user’s query.
Hereby, we must address the challenge of semantic matching by seeking documents and information that are not just keyword matches, but also conceptually aligned with the meaning embedded within the user query.
Proposed Solutions:
Hybrid Search:
Hybrid search tackles the challenge of optimal document lookup in vector databases. It combines semantic and keyword searches, ensuring retrieval of the most relevant documents.
Semantic Search: Goes beyond keywords, considering document meaning and context for accurate results.
Keyword Search: Excellent for queries with specific terms like product codes, jargon, or dates.
Hybrid search strikes a balance, offering a comprehensive and optimized retrieval process. Developers can further refine results by adjusting weighting between semantic and keyword search. This empowers vector databases to deliver highly relevant documents, streamlining document lookup.
Challenge 4: Chunking Large Datasets
When we put large amounts of data into a RAG-based product we eventually have to parse and then chunk the data because when we retrieve info – we can’t really retrieve a whole pdf – but different chunks of it.
However, this can present several pain points.
Loss of Context: One primary issue is the potential loss of context when breaking down large documents into smaller chunks. When documents are divided into smaller pieces, the nuances and connections between different sections of the document may be lost, leading to incomplete representations of the content.
Optimal Chunk Size: Determining the optimal chunk size becomes essential to balance capturing essential information without sacrificing speed. While larger chunks could capture more context, they introduce more noise and require additional processing time and computational costs. On the other hand, smaller chunks have less noise but may not fully capture the necessary context.
Document Hierarchies: This is a pre-processing step where you can organize data in a structured manner to improve information retrieval by locating the most relevant chunks of text.
Knowledge Graphs: Representing related data through graphs, enabling easy and quick retrieval of related information and reducing hallucinations in RAG systems.
Sub-document Summary: Breaking down documents into smaller chunks and injecting summaries to improve RAG retrieval performance by providing global context awareness.
Parent Document Retrieval: Retrieving summaries and parent documents in a recursive manner to improve information retrieval and response generation in RAG systems.
RAPTOR: RAPTOR recursively embeds, clusters, and summarizes text chunks to construct a tree structure with varying summarization levels. Read more
Recursive Retrieval: Retrieval of summaries and parent documents in multiple iterations to improve performance and provide context-specific information in RAG systems.
Challenge 5: Retrieving Outdated Content from the Database
Imagine a RAG app working perfectly for 100 documents. But what if a document gets updated? The app might still use the old info (stored as an “embedding”) and give you answers based on that, even though it’s wrong.
Proposed Solutions:
Meta-Data Filtering: It’s like a label that tells the app if a document is new or changed. This way, the app can always use the latest and greatest information.
Stage 3: Generation
While the quality of the response generated largely depends on how good the retrieval of information was, there still are tons of aspects you must consider. After all, the quality of the response and the time it takes to generate the response directly impacts the satisfaction of your user.
Challenge 1: Optimized Response Time for User
The prompt response to user queries is vital for maintaining user engagement and satisfaction.
Proposed Solutions:
Semantic Caching: Semantic caching addresses the challenge of optimizing response time by implementing a cache system to store and quickly retrieve pre-processed data and responses. It can be implemented at two key points in an RAG system to enhance speed:
Retrieval of Information: The first point where semantic caching can be implemented is in retrieving the information needed to construct the enriched prompt. This involves pre-processing and storing relevant data and knowledge sources that are frequently accessed by the RAG system.
Calling the LLM: By implementing a semantic cache system, the pre-processed data and responses from previous interactions can be stored. When similar queries are encountered, the system can quickly access these cached responses, leading to faster response generation.
Challenge 2: Inference Costs
The cost of inference for large language models (LLMs) is a major concern, especially when considering enterprise applications.
Some of the factors that contribute to the inference cost of LLMs include context window size, model size, and training data.
Proposed Solutions:
Minimum viable model for your use case: Not all LLMs are created equal. There are models specifically designed for tasks like question answering, code generation, or text summarization. Choosing an LLM with expertise in your desired area can lead to better results and potentially lower inference costs because the model is already optimized for that type of work.
Conservative Use of LLMs in Pipeline: By strategically deploying LLMs only in critical parts of the pipeline where their advanced capabilities are essential, you can minimize unnecessary computational expenditure. This selective use ensures that LLMs contribute value where they’re most needed, optimizing the balance between performance and cost.
Challenge 3: Data Security
The problem of data security in RAG systems refers to the concerns and challenges associated with ensuring the security and integrity of Language Models LLMs used in RAG applications. As LLMs become more powerful and widely used, there are ethical and privacy considerations that need to be addressed to protect sensitive information and prevent potential abuses.
These include:
Prompt injection
Sensitive information disclosure
Insecure outputs
Proposed Solutions:
Multi-tenancy: Multi-tenancy is like having separate, secure rooms for each user or group within a large language model system, ensuring that everyone’s data is private and safe.It makes sure that each user’s data is kept apart from others, protecting sensitive information from being seen or accessed by those who shouldn’t.By setting up specific permissions, it controls who can see or use certain data, keeping the wrong hands off of it. This setup not only keeps user information private and safe from misuse but also helps the LLM follow strict rules and guidelines about handling and protecting data.
NeMo Guardrails: NeMo Guardrails is an open-source security toolset designed specifically for language models, including large language models. It offers a wide range of programmable guardrails that can be customized to control and guide LLM inputs and outputs, ensuring secure and responsible usage in RAG systems.
Ensuring the Practical Success of the RAG Framework
This article explored key pain points associated with RAG systems, ranging from missing content and incomplete responses to data ingestion scalability and LLM security. For each pain point, we discussed potential solutions, highlighting various techniques and tools that developers can leverage to optimize RAG system performance and ensure accurate, reliable, and secure responses.
By addressing these challenges, RAG systems can unlock their full potential and become a powerful tool for enhancing the accuracy and effectiveness of LLMs across various applications.
While we provided a detailed guideline on understanding RAG and finetuning, a comparative analysis of the two provides a deeper insight. Let’s explore and address the RAG vs finetuning debate to determine the best tool to optimize LLM performance.
RAG vs finetuning LLM – A detailed comparison of the techniques
It’s crucial to grasp that these methodologies while targeting the enhancement of large language models (LLMs), operate under distinct paradigms. Recognizing their strengths and limitations is essential for effectively leveraging them in various AI applications.
This understanding allows developers and researchers to make informed decisions about which technique to employ based on the specific needs of their projects. Whether it’s adapting to dynamic information, customizing linguistic styles, managing data requirements, or ensuring domain-specific performance, each approach has its unique advantages.
By comprehensively understanding these differences, you’ll be equipped to choose the most suitable method—or a blend of both—to achieve your objectives in developing sophisticated, responsive, and accurate AI models.
Summarizing the RAG vs finetuning comparison
Team RAG or team Fine-Tuning? Tune in to this podcast now to find out their specific benefits, trade-offs, use-cases, enterprise adoption, and more!
Adaptability to dynamic information
RAG shines in environments where information is constantly updated. By design, RAG leverages external data sources to fetch the latest information, making it inherently adaptable to changes.
This quality ensures that responses generated by RAG-powered models remain accurate and relevant, a crucial advantage for applications like real-time news summarization or updating factual content.
Fine-tuning, in contrast, optimizes a model’s performance for specific tasks through targeted training on a curated dataset.
While it significantly enhances the model’s expertise in the chosen domain, its adaptability to new or evolving information is constrained. The model’s knowledge remains as current as its last training session, necessitating regular updates to maintain accuracy in rapidly changing fields.
Customization and linguistic style
RAG‘s primary focus is on enriching responses with accurate, up-to-date information retrieved from external databases.
This process, though excellent for fact-based accuracy, means RAG models might not tailor their linguistic style as closely to specific user preferences or nuanced domain-specific terminologies without integrating additional customization techniques.
Fine-tuning excels in personalizing the model to a high degree, allowing it to mimic specific linguistic styles, adhere to unique domain terminologies, and align with particular content tones.
This is achieved by training the model on a dataset meticulously prepared to reflect the desired characteristics, enabling the fine-tuned model to produce outputs that closely match the specified requirements.
Data efficiency and requirements
RAG operates by leveraging external datasets for retrieval, thus requiring a sophisticated setup to manage and query these vast data repositories efficiently.
The model’s effectiveness is directly tied to the quality and breadth of its connected databases, demanding rigorous data management but not necessarily a large volume of labeled training data.
Fine-tuning, however, depends on a substantial, well-curated dataset specific to the task at hand.
It requires less external data infrastructure compared to RAG but relies heavily on the availability of high-quality, domain-specific training data. This makes fine-tuning particularly effective in scenarios where detailed, task-specific performance is paramount and suitable training data is accessible.
Efficiency and scalability
RAG is generally considered cost-effective and efficient for a wide range of applications, particularly because it can dynamically access and utilize information from external sources without the need for continuous retraining.
This efficiency makes RAG a scalable solution for applications requiring access to the latest information or coverage across diverse topics.
Fine-tuning demands a significant investment in time and resources for the initial training phase, especially in preparing the domain-specific dataset and computational costs.
However, once fine-tuned, the model can operate with high efficiency within its specialized domain. The scalability of fine-tuning is more nuanced, as extending the model’s expertise to new domains requires additional rounds of fine-tuning with respective datasets.
RAG demonstrates exceptional versatility in handling queries across a wide range of domains by fetching relevant information from its external databases.
Its performance is notably robust in scenarios where access to wide-ranging or continuously updated information is critical for generating accurate responses.
Fine-tuning is the go-to approach for achieving unparalleled depth and precision within a specific domain.
By intensively training the model on targeted datasets, fine-tuning ensures the model’s outputs are not only accurate but deeply aligned with the domain’s subtleties, making it ideal for specialized applications requiring high expertise.
Hybrid approach: Enhancing LLMs with RAG and finetuning
The concept of a hybrid model that integrates Retrieval-Augmented Generation (RAG) with fine-tuning presents an interesting advancement. This approach allows for the contextual enrichment of LLM responses with up-to-date information while ensuring that outputs are tailored to the nuanced requirements of specific tasks.
Such a model can operate flexibly, serving as either a versatile, all-encompassing system or as an ensemble of specialized models, each optimized for particular use cases.
In practical applications, this could range from customer service chatbots that pull the latest policy details to enrich responses and then tailor these responses to individual user queries, to medical research assistants that retrieve the latest clinical data for accurate information dissemination, adjusted for layman understanding.
The hybrid model thus promises not only improved accuracy by grounding responses in factual, relevant data but also ensures that these responses are closely aligned with specific domain languages and terminologies.
However, this integration introduces complexities in model management, potentially higher computational demands, and the need for effective data strategies to harness the full benefits of both RAG and fine-tuning.
Despite these challenges, the hybrid approach marks a significant step forward in AI, offering models that combine broad knowledge access with deep domain expertise, paving the way for more sophisticated and adaptable AI solutions.
Choosing the best approach: Finetuning, RAG, or hybrid
Choosing between fine-tuning, Retrieval-Augmented Generation (RAG), or a hybrid approach for enhancing a Large Language Model should consider specific project needs, data accessibility, and the desired outcome alongside computational resources and scalability.
Fine-tuning is best when you have extensive domain-specific data and seek to tailor the LLM’s outputs closely to specific requirements, making it a perfect fit for projects like creating specialized educational content that adapts to curriculum changes. RAG, with its dynamic retrieval capability, suits scenarios where responses must be informed by the latest information, ideal for financial analysis tools that rely on current market data.
A hybrid approach merges these advantages, offering the specificity of fine-tuning with the contextual awareness of RAG, suitable for enterprises needing to keep pace with rapid information changes while maintaining deep domain relevance. As technology evolves, a hybrid model might offer the flexibility to adapt, providing a comprehensive solution that encompasses the strengths of both fine-tuning and RAG.
Evolution and future directions
As the landscape of artificial intelligence continues to evolve, so too do the methodologies and technologies at its core. Among these, Retrieval-Augmented Generation (RAG) and fine-tuning are experiencing significant advancements, propelling them toward new horizons of AI capabilities.
Advanced enhancements in RAG
Enhancing the retrieval-augmented generation pipeline
RAG has undergone significant transformations and advancements in each step of its pipeline. Each research paper on RAG introduces advanced methods to boost accuracy and relevance at every stage.
Let’s use the same query example from the basic RAG explanation: “What’s the latest breakthrough in renewable energy?”, to better understand these advanced techniques.
Pre-retrieval optimizations: Before the system begins to search, it optimizes the query for better outcomes. For our example, Query Transformations and Routing might break down the query into sub-queries like “latest renewable energy breakthroughs” and “new technology in renewable energy.” This ensures the search mechanism is fine-tuned to retrieve the most accurate and relevant information.
Enhanced retrieval techniques: During the retrieval phase, Hybrid Search combines keyword and semantic searches, ensuring a comprehensive scan for information related to our query. Moreover, by Chunking and Vectorization, the system breaks down extensive documents into digestible pieces, which are then vectorized. This means our query doesn’t just pull up general information but seeks out the precise segments of texts discussing recent innovations in renewable energy.
Post-retrieval refinements: After retrieval, Reranking and Filtering processes evaluate the gathered information chunks. Instead of simply using the top ‘k’ matches, these techniques rigorously assess the relevance of each piece of retrieved data. For our query, this could mean prioritizing a segment discussing a groundbreaking solar panel efficiency breakthrough over a more generic update on solar energy. This step ensures that the information used in generating the response directly answers the query with the most relevant and recent breakthroughs in renewable energy.
Through these advanced RAG enhancements, the system not only finds and utilizes information more effectively but also ensures that the final response to the query about renewable energy breakthroughs is as accurate, relevant, and up-to-date as possible.
Towards multimodal integration
RAG, traditionally focused on enhancing text-based language models by incorporating external data, is now also expanding its horizons towards a multimodal future.
Multimodal RAG integrates various types of data, such as images, audio, and video, alongside text, allowing AI models to generate responses that are not only informed by a vast array of textual information but also enriched by visual and auditory contexts.
This evolution signifies a move towards AI systems capable of understanding and interacting with the world more holistically, mimicking human-like comprehension across different sensory inputs.
In parallel, fine-tuning is transforming more parameter-efficient methods. Fine-tuning large language models (LLMs) presents a unique challenge for AI practitioners aiming to adapt these models to specific tasks without the overwhelming computational costs typically involved.
One such innovative technique is Parameter-Efficient Fine-Tuning (PEFT), which offers a cost-effective and efficient method for fine-tuning such a model.
Techniques like Low-Rank Adaptation (LoRA) are at the forefront of this change, enabling fine-tuning to be accomplished with significantly less computational overhead. LoRA and similar approaches adjust only a small subset of the model’s parameters, making fine-tuning not only more accessible but also more sustainable.
Specifically, it introduces a low-dimensional matrix that captures the essence of the downstream task, allowing for fine-tuning with minimal adjustments to the original model’s weights.
This method exemplifies how cutting-edge research is making it feasible to tailor LLMs for specialized applications without the prohibitive computational cost typically associated.
The emergence of long-context LLMs
The evolution toward long context LLMs – Source: Google Blog
As we embrace these advancements in RAG and fine-tuning, the recent introduction of Long Context LLMs, like Gemini 1.5 Pro, poses an intriguing question about the future necessity of these technologies. Gemini 1.5 Pro, for instance, showcases a remarkable capability with its 1 million token context window, setting a new standard for AI’s ability to process and utilize extensive amounts of information in one go.
The big deal here is how this changes the game for technologies like RAG and advanced fine-tuning. RAG was a breakthrough because it helped AI models to look beyond their training, fetching information from outside when needed, to answer questions more accurately. But now, with Long Context LLMs’ ability to hold so much information in memory, the question arises: Do we still need RAG anymore?
This doesn’t mean RAG and fine-tuning are becoming obsolete. Instead, it hints at an exciting future where AI can be both deeply knowledgeable, thanks to its vast memory, and incredibly adaptable, using technologies like RAG to fill in any gaps with the most current information.
In essence, Long Context LLMs could make AI more powerful by ensuring it has a broad base of knowledge to draw from, while RAG and fine-tuning techniques ensure that the AI remains up-to-date and precise in its answers. So the emergence of Long Context LLMs like Gemini 1.5 Pro does not diminish the value of RAG and fine-tuning but rather complements it.
Concluding Thoughts
The trajectory of AI, through the advancements in RAG, fine-tuning, and the emergence of long-context LLMs, reveals a future rich with potential. As these technologies mature, their combined interaction will make systems more adaptable, efficient, and capable of understanding and interacting with the world in ways that are increasingly nuanced and human-like.
The evolution of AI is not just a testament to technological advancement but a reflection of our continuous quest to create machines that can truly understand, learn from, and respond to the complex landscape of human knowledge and experience.
This is the first blog in the series of RAG and finetuning, focusing on providing a better understanding of the two approaches.
RAG and finetuning: You’ve likely seen these terms tossed around on social media, hailed as the next big leap in artificial intelligence. But what do they really mean, and why are they so crucial in the evolution of AI?
To truly understand their significance, it’s essential to recognize the practical challenges faced by current language models, such as ChatGPT, renowned for their ability to mimic human-like text across essays, dialogues, and even poetry.
Yet, despite these impressive capabilities, their limitations became more apparent when tasked with providing up-to-date information on global events or expert knowledge in specialized fields.
Take, for instance, the FIFA World Cup.
Messi’s winning shot at the Fifa World Cup – Source: Economic Times
If you were to ask ChatGPT, “Who won the FIFA World Cup?” expecting details on the most recent tournament, you might receive an outdated response citing France as the champions despite Argentina’s triumphant victory in Qatar 2022.
ChatGPT’s response to an inquiry about the winner of the FIFA World Cup 2022
Moreover, the limitations of AI models extend beyond current events to specialized knowledge domains. Try asking ChatGPT for treatments in neurodegenerative diseases, a highly specialized medical field. The model might offer generic advice based on its training data but lacks depth or specificity – and, most importantly, accuracy.
Symptoms of Parkinson’s disease – Source: Neuro2go
GPT’s response to inquiry about Parkinson’s disease
These scenarios precisely illustrate the problem: a language model might generate text relevant to a past context or data but falls short when current or specialized knowledge is required.
RAG revolutionizes the way language models access and use information. Incorporating a retrieval step allows these models to pull in data from external sources in real-time. This means that when you ask a RAG-powered model a question, it doesn’t just rely on what it learned during training; instead, it can consult a vast, constantly updated external database to provide an accurate and relevant answer. This would bridge the gap highlighted by the FIFA World Cup example.
On the other hand, fine-tuning offers a way to specialize a general AI model for specific tasks or knowledge domains. Additional training on a focused dataset sharpens the model’s expertise in a particular area, enabling it to perform with greater precision and understanding.
This process transforms a jack-of-all-trades into a master of one, equipping it with the nuanced understanding required for tasks where generic responses just won’t cut it. This would allow it to perform as a seasoned medical specialist dissecting a complex case rather than a chatbot giving general guidelines to follow.
Curious about the LLM context augmentation approaches like RAG and fine-tuning and their benefits, trade-offs and use-cases? Tune in to this podcast with Co-founder and CEO of LlamaIndex now!
This blog will walk you through RAG and finetuning, unraveling how they work, why they matter, and how they’re applied to solve real-world problems. By the end, you’ll not only grasp the technical nuances of these methodologies but also appreciate their potential to transform AI systems, making them more dynamic, accurate, and context-aware.
Understanding the RAG LLM duo
What is RAG?
Retrieval-augmented generation (RAG) significantly enhances how AI language models respond by incorporating a wealth of updated and external information into their answers. It could be considered a model consulting an extensive digital library for information as needed.
Its essence is in the name: Retrieval, Augmentation, and Generation.
Retrieval
The process starts when a user asks a query, and the model needs to find information beyond its training data. It searches through a vast database that is loaded with the latest information, looking for data related to the user’s query.
Augmentation
Next, the information retrieved is combined, or ‘augmented,’ with the original query. This enriched input provides a broader context, helping the model understand the query in greater depth.
Generation
Finally, the language model generates a response based on the augmented prompt. This response is informed by the model’s training and the newly retrieved information, ensuring accuracy and relevance.
Why use RAG?
Retrieval-augmented generation (RAG) brings an approach to natural language processing that’s both smart and efficient. It solved many problems faced by current LLMs, and that’s why it’s the most talked about technique in the NLP space.
Always up-to-date
RAG keeps answers fresh by accessing the latest information. RAG ensures the AI’s responses are current and correct in fields where facts and data change rapidly.
Sticks to the facts
Unlike other models that might guess or make up details (a ” hallucinations ” problem), RAG checks facts by referencing real data. This makes it reliable, giving you answers based on actual information.
Flexible and versatile
RAG is adaptable, working well across various settings, from chatbots to educational tools and more. It meets the need for accurate, context-aware responses in a wide range of uses, and that’s why it’s rapidly being adapted in all domains.
To understand RAG further, consider when you interact with an AI model by asking a question like “What’s the latest breakthrough in renewable energy?”. This is when the RAG system springs into action. Let’s walk through the actual process.
A visual representation of an RAG pipeline
Query initiation and vectorization
Your query starts as a simple string of text. However, computers, particularly AI models, don’t understand text and its underlying meanings the same way humans do. To bridge this gap, the RAG system converts your question into an embedding, also known as a vector.
Why a vector, you might ask? Well, A vector is essentially a numerical representation of your query, capturing not just the words but the meaning behind them. This allows the system to search for answers based on concepts and ideas, not just matching keywords.
Searching the vector database
With your query now in vector form, the RAG system seeks answers in an up-to-date vector database. The system looks for the vectors in this database that are closest to your query’s vector—the semantically similar ones, meaning they share the same underlying concepts or topics.
But what exactly is a vector database?
Vector databases defined: A vector database stores vast amounts of information from diverse sources, such as the latest research papers, news articles, and scientific discoveries. However, it doesn’t store this information in traditional formats (like tables or text documents). Instead, each piece of data is converted into a vector during the ingestion process.
Why vectors?: This conversion to vectors allows the database to represent the data’s meaning and context numerically or into a language the computer can understand and comprehend deeply, beyond surface-level keywords.
Indexing: Once information is vectorized, it’s indexed within the database. Indexing organizes the data for rapid retrieval, much like an index in a textbook, enabling you to find the information you need quickly. This process ensures that the system can efficiently locate the most relevant information vectors when it searches for matches to your query vector.
The key here is that this information is external and not originally part of the language model’s training data, enabling the AI to access and provide answers based on the latest knowledge.
Selecting the top ‘k’ responses
From this search, the system selects the top few matches—let’s say the top 5. These matches are essentially pieces of information that best align with the essence of your question.
By concentrating on the top matches, the RAG system ensures that the augmentation enriches your query with the most relevant and informative content, avoiding information overload and maintaining the response’s relevance and clarity.
Augmenting the query
Next, the information from these top matches is used to augment the original query you asked the LLM. This doesn’t mean the system simply piles on data. Instead, it integrates key insights from these top matches to enrich the context for generating a response. This step is crucial because it ensures the model has a broader, more informed base from which to draw when crafting its answer.
Generating the response
Now comes the final step: generating a response. With the augmented query, the model is ready to reply. It doesn’t just output the retrieved information verbatim. Instead, it synthesizes the enriched data into a coherent, natural-language answer. For your renewable energy question, the model might generate a summary highlighting the most recent and impactful breakthrough, perhaps detailing a new solar panel technology that significantly increases power output. This answer is informative, up-to-date, and directly relevant to your query.
Understanding fine-tuning
What is fine-tuning?
Fine-tuning could be likened to sculpting, where a model is precisely refined, like shaping marble into a distinct figure. Initially, a model is broadly trained on a diverse dataset to understand general patterns—this is known as pre-training. Think of pre-training as laying a foundation; it equips the model with a wide range of knowledge.
Fine-tuning, then, adjusts this pre-trained model and its weights to excel in a particular task by training it further on a more focused dataset related to that specific task. From training on vast text corpora, pre-trained LLMs, such as GPT or BERT, have a broad understanding of language.
Fine-tuning adjusts these models to excel in targeted applications, from sentiment analysis to specialized conversational agents.
Why fine-tune?
The breadth of knowledge LLMs acquire through initial training is impressive but often lacks the depth or specificity required for certain tasks. Fine-tuning addresses this by adapting the model to the nuances of a specific domain or function, enhancing its performance significantly on that task without the need to train a new model from scratch.
The fine-tuning process
Fine-tuning involves several key steps, each critical to customizing the model effectively. The process aims to methodically train the model, guiding its weights toward the ideal configuration for executing a specific task with precision.
A look at the finetuning process
Selecting a task
Identify the specific task you wish your model to perform better on. The task could range from classifying emails into spam or not spam to generating medical reports from patient notes.
Choosing the right pre-trained model
The foundation of fine-tuning begins with selecting an appropriate pre-trained large language model (LLM) such as GPT or BERT. These models have been extensively trained on large, diverse datasets, giving them a broad understanding of language patterns and general knowledge.
The choice of model is critical because its pre-trained knowledge forms the basis for the subsequent fine-tuning process. For tasks requiring specialized knowledge, like medical diagnostics or legal analysis, choose a model known for its depth and breadth of language comprehension.
Preparing the specialized dataset
For fine-tuning to be effective, the dataset must be closely aligned with the specific task or domain of interest. This dataset should consist of examples representative of the problem you aim to solve. For a medical LLM, this would mean assembling a dataset comprised of medical journals, patient notes, or other relevant medical texts.
The key here is to provide the model with various examples it can learn from. This data must represent the types of inputs and desired outputs you expect once the model is deployed.
Reprocess the data
Before your LLM can start learning from this task-specific data, the data must be processed into a format the model understands. This could involve tokenizing the text, converting categorical labels into numerical format, and normalizing or scaling input features.
At this stage, data quality is crucial; thus, you’ll look out for inconsistencies, duplicates, and outliers, which can skew the learning process, and fix them to ensure cleaner, more reliable data.
After preparing this dataset, you divide it into training, validation, and test sets. This strategic division ensures that your model learns from the training set, tweaks its performance based on the validation set, and is ultimately assessed for its ability to generalize from the test set.
Once the pre-trained model and dataset are ready, you must better tailor the model to suit your specific task. An LLM comprises multiple neural network layers, each learning different aspects of the data.
During fine-tuning, not every layer is tweaked—some represent foundational knowledge that applies broadly. In contrast, the top or later layers are more plastic and customized to align with the specific nuances of the task. The architecture requires two key adjustments:
Layer freezing: To preserve the general knowledge the model has gained during pre-training, freeze most of its layers, especially the lower ones closer to the input. This ensures the model retains its broad understanding while you fine-tune the upper layers to be more adaptable to the new task.
Output layer modification: Replace the model’s original output layer with a new one tailored to the number of categories or outputs your task requires. This involves configuring the output layer to classify various medical conditions accurately for a medical diagnostic task.
Fine-tuning hyperparameters
With the model’s architecture now adjusted, we turn your attention to hyperparameters. Hyperparameters are the settings and configurations that are crucial for controlling the training process. They are not learned from the data but are set before training begins and significantly impact model performance. Key hyperparameters in fine-tuning include:
Learning rate: Perhaps the most critical hyperparameter in fine-tuning. A lower learning rate ensures that the model’s weights are adjusted gradually, preventing it from “forgetting” its pre-trained knowledge.
Batch size: The number of training examples used in one iteration. It affects the model’s learning speed and memory usage.
Epochs: The number of times the entire dataset is passed through the model. Enough epochs are necessary for learning, but too many can lead to overfitting.
Training process
With the dataset prepared, the model was adapted, and the hyperparameters were set, so the model is now ready to be fine-tuned.
The training process involves repeatedly passing your specialized dataset through the model, allowing it to learn from the task-specific examples, it involves adjusting the model’s internal parameters, the weights, and biases of those fine-tuned layers so the output predictions get as close to the desired outcomes as possible.
This is done in iterations (epochs), and thanks to the pre-trained nature of the model, it requires fewer epochs than training from scratch. Here is what happens in each iteration:
Forward pass: The model processes the input data, making predictions based on its current state.
Loss calculation: The difference between the model’s predictions and the actual desired outputs (labels) is calculated using a loss function. This function quantifies how well the model is performing.
Backward pass (Backpropagation): The gradients of the loss for each parameter (weight) in the model are computed. This indicates how the changes being made to the weights are affecting the loss.
Update weights: Apply an optimization algorithm to update the model’s weights, focusing on those in unfrozen layers. This step is where the model learns from the task-specific data, refining its predictions to become more accurate.
A tight feedback loop where you incessantly monitor the model’s validation performance guides you in preventing overfitting and determining when the model has learned enough. It gives you an indication of when to stop the training.
Evaluation and iteration
After fine-tuning, assess the model’s performance on a separate validation dataset. This helps gauge how well the model generalizes to new data. You do this by running the model against the test set—data it hadn’t seen during training.
Here, you look at metrics appropriate to the task, like BLEU and ROUGE for translation or summarization, or even qualitative evaluations by human judges, ensuring the model is ready for real-life application and isn’t just regurgitating memorized examples.
If the model’s performance is not up to par, you may need to revisit the hyperparameters, adjust the training data, or further tweak the model’s architecture.
For medical LLM applications, it is this entire process that enables the model to grasp medical terminologies, understand patient queries, and even assist in diagnosing from text descriptions—tasks that require deep domain knowledge.
Hence, this provides a comprehensive introduction to RAG and fine-tuning, highlighting their roles in advancing the capabilities of large language models (LLMs). Some key points to take away from this discussion can be put down as:
LLMs struggle with providing up-to-date information and excelling in specialized domains.
RAG addresses these limitations by incorporating external information retrieval during response generation, ensuring informative and relevant answers.
Fine-tuning refines pre-trained LLMs for specific tasks, enhancing their expertise and performance in those areas.
Retrieval augmented generation (RAG) has improved the function of large language models (LLM). It empowers generative AI to create more coherent and contextually relevant content. Let’s take a deeper look into understanding RAG.
What is retrieval augmented generation?
It is an AI framework and a type of natural language processing (NLP) model that enables the retrieval of information from an external knowledge base. It integrates retrieval-based and generation-based approaches to provide a robust database for LLMs.
A retrieval augmented generation model accesses a large pre-existing pool of knowledge to improve the quality of LLM-generated responses. It ensures that the information is more accurate and up-to-date by combining factual data with contextually relevant information.
By combining vector databases and LLM, the retrieval model has set up a standard for the search and navigation of data for generative AI. It has become one of the most used techniques for LLM.
An example illustrating retrieval augmentation – Source: LinkedIn
Benefits of RAG
While retrieval augmented generation improves LLM responses, it offers multiple benefits to the generative AI efforts of an organization.
Explore RAG and its benefits, trade-offs, use cases, and enterprise adoption, in detail with our podcast!
Improved contextual awareness
The retrieval component allows access to a large knowledge base, enabling the model to generate contextually relevant information. Due to improved awareness of the context, the output generated is more coherent and appropriate.
Enhanced accuracy
An LLM using a retrieval model can produce accurate results with proper attribution, including citations of relevant sources. Access to a large and accurate database ensures that factually correct results are generated.
Adaptability to dynamic knowledge
The knowledge base of a retrieval model is regularly updated to ensure access to the latest information. The system integrates new information without retraining the entire program, ensuring quick adaptability. It enables the generative models to access the latest statistics and research.
Resource efficiency
Retrieval mechanisms enable the model to retrieve information from a large information base. The contextual relevance of the data enhances the accuracy of the results, making the process resource-efficient. It makes handling of large data volumes easier and makes the system cost-efficient.
Increased developer control
Developers use a retrieval augmented generation model to control the information base of a LLM. They can adapt the data to the changing needs of the user. Moreover, they can also restrict the accessibility of the knowledge base, giving them control of data authorization.
Frameworks for retrieval augmented generation
A RAG system combines a retrieval model with a generation model. Developers use frameworks and libraries available online to implement the required retrieval system. Let’s take a look at some of the common resources used for it.
Hugging face transformers
It is a popular library of pre-trained models for different tasks. It includes retrieval models like Dense Passage Retrieval (DPR) and generation models like GPT. The transformer allows the integration of these systems to generate a unified retrieval augmented generation model.
Facebook AI similarity search (FAISS)
FAISS is used for similarity search and clustering dense vectors. It plays a crucial role in building retrieval components of a system. Its use is preferred in models where vector similarity is crucial for the system.
PyTorch and TensorFlow
These are commonly used deep learning frameworks that offer immense flexibility in building RAG models. They enable the developers to create retrieval and generation models separately. Both models can then be integrated into a larger framework to develop a RAG model.
Haystack
It is a Python framework that is built on Elasticsearch. It is suitable to build end-to-end conversational AI systems. The components of the framework are used for storage of information, retrieval models, and generation models.
Use cases of RAG
Some common use cases and real-world applications are listed below.
Content creation
It primarily deals with writing articles and blogs. It is one of the most common uses of LLM where the retrieval models are used to generate coherent and relevant content. It can lead to personalized results for users that include real-time trends and relevant contextual information.
Real-time commentary
A retriever uses APIs to connect real-time information updates with an LLM. It is used to create a virtual commentator which can be integrated further to create text-to-speech models. IBM used this mechanism during the US Open 2023 for live commentary.
Question answering system
Question answering through retrieval augmented generation – Source: Medium
The ability of LLMs to generate contextually relevant content enables the retrieval model to function as a question-answering machine. It can retrieve factual information from an extensive knowledge base to create a comprehensive answer.
Language translation
Translation is a tricky process. A retrieval model can detect the context of phrases and words, enabling the generation of relevant translations. Access to external databases ensures the results are accurate and fluent for the users. The extensive information on available idioms and phrases in multiple languages ensures this use case of the retrieval model.
Educational assistance
The application of a retrieval model in the educational arena is an extension of question answering systems. It uses the said system, particularly for educational queries of users. In answering questions and generating academic content, the system can create more comprehensive results with contextually relevant information.
Future of RAG
The integration of retrieval and generation models in LLM is expected to grow in the future. The current trends indicate their increasing use in technological applications. Some common areas of future development of RAG include:
Improved architecture – the development of retrieval and generation models will result in the innovation of neural network architectures
Enhanced conversational agents – improved adaptation of knowledge base into retrieval model databases will result in more sophisticated conversational agents that can adapt to domain-specific information in an improved manner
Integration with multimodal information – including different types of information, including images and audio, can result in contextually rich responses that encompass a diverse range of media
Increased focus on ethical concerns – since data privacy and ethics are becoming increasingly important in today’s digital world, the retrieval models will also focus more on mitigating biases and ethical concerns from the development systems
Hence, retrieval augmented generation is an important aspect of large language models within the arena of generative AI. It has improved the overall content processing and promises an improved architecture of LLMs in the future.
In this blog, we are enhancing our Language Model (LLM) experience by adopting the Retrieval-Augmented Generation (RAG) approach!
We’ll explore the fundamental architecture of RAG conceptually and delve deeper by implementing it through the Lang Chain orchestration framework and leveraging an open-source model from Hugging Face for both question answering and text embedding.
So, let’s get started!
Common hallucinations in large language models
The most common problem faced by state-of-the-art LLMs is that they produce inaccurate or hallucinated responses. This mostly occurs when prompted with information not present in their training set, despite being trained on extensive data.
This discrepancy between the general knowledge embedded in the LLM’s weights and newer information can be bridged using RAG. The solution provided by RAG eliminates the need for computationally intensive and expertise-dependent fine-tuning, offering a more flexible approach to adapting to evolving information.
Retrieval-Augmented Generation involves enhancing the output of Large Language Models (LLMs) by providing them with additional information from an external knowledge source.
Explore LLM context augmentation techniques like RAG and fine-tuning in detail with out podcast now!
This method aims to improve the accuracy and contextuality of LLM-generated responses while minimizing factual inaccuracies. RAG empowers language models to sidestep the need for retraining, facilitating access to the most up-to-date information to produce trustworthy outputs through retrieval-based generation.
Architecture of RAG approach
Figure from Lang chain documentation
Prerequisites for code implementation
HuggingFace account and LLAMA2 model access:
Create a Hugging Face account (free sign-up available) to access open-source Llama 2 and embedding models.
Request access to LLAMA2 models using this form (access is typically granted within a few hours).
After gaining access to Llama 2 models, please proceed to the provided link, select the checkbox to indicate your agreement to the information, and then click ‘Submit’.
2. Google Colab account:
Create a Google account if you don’t already have one.
In Google Colab, go to Runtime > Change runtime type > Hardware accelerator > GPU > GPU type > T4 for faster execution of code.
4. Library and dependency installation:
Install necessary libraries and dependencies using the following command:
5. Authentication with HuggingFace:
Integrate your Hugging Face token into Colab’s environment:
When prompted, enter your Hugging Face token obtained from the “Access Token” tab in your Hugging Face settings.
Step 1: Document Loading
Loading a document refers to the process of retrieving and storing data as documents in memory from a specified source. This process is typically facilitated by document loaders, which provide a “load” method for accessing and loading documents into the memory.
Lang chain has number of document loaders in this example we will be using “WebBaseLoader” class from the “langchain.document_loaders” module to load content from a specific web page.
The code extracts content from the web page “https://lilianweng.github.io/posts/2023-06-23-agent/“. BeautifulSoup (`bs4`) is employed for HTML parsing, focusing on elements with the classes “post-content”, “post-title”, and “post-header.” The loaded content is stored in the variable `docs`.
After loading the data, it can be transformed to fit the application’s requirements or to extract relevant portions. This involves splitting lengthy documents into smaller chunks that are compatible with the model and produce accurate and clear results. Lang Chain offers various text splitters, in this implementation we chose the “RecursiveCharacterTextSplitter” for generic text processing.
The code breaks documents into chunks of 1000 characters with a 200-character overlap. This chunking is employed for embedding and vector storage, enabling more focused retrieval of relevant content during runtime. The recursive splitter ensures chunks maintain contextual integrity by using common separators, like new lines, until the desired chunk size is achieved.
Step 3: Storage in vector database
After extracting text chunks, we store and index them for future searches using the RAG application. A common approach involves embedding the content of each split and storing these embeddings in a vector store.
When searching, we embed the search query and perform a similarity search to identify stored splits with embeddings most similar to the query embedding. Cosine similarity, which measures the angle between embeddings, is a simple similarity measure.
Using the Chroma vector store and open source “HuggingFaceEmbeddings” in Lang chain, we can embed and store all document splits in a single command.
Text embedding:
Text embedding converts textual data into numerical vectors that capture the semantic meaning of the text. This enables efficient identification of similar text pieces. An embedding model, which is a variant of Language Models (LLMs) specifically designed for this purpose.
Lang Chain’s Embeddings class facilitates interaction with various text embedding models. While any model can be used, we opted for “HuggingFaceEmbeddings”.
This code initializes an instance of the HuggingFaceEmbeddings class, configuring it with an open-source pre-trained model located at “sentence-transformers/all-MiniLM-l6-v2“. By doing this text embedding is created for converting textual data into numerical vectors.
Vector Stores:
Vector stores are specialized databases designed to efficiently store and search for high-dimensional vectors, such as text embeddings. They enable the retrieval of the most similar embedding vectors based on a given query vector. Lang Chain integrates with various vector stores, and we are using “Chroma” vector store for this task.
This code utilizes the Chroma class to create a vector store (vectorstore) from the previously split documents (splits) using the specified embeddings (embeddings). The Chroma vector store facilitates efficient storage and retrieval of document vectors for further processing.
Step 4: Retrieval of text chunks
After storing the data, preparing the LLM model, and constructing the pipeline, we need to retrieve the data. Retrievers serve as interfaces that return documents based on a query.
Retrievers cannot store documents; they can only retrieve them. Vector stores form the foundation of retrievers. Lang Chain offers a variety of retriever algorithms, here is the one we implement.
Step 5: Generation of answer with RAG approach
Preparing the LLM Model:
In the context of Retrieval Augmented Generation (RAG), an LLM model plays a crucial role in generating comprehensive and informative responses to user queries. By leveraging its ability to process and understand natural language, the LLM model can effectively combine retrieved documents with the given query to produce insightful and relevant outputs.
These lines import the necessary libraries for handling pre-trained models and tokenization. The specific model “meta-llama/Llama-2-7b-chat-hf” is chosen for its question-answering capabilities.
This code defines a transformer pipeline, which encapsulates the pre-trained HuggingFacemodel and its associated configuration. It specifies the task as “text-generation” and sets various parameters to optimize the pipeline’s performance.
This line creates a Lang Chain pipeline (HuggingFace Pipeline) that wraps the transformer pipeline. The model_kwargs parameter adjusts the model’s “temperature” to control its creativity and randomness.
Retrieval QA Chain:
To combine question-answering with a retrieval step, we employ the RetrievalQA chain, which utilizes a language model and a vector database as a retriever. By default, we process all data in a single batch and set the chain type to “stuff” when interacting with the language model.
This code initializes a RetrievalQA instance by specifying a chain type (“stuff”), a HuggingFacePipeline (llm), and a retriever (retriever-initialize previously in the code from vectorstore). The return_source_documents parameter is set to True to include source documents in the output, enhancing contextual information retrieval.
Finally, we call this QA chain with the specific question we want to ask.
The result will be:
We can print source documents to see which document chunks the model used to generate the answer to this specific query.
In this output, only 2 out of 4 document contents are shown as an example, that were retrieved to answer the specific question.
Conclusion
In conclusion, by embracing the Retrieval-Augmented Generation (RAG) approach, we have elevated our Language Model (LLM) experience to new heights.
Through a deep dive into the conceptual foundations of RAG and practical implementation using the Lang Chain orchestration framework, coupled with the power of an open-source model from Hugging Face, we have enhanced question answering capabilities of LLMs.
This journey exemplifies the seamless integration of innovative technologies to optimize LLM capabilities, paving the way for a more efficient and powerful language processing experience. Cheers to the exciting possibilities that arise from combining innovative approaches with open-source resources!
RAG integration revolutionized search with LLM, boosting dynamic retrieval.
Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable.
In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Tune in to Co-founder and CEO of LlamaIndex, Jerry Liu, and learn all about LLMs, RAG, fine-tuning and more!
Why chunk size matters in RAG system
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and detail:
Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the most retrieved segments.
On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the faithfulness and relevance metrics.
These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation time for responses:
With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness is pivotal.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies.
Traditional evaluation techniques like BLEU or F1 are now unreliable for assessing models because they have limited correspondence with human evaluations.
As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment.
To facilitate this, we establish two key evaluators, the faithfulness evaluator and the relevance evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Downloading dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
Load dataset
SimpleDirectoryReader class will help us to load all the files in the dataset directory.
document[0:10] represents that we will only be loading the first 10 pages of the file for the sake of simplicity.
Defining question bank
These questions will help us to evaluate metrics for different chunk sizes.
Establishing evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
Main evaluator method
We will be evaluating each chunk size based on 3 metrics.
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
Testing different chunk sizes
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Use LlamaIndex to construct a RAG system
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions.
When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
Optimizing RAG Efficiency with LlamaIndex: Finding the Perfect Chunk Size
The integration of retrieval-augmented generation (RAG) has revolutionized the fusion of robust search capabilities with the LLM, amplifying the potential for dynamic information retrieval. Within the implementation of a RAG system, a pivotal factor governing its efficiency and performance lies in the determination of the optimal chunk size. How does one identify the most effective chunk size for seamless and efficient retrieval? This is precisely where the comprehensive assessment provided by the LlamaIndex Response Evaluation tool becomes invaluable. In this article, we will provide a comprehensive walkthrough, enabling you to discern the ideal chunk size through the powerful features of LlamaIndex’s Response Evaluation module.
Why chunk size matters
Selecting the appropriate chunk size is a crucial determination that holds sway over the effectiveness and precision of a RAG system in various ways:
Pertinence and Detail: Opting for a smaller chunk size, such as 256, results in more detailed segments. However, this heightened detail brings the potential risk that pivotal information might not be included in the foremost retrieved segments. On the contrary, a chunk size of 512 is likely to encompass all vital information within the leading chunks, ensuring that responses to inquiries are readily accessible. To navigate this challenge, we will employ the Faithfulness and Relevancy metrics. These metrics gauge the absence of ‘hallucinations’ and the ‘relevancy’ of responses concerning the query and the contexts retrieved, respectively.
Generation Time for Responses: With an increase in the chunk size, the volume of information directed into the LLM for generating a response also increases. While this can guarantee a more comprehensive context, it might potentially decelerate the system. Ensuring that the added depth doesn’t compromise the system’s responsiveness, is pivot.
Ultimately, finding the ideal chunk size boils down to achieving a delicate equilibrium. Capturing all crucial information while maintaining operational speed. It’s essential to conduct comprehensive testing with different sizes to discover a setup that aligns with the unique use case and dataset requirements.
Why evaluation?
The discussion surrounding evaluation in the field of NLP has been contentious, particularly with the advancements in NLP methodologies. Consequently, traditional evaluation techniques like BLEU or F1, once relied upon for assessing models, are now considered unreliable due to their limited correspondence with human evaluations. As a result, the landscape of evaluation practices continues to shift, emphasizing the need for cautious application.
In this blog, our focus will be on configuring the gpt-3.5-turbo model to serve as the central tool for evaluating the responses in our experiment. To facilitate this, we establish two key evaluators, Faithfulness Evaluator and Relevancy Evaluator, utilizing the service context. This approach aligns with the evolving standards of LLM evaluation, reflecting the need for more sophisticated and reliable evaluation mechanisms.
Faithfulness Evaluator: This evaluator is instrumental in determining whether the response was artificially generated and checks if the response from a query engine corresponds with any source nodes.
Relevancy Evaluator: This evaluator is crucial for gauging whether the query was effectively addressed by the response and examines whether the response, combined with source nodes, matches the query.
In order to determine the appropriate chunk size, we will calculate metrics such as average response time, average faithfulness, and average relevancy across different chunk sizes.
Setup
!pip install llama_index pypdf
import openai
import time
import pypdf
import pandas as pd
from llama_index.evaluation import (
RelevancyEvaluator,
FaithfulnessEvaluator,
)
from llama_index import (
SimpleDirectoryReader,
VectorStoreIndex,
ServiceContext
)
from llama_index.llms import OpenAI
OpenAI API Key
openai.api_key = ‘OPENAI_API_KEY’
Downloading Dataset
We will be using the IRS armed forces tax guide for this experiment.
mkdir is used to make a folder. Here we are making a folder named dataset in the root directory.
wget command is used for non-interactive downloading of files from the web. It allows users to retrieve content from web servers, supporting various protocols like HTTP, HTTPS, and FTP.
# we will first generate a set of 10 questions from first 10 pages.
documents = documents[0:10]
Defining Question Bank
These questions will help us to evaluate metrics for different chunk sizes.
questionBank = [‘What is the purpose of Publication 3 by the Internal Revenue Service?’,
‘How can individuals access forms and information related to taxes faster and easier?’,
‘What are some examples of income items that are excluded from gross income for servicemembers?’,
‘What is the definition of a combat zone and how does it affect the taxation of servicemembers?’,
‘How are travel expenses of Armed Forces Reservists treated for tax purposes?’,
‘What are some adjustments to income that individuals can make on their tax returns?’,
‘How does the Combat Zone Exclusion impact the reporting of combat zone pay?’,
‘What are some credits available to taxpayers, specifically related to children and dependents?’,
‘How is the Earned Income Credit calculated and who is eligible for it?’,
‘What are the requirements for claiming tax forgiveness related to terrorist or military action?’]
Establishing Evaluators
This code initializes an OpenAI language model (gpt-3.5-turbo) with temperature=0 settings and instantiate evaluators for measuring faithfulness and relevancy, utilizing the ServiceContext module with default configurations.
We will be evaluating each chunk size based on 3 metrics.
Average Response Time
Average Faithfulness
Average Relevancy
The function evaluator takes two parameters, chunkSize and questionBank.
It first initializes an OpenAI language model (llm) with the model set to gpt-3.5-turbo.
Then, it creates a serviceContext using the ServiceContext.from_defaults method, specifying the language model (llm) and the chunk size (chunkSize).
The function uses the VectorStoreIndex.from_documents method to create a vector index from a set of documents, with the service context specified.
It builds a query engine (queryEngine) from the vector index.
The total number of questions in the question bank is determined and stored in the variable totalQuestions.
Next, the function initializes variables for tracking various metrics:
totalResponseTime: Tracks the cumulative response time for all questions.
totalFaithfulness: Tracks the cumulative faithfulness score for all questions.
totalRelevancy: Tracks the cumulative relevancy score for all questions.
It records the start time before querying the queryEngine for a response to the current question.
It calculates the elapsed time for the query by subtracting the start time from the current time.
The function evaluates the faithfulness of the response using faithfulnessLLM.evaluate_response and stores the result in the faithfulnessResult variable.
Similarly, it evaluates the relevancy of the response using relevancyLLM.evaluate_response and stores the result in the relevancyResult variable.
The function accumulates the elapsed time, faithfulness result, and relevancy result in their respective total variables.
After evaluating all the questions, the function computes the averages
To find out the best chunk size for our data, we have defined a list of chunk sizes then we will traverse through the list of chunk sizes and find out the average response time, average faithfulness, and average relevance with the help of evaluator method. After this, we will convert our data list into a data frame with the help of Pandas DataFrame class to view it in a fine manner.
From the illustration, it is evident that the chunk size of 128 exhibits the highest average faithfulness and relevancy while maintaining the second-lowest average response time.
Conclusion
Identifying the best chunk size for a RAG system depends on a combination of intuition and empirical data. By utilizing LlamaIndex’s Response Evaluation module, we can experiment with different sizes and make well-informed decisions. When constructing a RAG system, it is crucial to remember that the chunk size plays a pivotal role. Therefore, it is essential to invest the necessary time to thoroughly evaluate and fine-tune the chunk size for optimal outcomes.
