Introduction​

Since ChatGPT hit the scene, the term 'Large Language Models (LLMs)' has become a buzzword, with everyone on social media sharing the latest papers on the next big advancement. At first, I was just as excited, but eventually, I started to lose interest as many of these so-called breakthroughs felt like incremental improvements. They didn’t offer that 'wow' factor that ChatGPT did. But then, I stumbled upon a post from Amazon Science that reignited my interest in LLMs. They were talking about using LLMs, not for the usual NLP tasks, but for something entirely different: time series forecasting!

This got me excited because imagine being able to harness the power of LLMs—models that have already shown amazing feats in Natural Language Processing (NLP)—and apply it to time series! Could we finally predict the future with perfect accuracy? Well, obviously not, but even reducing uncertainty would be incredibly valuable.

In this blog post, I’ll walk you through how the authors of the Chronos paper successfully repurposed any LLM for time series forecasting. And if you’re the hands-on type, you can follow along with all the code to reproduce the diagrams and results by checking out this GitHub repository.

Introduction​

So, there I was, reading this paper on time series models, and suddenly I hit a section that made me go, "WTF?" The model didn’t just spit out a single predicted value; instead, it produced a whole range of predictions. My brain instantly went into overdrive—how on earth are you supposed to evaluate that? I’m used to straightforward metrics like RMSE or MAD, where you basically compute the difference between the actual and predicted values. But now, the predicted value has multiple numbers, and let’s just say, my head was ready to explode 😅

That’s when the author introduced Weighted Quantile Loss, and I knew I had to dive deep into it and put together this guide to help folks understand it just as clearly.

Introduction​

As someone who works with vector databases daily, I've become accustomed to the conventional applications of Retrieval-Augmented Generation (RAG) in scenarios such as extracting information from dense user manuals, navigating complex code bases, or conducting in-depth legal research. These "talk to your documents" use cases, while impressive, often revolve around similar challenges across different datasets, which can become somewhat monotonous.

So, it was particularly refreshing when I came across the paper "Approaching Human-Level Forecasting with Language Models" by researchers Danny Halawi, Fred Zhang, Chen Yueh-Han, and Jacob Steinhardt from UC Berkeley. They propose a novel (at least to me) use of RAG: forecasting events!

Introduction​

Imagine a tool that can dive into real GitHub repositories to debug and fix issues automatically. That's SWE-agent for you, a project born at Princeton University, where language models like GPT-4 are turned into software engineering agents. These aren't just toys either; they've shown to resolve over 12% of software issues tested in the SWE-bench dataset. While 12% might not initially seem high, it represents a significant leap from the previous benchmark of just 3.79%. This achievement marks a considerable advancement in the field, underscoring the growing potential of AI to transform software development and maintenance.

My journey into SWE-agent began with curiosity and a bit of a stumble. I wanted to set up a local dev environment to study the model's inference step but the project doesn't say how to set up such an environment! It's a familiar story in open-source projects, especially those with roots in academia. I encountered a mix of excitement and frustration, reading through the setup instructions in the README and realizing the commitment needed to even start. And I wasn't the only one feeling this way; a community issue highlighted similar struggles.

Deciding to lean into the challenge, I saw an opportunity to simplify this for everyone. While the official setup process is being refined, I've put together an alternative guide to get you up and running with SWE-agent in a local dev environment using dev containers.

All you need is Docker and VS Code!

Introduction​

Retrieval Augmented Generation (RAG) typically finds its place in enhancing document-based question answering (QnA), effectively leveraging extensive databases to provide contextually relevant information for Large Language Models (LLMs) to formulate precise answers. Traditionally, when looking to boost the reasoning capabilities of LLMs, the go-to strategy has been fine-tuning these models with additional data. However, fine-tuning is not only resource-intensive but also presents scalability challenges.

Interestingly, RAG could potentially offer a more efficient pathway to enhance LLMs' reasoning skills without the hefty costs of fine-tuning. This intriguing premise is explored in depth in Enhancing LLM Intelligence with ARM-RAG: Auxiliary Rationale Memory for Retrieval Augmented Generation by Eric Melz, which proposes a novel use of RAG beyond its conventional application, aiming to refine and expand the problem-solving prowess of LLMs efficiently.

Introduction​

When it comes to bestowing Large Language Models (LLMs) with long-term memory, the prevalent approach often involves a Retrieval Augmented Generation (RAG) solution, with vector databases acting as the storage mechanism for the long-term memory. This begs the question: Can we achieve the same results without vector databases?

Enter "RecallM: An Adaptable Memory Mechanism with Temporal Understanding for Large Language Models" by Brandon Kynoch, Hugo Latapie, and Dwane van der Sluis. This paper proposes the use of an automatically constructed knowledge graph as the backbone of long-term memory for LLMs.

Introduction​

In the dynamic realm of data management, the unfolding narrative of vector databases as a unique category mirrors the historical discourse of the SQL vs NoSQL movement that swept through the tech world over the past decade. As modern enterprises wrestle with increasingly intricate data landscapes, differentiating between traditional databases and vector databases becomes not merely relevant, but essential.

This article will argue why this distinction is necessary and explore how specialized vector database companies can respond to incumbents in the database domain.

Introduction​

In the high-stakes world of venture capital, hindsight often provides lessons that are as valuable as a successful investment. Imagine having the chance to invest in companies like Airbnb, Apple, or Google—only to pass on the opportunity. Sounds unthinkable today, doesn't it?

Yet, even the best in the business have their list of 'the ones that got away.' For example, Bessemer Venture Partners openly shares this list in their The Anti-Portfolio page.

Curious about what could be learned from these passed-over investments, I took a deep dive into each company listed on that page to look for common threads. I've condensed these findings into 7 lessons that might just be game-changers in how you approach venture investing.

If you're interested in avoiding the same pitfalls and sharpening your investment acumen, keep reading.

Introduction​

In the realm of software development, debugging is not only inevitable but can also be a complex endeavor.

Picture this: you're faced with the task of deciphering what's occurring within a server that's already humming along. Relaunching it with an attached debugger, the usual go-to method, isn't an option.

In this post, we'll navigate this challenge, zeroing in on how to debug an already running FastAPI server in the rag-stack project as an example. And for those on a tight schedule, here's a quick video tutorial breaking down the process:

Introduction​

Today, we're going to discuss an efficient way to set up your automated integration test workflows using Docker and Pytest.

Motivation​

In an era where software complexity is rapidly growing, developing an efficient testing strategy is more than a mere best practice — it's the bedrock of stable and reliable applications.

One common strategy involves using Docker to set up a test version of a software component, such as a vector database. There are two popular variations to this strategy, both of which have their own limitations.