GambleGone

Summary

This project is made during the GarudaHacks 5.0 hackathon that I did with 3 other teammates. This hackathon is a part of my preparation before I go to Canada to participate in the hackathons there (see more here). During the 36 hours duration of the hackathon, we ended up making a product called GambleGone that is meant to help online gambling addicts to recover from their addiction. You can look at the demo and pitching video for the project here. A more general explanation of the project can be seen in its devpost.

The Team Composition

I placed myself as the """AI engineer"""" of the team due to my experiences developing LLM-based applications in Covena, the place of my summer internship, which I have been doing since June. The story of how I discovered this particular hackathon could be found in the aforementioned link, in which I talked about doing hackathons to prepare myself before doing hackathons in Canada. TL;DR I heard about it from a friend that I was doing another hackathon with (hackjakarta).

I first contacted Dewo, a friend of mine whom I have worked with in the past in TEDxITB. When I was the Director of Website for TEDxITB 6.0, he was one of my members in the department. His reliability and dependability when working under me was one of the reason I recommended him to be the next Director of Website, for next year's TEDxITB 7.0. In it, he demonstrated. Aside from what I have said in this paragraph, he has a long list of experience. More importantly, I get along pretty well with him, in both personal and professional capacity. That's why he was the first person that I called up to join this hackathon.

Dewo then contacted his two friends, Nuel and Angie. Nuel will be taking the role as a fellow fullstack developer just like Dewo, while Angie will be a mixture of the archetypal hipster & hustler. As such, she'll be handling both the UI/UX of the application that we're going to develop, as well as the business case for it.

What Did We Try to Make?

There are two tracks in the hackathon:

• Helping Hands: helping the underprivileged of society to regain their footing.

• Stronger Together: helping bands of people to join forces in tackling societal issues.

At first, the discussion started from addicts, from drugs to gambling. There was an idea to build an application that could help addicts recover and regain their life. But then, we thought that helping all form of addicts is too general of an app. The app would be too general and thus would be much less effective for each distinct types of addiction. Thus, we decided to narrow our focus to one specific type of addiction that has become an increasingly prevalent societal issue here in Indonesia, online gambling addiction.

Our idea was to make an app with the following features:

• Personalized debt tracker and debt analysis.

• Personalized first help chatbot that is equipped with resources on online gambling addiction and its treatment.

• Habit tracker and builder.

• User-created posts in which they can share their stories

• An alluring homepage with the most accurate facts and figures about online gambling addiction in Indonesia.

Not all of the above idea was thought of immediately in the planning stage. We came up with the debt tracker and analysis a good several hours after we had started to code.

Developer Diaries

I am responsible for the development of the AI-related functionalities of the application, but I think the title """AI engineer""" is too pompous to be put on me. I am not training new models, nor am I making an efficient but fruitful design of experiment for the model that will be used in the app. I am merely a GenAI jockey: making prompts, calling on the Claude Sonnet 3.5 LLM, and making a langchain chain that is suitable for the necessary functionalities of the applications.

RAG and Its Base Data

I conceived the chatbot that we had in mind to be using GenAI (obviously) as its base, with the addition of retrieval augmented generation (RAG). I'll discuss more on whether or not RAG is really necessary later, but I wanted to have RAG to make it more sophisticated than just merely prompting GenAI, which isn't all that different than just going to ChatGPT and typing your instructions yourself. Another benefit of RAG is the fact that it can augment the GenAI knowledge with knowledge that it may not have. In this particular case, the RAG could be used against the online gambling addiction resources provided by the government of Indonesia (which is written in Bahasa Indonesia). Unfortunately, this benefit can't really be reaped by this project since the chatbot needs to use English, and thus it's best that the data given to the RAG is also in English. Why should the chatbot speak in English? Because there were international judges in this hackathon.

