Category Archives: RelationalAI

Teaching an LLM a little Jiu Jitsu

A Brazilian Jiu-Jitsu match is in progress, featuring two competitors on a blue mat. One fighter, wearing a blue gi, is positioned on the bottom while the other, in a white gi with robotic elements, is attempting to gain control. A referee oversees the match, with spectators in the background.

Earlier this year, my colleagues at Relational AI helped AT&T build LLM models focused on Telecom called Otel and push it to the top of the leaderboard. I wish I could tell you all about it, but I wasn’t on the team. No worries though, you can read all about on the links above. Instead I’m going to tell you about training an LLM focused on Brazilian Jiu Jitsu. The idea is to ask it all kinds of dumb beginner questions and have it provides great answers. All without getting frustrated or telling you to focus on the fundamentals before trying flying armbars. Now, I wish I could just sign up Claude to our local school, fast forward 10 years and be done, but LLMs can’t learn that way. Large Language Models need Language, they need Text.

Luckily there are thousands of “Instructionals” (video classes teaching a topic or technique) of usually high quality and thousands of YouTube videos of varying degrees of quality we can use as our starting point. While kid classes pay the bills for local schools, it turns out middle aged men are the target audience of the instructional market. I had already purchased over 50 instructionals on BJJ Fanatics, but that wasn’t nearly enough, I had to use the Jozef Chen method and got a lot more. I also got some competition match clips that were narrated from youtube and downloaded them using yt-dlp.

Everyone is short on attention these days, so this is the AI:DR version for you to replicate this for your own video or document library:

  1. Clean phonetic transcription errors and prepend Contextual Retrieval headers ([Context: Author — Source | Category | Tags]) before embedding.
  2. Build an explicit Knowledge Graph mapping canonical tags, cross-school synonyms, parent-child tag hierarchy, and mutual-exclusivity rules.
  3. Audit video keyframes with CLIP + a Vision-Language Model so silent physical demonstrations become searchable [Visual Demonstration] chunks.
  4. Mine timestamped links from your existing docs to fine-tune an ONNX Cross-Encoder Re-Ranker (bge-reranker-base) with 5-way listwise loss.
  5. Synthesize a 3-Track SFT dataset (6-excerpt RAFT with distractors + diagnostic Go/No-Go gates + Knowledge Graph lineage/rules) and gate it with an automated <0.35% 7-gram linter.
  6. Run 2.5x Decision-Weighted QLoRA SFT followed by Zero-Extra-VRAM PEFT DPO (with model.disable_adapter(): + 0.15 NLL anchor) on a single GPU.
  7. Verify against a rubric-scored domain benchmark and deploy on volume-backed vLLM serverless.
Continue reading →
Tagged , , , , ,

The Logic Graph Epiphany

By the end of this blog post, you are going to experience two epiphanies about databases. However, you are going to have to do a little more work than just read. You are going to have to stop and actually think about what you’re reading. I promise it will be worth it. Let’s go!

A relational database has tables with columns of numbers we refer to as keys. User_ID 1, 2, 3, Place_ID 1, 2, 3, Book_ID 1, 2, 3… and so on. These are numbers that are hopefully the same on some other column on some other table. The database itself has absolutely no idea how things are connected until you query it and you tell it exactly how to use these columns to join the tables together. Think about that.

Now, a graph database has explicit relationships. You never have to ask it to search for some id in some column. It knows how things are connected. Tell me about yourself Node A. I am 5’11” and 200 lbs, I have brown eyes… Now tell me how you are related to the world. These are my Friends, these are the Companies I have worked at, these are the Skills I have learned, these are the Things I like. How are you and this other noted related? We are 4 hops away through x, y an z nodes.

Continue reading →
Tagged , , , , , ,

Hey Database! Go Fine Tune Yourself

Everyone expects AI prices to go down in the long term. But in the short term, we have three things going on. Token prices keep dropping, hurray for that. Subscription fees are going up and dumping their all you can eat plans for volume based pricing. There more you use, the more you pay. I guess that’s fair. Third, hardware component pricing is going up and big companies are borrowing billions to build the greatest and latest AI data centers. What’s going on? Are we in the pets.com era of selling $40 dollars worth of dog food for $20 bucks and making it up in volume? The real question is, how do we close this giant chasm of a value gap?

Molham Aref argues that enterprises must make agents smarter and cheaper. We have to solve two problems at the same time: making agents smart enough to handle real business decisions, and ensuring they are cost-effective enough to scale enterprise-wide. It sounds simple enough on the surface, but… it’s not. I’m going to talk about one of the ways we are doing that. But before I start, about six months ago, Greg Diamos and Naila Farooqui at RelationalAI wrote a blog post “Introducing Superalignment for Relational Databases“. If you haven’t read it yet, please take the time to do it now or you may be a little lost on what follows. There is a line in there people sometimes overlook, even thought it’s literally highlighted in bold:

