Notebooks
W
Weaviate
Weaviate Dspy Visualization

Weaviate Dspy Visualization

vector-searchvector-databaseretrieval-augmented-generationllm-frameworksoperationsfunction-callingweaviate-recipesintegrationsPythongenerative-ailangwatch

Open In Colab

DSPy with Weaviate + LangWatch DSPy Visualizer

This notebook shows an example of DSPy RAG program using Weaviate as the vector database and LangWatch for visualization of the DSPy optimization process.

[ ]

1. Load Data into Weaviate

You need a running Weaviate cluster with data:

  1. Learn about the installation options here, or use the ./docker-compose.yml file, which uses Cohere for embeddings

  2. Import your data:

    a. You can follow the Weaviate-Import.ipynb notebook to load in the Weaviate blogs

    b. Or follow this Quickstart Guide

2. Prepare the LLM and Retriever

[1]
LLM test response: ['Hello! How can I assist you today?']
Retriever test response: {'long_text': "LLMs are a versatile tool that is seen in many applications like chatbots, content creation, and much more. Despite being a powerful tool, LLMs have the drawback of being too general. Reasoning: Let's think step by step in order to **produce the query. We need to identify the unique aspects of the document that would allow us to formulate a question that this document can answer. The document seems to focus on the combination of LangChain and Weaviate, mentioning the benefits of LangChain in overcoming limitations of LLMs such as hallucination and limited input lengths."}
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1721929852.765644 4075415 config.cc:230] gRPC experiments enabled: call_status_override_on_cancellation, event_engine_dns, event_engine_listener, http2_stats_fix, monitoring_experiment, pick_first_new, trace_record_callops, work_serializer_clears_time_cache

3. Prepare the Dataset

[2]
(30, 20)

4. Define the RAG model

[3]
[Devset] Question: What is the strategy for chunking text for vectorization when dealing with a 512 token length limit?
[Devset] Answer: The strategy for chunking text for vectorization when dealing with a 512 token length limit involves using a Large Language Model to identify suitable places to cut up text chunks. This process, known as "chunking", breaks down long documents into smaller sections, each containing an important piece of information. This approach not only helps to stay within the LLMs token limit but also enhances the retrieval of information. It's important to note that the chunking should be done thoughtfully, not just splitting a list of items into 2 chunks because the first half fell into the tail end of a chunk[:512] loop.
[Prediction] Question: What is the strategy for chunking text for vectorization when dealing with a 512 token length limit?
[Prediction] Predicted Answer: Context: The provided context discusses the limitations of vector embedding models, particularly the 512 token length constraint, and suggests strategies for effectively chunking text for vectorization. It highlights the importance of identifying optimal places to cut text chunks, such as avoiding arbitrary splits that could disrupt the coherence of the content, and emphasizes the use of summarization techniques to handle longer documents.

Question: What is the strategy for chunking text for vectorization when dealing with a 512 token length limit?

Answer: The strategy for chunking text for vectorization within the 512 token length limit involves several key considerations. First, it is essential to identify logical and coherent points in the text where it can be divided, rather than making arbitrary cuts that could disrupt the flow of information. For instance, when dealing with lists or structured data, care should be taken to avoid splitting items in a way that separates related content. 

Additionally, for longer documents that exceed the token limit, summarization techniques can be employed. This involves creating a summary of the text, which can then be vectorized and indexed for semantic search. By summarizing the content, the overall length is reduced while still capturing the essential information, making it suitable for embedding within the token constraints.

In practice, a good chunk size is often around a single paragraph or less, which typically fits within the 512 token limit. However, in special cases where longer texts need to be embedded, models with larger context windows may be necessary. Overall, the strategy emphasizes coherence, logical segmentation, and the use of summarization to effectively manage the limitations of vectorization models.

5. Define your Metric

[110]
422.5

6. Connect to LangWatch

[4]
Please go to https://app.langwatch.ai/authorize to get your API key
LangWatch API key set

7. Start Training Session!

This will cost around $0.40

[ ]

Screenshot:

optimization screenshot

[115]
430.0
Congratulations! We optimized the RAG program and bumped the score from 422.5 to 430.0!

8. Save the optimized RAG

