🔥Building a Slack Bot with AI Capabilities - From Scratch! Part 5: RAG with Confluence Knowledge Base🔥

aka, please read ALL my docs

This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can do it!

This article is part of a series of articles, because 1 article would be absolutely massive.

• Part 1: Covers how to build a slack bot in websocket mode and connect to it with python

• Part 2: How to deploy an AWS Bedrock AI resource and connect to it to ask a request locally from your terminal with python3

• Part 3: We’ll connect our slack bot with Bedrock locally using python3 with ngrok so slack users can have conversations with AI

• Part 4: How to convert your local script to an event-driven serverless, cloud-based app in AWS Lambda

• Part 5 (this article): Building a RAG Knowledge Base of an entire Confluence wiki, and teaching our Slack Bot to Read it in RealTime

The response to this series from you readers (and from my coworkers to this tool) has been tremendous, so I’m going to keep building it out. Your subscriptions (and if you’re a paying subscriber, your dollars for caffeine), power me to write all these. If you don’t subscribe, please consider doing so. It means the world to me :D

Hey all!

In this series so far, we’ve established a Slack App (that we call @Vera), which sends a webhook to an AWS Lambda running Python 3.12. It reads the Slack thread, and constructs a conversation for Claude Sonnet v3, which is running in serverless mode on AWS Bedrock. We built guardrails, all the python, all the things.

It’s amazing, and it works, and our users love it. And then they ask:

Can you have this bot read our internal docs?

And that’s a great question, right? Wouldn’t it be amazing if this great AI bot had read all your internal docs and could have a conversation with you on it? Even better if it could link you to the relevant docs so you could read further?

Well, you can do that! There’s a couple options here:

• Training a model so it has access to all your data internally

  • This requires dedicated “provisioned access” at AWS, which is minimum $30k/month, which is a little beyond my price point

• Establishing a “knowledge base” which runs OpenSearch on the back-end, and can be queried to provide “vectors” (which are really snippets of information) to your bot so it can be more informed

  • This should cost a few hundred dollars a month, which is significant, but not compared with Confluence AI, which is ~$3.53/month/user, so for 1.5k users, that’s $63k/yr!

  • This is an early feature from AWS, and it’s not very efficient yet. You pay for DB units, and so it’s costing ~$2k/month. That’s still less than 40% what Confluence AI costs, but it’s a significant investment! FYI in case you don’t have a corp picking up the bill here

We don’t want to pay $30k/month to train our model on any particular knowledge. We’d rather just fetch relevant information at runtime. That doesn’t sound very amazing, but check out some examples of what it can do.

Example 1 - When provided with some terraform to validate, it found that a) the terraform is entirely valid and logical except b) it checked the IPs referenced in the confluence vector DB, and found that one of them was inaccurate

Good luck getting a human to notice something like that, but Vera found it in a few seconds and event provided a fixed version.

Example 2: Sometimes it’s hard to know who to talk to. When asked for the name of an internal team, it found a Confluence wiki that had all the members, and provided all of them grouped by function.

Having an AI that understands your Org chart (if you keep that somewhere in Confluence) can be really helpful for who to ask to unstick stuck projects, or know who the expert on a particular topic is.

Without further ado, lets dig into how we implement this. First stop, lets read the entire Confluence and store it in OpenSearch with a Bedrock Knowledge Base.