The training dataset is the database itself.

Continue reading →
Tagged , , , , , , ,

Decision Graphs

About eight years ago, I wrote a little blog post on dynamic decision trees. If you have the time, go back and read that and the follow up posts on the subject. If not, I’ll summarize. Instead of building a Rules Engine to make decisions, I built a dynamic traverser that evaluates logic on the fly. This enables us to change how the decisions are made any time. We can also version the trees as we change it and create completely new trees for any complex decision making. If we don’t have enough information to get to a conclusion, it doesn’t give up or make something up, instead it asks us a question we must answer to continue down the path.

I bring up this relic from the past because I’m still trying to wrap my head around the value of “Context Graphs”. Which are supposed to be graphs that capture the how, when and why decisions were made instead of what decision was made. The idea being to capture “decision traces” which then allow an AI agent to see precedents (how similar problems were solved) and apply those same rules to new situations. The first decision traces would be made by people, and then the agents could learn and take it from there. So every time you want a decision answered, your agents would read all the previous decisions, analyze them, and make a new decision. But why? If we made a policy change, would the AI agents now ignore all the previous decisions and utilize the new policy? Would we have to repopulate the graph with human made decisions following the new policy so the agent understood there was a change?

Continue reading →
Tagged , , , ,

All of NoSQL is because of this…

In this blog post, KuzuDB creator Semih Salihoğlu makes the case that graph databases need new join algorithms. If you’ve read the blog post and came away still a bit confused then look at the image above. This image shows what happens when you try to join 3 tables. The problem is that traditionally databases have used binary joins (two tables at a time) to execute queries. The intermediate result build up of these joins can get massive and eat a ton of memory and processing power. The more binary joins you have, the worse it gets.

Continue reading →
Tagged , , , ,

Death Star Queries in Graph Databases

Star Wars: Episode IV - A New Hope Death Star

In Cypher, we call any unbounded star query a “Death Star” query. You’ll recognize it if you see a star between two brackets in any part of the query:

-[*]-

the deadly pattern of a death star query

The “star” in Cypher means “keep going”, and when it is not bound by a path length -[*..3]- or relationship type(s) -[:KNOWS|FRIENDS*]- it tends to blow up Alderaaning servers. It’s hard to find a valid reason for this query, but its less deadly cousins are very important in graph workloads.

For example when looking at fraud, we may start with a Customer node and ask, which known Fraudulent nodes are within 4 hops away? A Customer HAS an Account that was ACCESSED by a Device that ACCESSED another Account that BELONGS_TO a known Fraudster. A Customer HAS a mailing Address that is very SIMILAR to an Address that BELONGS_TO a Business that is partially OWNED by a known Fraudster. These are just two out of many valid patterns in our graph. Graph databases were designed to handle these kind of queries. The trick is that every node KNOWS its relationships, every node KNOWS how it is connected.

Continue reading →
Tagged , , , , , , ,

Watch your Language

I was watching The Marvelous Mrs. Maisel and one of the more jarring issues of the first two episodes is that Midge keeps getting arrested for the things she says. It reminded me of the song “Me So Horny” from 2 Live Crew that landed the hip hop group in jail charged with obscenity. Record store owners were getting arrested for selling CDs to undercover cops. How insane does that all sound? But it strikes the point that language matters. The things we say and how we say them are powerful. They convey meaning and emotion, language can be pleasant or it can be foul.

Continue reading →
Tagged , , , , , ,

Query Optimizers are made of sand

I’ve written a ton of SQL and Cypher queries over the last 20 years…and I’ve rewritten those queries as stored procedures more times than I can count. The issues with the expressivity of the query language and the ability of the query optimizer to “do the right thing” have been around longer than my career. I’ve written about this problem before. I went so far as to completely give up. In RageDB I let the developer write the query in a programming language directly. Skipping the “middle man” and letting the user be the query optimizer. Because in the end… this is what always happens. Well almost always.

Continue reading →
Tagged , , , ,

30 Days of Relational AI

There was a show called “30 Days” where people would be inserted in to a lifestyle completely different from their beliefs to see what would happen. The idea wasn’t so much to change their mind, but to help them (and the viewer) understand a little bit of both sides. My experience with Declarative Query languages so far has led me to the belief that they were ultimately a performance dead end. I’ve always known more than the database, which allowed me to hand-craft high performance queries using stored procedures. Building RageDB I decided to stay away from query languages, going as far as letting you write part of your query in “c” if you wanted to.

Continue reading →
Tagged , , , ,