You can now use your optimized RAG program for inference

[ ]

9. Final Step: Instrument your DSPy program for Production

Now that you have your optimized RAG, you are ready to deploy, but usage in production can also be unpredictable.

To keep track of which documents are being retrieved and used by your RAG in production, you can use the langwatch.trace() decorator to instrument your DSPy program (docs for more details)

[5]
Trace Public URL: https://app.langwatch.ai/share/iNwGfWN3E3EzkoNjQxwK1
Prediction(
,    context=['We can then vectorize this text description using off-the-shelf models from OpenAI, Cohere, HuggingFace, and others to unlock semantic search. We recently presented an example of this idea for [AirBnB listings](https://weaviate.io/blog/generative-feedback-loops-with-llms), translating tabular data about each property’s price, neighborhood, and more into a text description. Huge thanks to Svitlana Smolianova for creating the following animation of the concept. <img\n    src={require(\'./img/gen-example.gif\').default}\n    alt="alt"\n    style={{ width: "100%" }}\n/>\n\n### Text Chunking\nSimilarly related to the 512 token length for vectorizing text chunks, we may consider using the Large Language Model to identify good places to cut up text chunks. For example, if we have a list of items, it might not be best practice to separate the list into 2 chunks because the first half fell into the tail end of a chunk[:512] loop.', '### Summarization Indexes\nVector embedding models are typically limited to 512 tokens at a time. This limits the application of vector embeddings to represent long documents such as an entire chapter of a book, or the book itself. An emerging solution is to apply summarization chains such as the create-and-refine example animated at the end of this article to summarize long documents. We then take the summary, vectorize it, and build an index to apply semantic search to the comparison of long documents such as books or podcast transcripts. ### Extracting Structured Data\nThe next application of LLMs in Search Index Construction is in extracting structured data from unstructured text chunks.', 'For common RAG applications, a good chunk size for an embedding is typically about a single paragraph of text or less. In this case, models with max tokens of 512 should be sufficient. However, there will be special cases where you need to embed longer source texts that require models with a larger context window. ![mteb leaderboard](./img/mteb.png)\n\n## Step 3: Evaluate the model on your use case\n\nWhile the MTEB Leaderboard is a great place to start, you should take its results cautiously and skeptically. Bear in mind that these results are self-reported.'],
,    answer='Context: The context discusses the limitations of vector embedding models, which are typically restricted to processing 512 tokens at a time. It emphasizes the importance of effective text chunking strategies to optimize the vectorization process, particularly when dealing with long documents or extensive text data. The context also mentions the use of Large Language Models (LLMs) to identify optimal places for cutting text into chunks, ensuring that the chunks remain coherent and meaningful for vectorization.\n\nQuestion: What is the strategy for chunking text for vectorization when dealing with a 512 token length limit?\n\nAnswer: To effectively chunk text for vectorization within the 512 token length limit, you can follow these strategies:\n\n1. **Identify Natural Breaks**: Use the content structure to identify natural breaks in the text, such as paragraphs, sentences, or sections. This helps maintain the coherence of the information within each chunk.\n\n2. **Use Large Language Models (LLMs)**: Leverage LLMs to analyze the text and suggest optimal chunking points. These models can help determine where to split the text based on semantic meaning, ensuring that each chunk remains contextually relevant.\n\n3. **Limit Chunk Size**: Aim to keep each chunk to a single paragraph or less, as this typically fits well within the 512 token limit. This approach allows for more manageable and meaningful vector representations.\n\n4. **Summarization for Long Texts**: For longer documents that exceed the token limit, consider applying summarization techniques. Summarize the content first, then vectorize the summary to create an index for semantic search.\n\n5. **Iterative Testing**: After chunking, test the vectorization process to ensure that the resulting embeddings are effective for your specific use case. Adjust the chunk sizes as necessary based on the performance of the semantic search.\n\nBy implementing these strategies, you can optimize the chunking of text for vectorization, ensuring that the resulting embeddings are both efficient and meaningful for subsequent semantic search tasks.',
,    question='What is the strategy for chunking text for vectorization when dealing with a 512 token length limit?'
,)

Screenshot:

Tracing Screenshot