We now have the most comprehensive cookbook on building LLMs with Knowledge Graphs (credits @wey_gu).
✅ Key query techniques: text2cypher, graph RAG
✅ Automated KG construction
✅ vector db RAG vs. KG RAG
Check out the full 1.5 hour tutorial:
The full Colab notebook is here:
There was so much content beyond the live webinar that we recorded a part 2 🔥
With one line of code, you can now seamlessly integrate @llama_index with rich observability/eval tools offered by our partners (@weights_biases, @arizeai, @truera_ai).
Tip for better RAG systems💡: don’t just store raw text chunks, augment them with structured data.
✅Enables metadata filtering
✅Helps bias embeddings
Here’s a guide on how to use the @huggingface span-marker to extract entities for this exact purpose📕: https://t.co/Gwwoeu3i9Hgpt-index.readthedocs.io/en/latest/exam…
In this example, we parse the 2023 IPPC Climate Report.
After text parsing to break the document into chunks, we use the span-marker extractor to extract relevant entities.
These entities can be used as metadata filters (in a vector db) or to help enhance the context embeddings.
In this guide, we do the latter. Adding/embedding the right metadata directly improves the generated answer (left), vs. without (right)
Routing 🚏 is a super simple concept that takes advantage of LLM decision making. Use it in:
⚡️Workflow automation
🔎 Search/retrieval over complex data
We’ve significantly upgraded our router (0.7.20) for retrieval/querying AND added a full guide 📗: https://t.co/Vn3DnCRjpNgpt-index.readthedocs.io/en/latest/core…
Example 1: Using routing to decide between summarization or semantic search.
Given different query engines that will act on different ways over your data, a router module can help decide which one to pick given a question: https://t.co/Z5ZfGODTpKgpt-index.readthedocs.io/en/latest/exam…
Example 2: Using routing to decide between structured data or unstructured data
Given a query, decide whether it makes sense to run a SQL query or if the answer would be better found through semantic search: https://t.co/GOrJuw6djxgpt-index.readthedocs.io/en/latest/exam…
LLM-powered agents now can now “theoretically” interact with arbitrary external services, but there’s a sentiment that a lot of agent implementations can be unreliable:
- might not properly reason about next steps
- Might get stuck in a reasoning loop.
But think about it: if an API interface is hard to understand, then you as the developer will have a hard time making use of that API.
Agents need even more care in being able to understand how to use Tools.
Step 1: Our Gmail, Google Calendar, and Google Search Tool Specs offer rich API interfaces for agents.
For instance, the Gmail Tool spec allows you to create a draft, update it, and send it.
In total, we give all 9 Tools to the agent to use.
Step 2: Wrap each of these with our `LoadAndSearchToolSpec`.
This offers a convenience abstraction that can abstract away the complexity of many of these APIs returning too much data - can overflow context windows.
Our tool helps to cache data in a searchable index.
In the notebook example, we initialize our OpenAPI tool which defines endpoints to load OpenAPI specs, and also a request tool that can make API requests.
Problem: the data returned by OpenAPI specs is too large ⚠️
We have tool abstractions (`LoadAndSearchToolSpec` and `OnDemandLoaderTool`) that can handle indexing/loading data under the hood, allowing agents to plugin to any API service.