Ooga booga programming is the term that me and my group of friends came up with when we do a quick and dirty implementation of something in our program (we don't claim ownership over the term or its meaning). And that's exactly what I did when I was doing my first objective, collecting the data for the chatbot. I simply googled a few dozens or so of online articles on online gambling addiction, printed them out to PDF, split them to chunks using the PDF splitter provided by the langchain library, and finally I upserted them to the Pinecone vector database. The vector database will handle the retrieval part of RAG, which will be done using the retriever abstraction provided by langchain.

The Chatbot and Its Limitations

In the previous section I already talked about how the benefits of RAG is diminished due to the necessity of using resources written in English for the RAG. There another larger quirk regarding the chatbot that cannot be ignored: it's implemented in langchain instead of langgraph. This is another example of ooga booga programming. When I started to develop the chatbot's back-end, it was the afternoon of the second day, about 18 hours or so since the hackathon had started, so it was right in the middle (I had a good night sleep prior to this to ensure I was able to function sanely during the second day). I was faced with the option to either implement a proper, well-functioning, and stateful chatbot with complicated RAG flows (see langgraph tutorial) using langgraph (a library that I have not yet delved that much deeper yet); or just make an easy-to-implement one flow chatbot using langchain.

I picked the latter. There were two main points on my reasoning: trying to make the chatbot using langgraph would run us the risk of not delivering the chatbot; and that there were not that much difference in the output of either implementation, given the limited data set and the limited scope of the chatbot.

Another limitation was the fact that the chatbot's response wasn't streamed to the front-end like most other GenAI tools such as ChatGPT or Github Copilot. I simply could not figure out how to make the streaming work when a langchain chain consists of multiple chain that fed off of the previous chain. This limitation was originally caused by my skill issue, but later on (this will be discussed in the next section) me and my teammates discovered that the tech stack that we had used does not really allow the use of streaming LLM responses to the front-end.

Debt Analysis (and Its Limitations)

It's pretty simple really. I just put in a prompt that explained the data format of the debt record, several examples of a debt record (this is called few-shot prompting), included the personal information and story of the user, and finally asked it for an analysis of the debt record, including any applicable advice. Since the chain consists of only a single chain, it was super easy to make streaming work in the back-end (there was quite a bit more involvement in the front-end, but it was made a breeze thanks to Vercel AI library).

Unfortunately, this is where we discovered the limitation of Vercel and its serverless deployments. Since Vercel's deployments are serverless, there's a limited amount of time in which a function can run in the back-end. Only after streaming had been implemented back to front and the app had been deployed, that we discovered that the aforementioned quirk of Vercel's serverless deployments rendered the streaming of debt analysis to become nonfunctional. Nuel later pulled another ooga booga programming and just did fake streaming purely from the front-end.

What Makes a Hackathon a Hackathon?

Sleepless nights. During the entirety of the hackathon duration, Dewo only slept for a couple of hours. I was sane enough to take a 7 hour sleep during the first day, because I knew I wouldn't function properly when I'm sleep deprived. But during the last day, me and all of my teammates didn't sleep as we were crunching together before the 6 AM deadline for the hackathon project. One of the most notable thing that happened was finding out a specific bug in the way that the pages was organized that caused the app to be slow. It turned out to be a quirk of Next (and its ever-expanding layers of abstraction) that we overlooked. Another notable thing is watching Angie making the incredibly cool demo and pitching video for the project using After Effects and Canva. It's also saddening seeing the research on the issue that she presented in the pitching video, in which a significant online gambler in Indonesia are kids and teenagers as young as 10.

And don't forget ooga booga programming, the recurring theme of this developer diary. Best practices, clean code, and the prevalence of code smells be damned, we have one day and a half to ship this thing!

Conclusion

Hackathon is about trying new things, going through uncharted territories, and breaking new bounds. Yet, when I look back at the experience, I can't help but think how an unquestionable proficiency in the tech stack that I was using would have helped me immensely in realizing what me and my teammates had in mind (see the chatbot and debt analyzer's limitations that have been discussed above).

I don't how far this statement could be generalized. Perhaps this is something that is unique to Indonesian hackathon or this applies to all hackathon in general. But what I can conclude for at least this hackathon, is the fact that the idea matters a lot more than the implementation details. Let me explain.

I know for a fact because I used langsmith for tracing that after we had submitted our project, our chatbot was only ever sent a message once, a simple hello message. We assumed this was one from the judges who actually tried the app. This then made me think, the app wasn't really used all that much, probably because the judges don't actually have the time to rigorously test every features of the app or even to merely try the app. This is cemented by the fact that the submission guide explicitly mentioned that a demo and pitching and demo video with a duration of over 2 minutes isn't guaranteed to be fully watched outside of the first 2 minutes by the judges. Of course this paragraph should be obvious to anybody who have been to a lot of hackathon, but I'm a first-timer, so this was a bit of a realization to me.

Following through with the implication of the preceding paragraph results in interesting conclusions. It means there's not much of a difference in how a judge regards GambleGone whether the chatbot in it be implemented with RAG or without. Expanding on it further, we could've programmed a pre-written script of conversation into the chatbot and only showed us going off of that script during our demo and pitch video. It would only be fraud had we disclaimed explicitly the implementation details of the chatbot (which in this case we did do in the devpost to show that the chatbot is somewhat sophisticated). Isn't that fascinating?