Combining an LLM and a Rules-based Chatbot

A rules-based chatbot allows for rapid development. Adding rules as you go, some of which can contain complex logic. Rules-based systems do not use large amounts of computation and especially don’t require GPUs, cheaper running costs and more responsive replies. As powerful as rules-based chatbots are, they also come with downsides. Creating rules is time-consuming and challenging to cover all the scenarios. The rules files quickly become quite large and cumbersome. Workarounds such as having a final catch-all rule can somewhat mitigate this.

Read More about Combining an LLM and a Rules-based Chatbot

Chatbots

I’ve been working on chatbots on and off for a while now. The other day, I received a question about how I built the latest Chatbot.

“I love the Chatbot, and it has been something I’ve been trying to replicate. There is so much noise. I’m finding it hard to find a good solution. I’d be grateful if you could point me in any direction, tools or what to search for.” 

I had always intended to write about it. The scope may have expanded a little since then into a short series. This post covers some background on chatbots, a few principles for conversational interfaces and building a basic chatbot.

Read More about Chatbots

Language choices

Very much a part two of ‘Mistakes I’ve made in my career (so far)

The Question

My Experience

I am expanding on my Twitter thread.

At a previous start-up. Greenfield project. New team. We got started with building version one. We began as a free for all. The mindset was the best tool for the job. Resulting in every service being in a different language. Node, Go, Haskell, Python.

For the MVP, everything was in containers, so deploying and running the system was not that bad. Maybe a little too complex for the features we had but nothing too horrible. Engineers worked on the same service most of the time. No one was switching back and forth between services. Maintenance or anything post-demo got zero thought. We needed to ship sometime that vaguely worked.

Post MVP. Maintenance was a problem; only certain people could work on certain services. Hiring was the other major problem and ultimately forced the issue. No one knew all those languages. Even people that knew two or three of them were not at the same level in all the languages. Mentally switching between different languages is tiring.  

We took the difficult decision to standardise on Go. The largest and most active service used that. Everyone on the project would work in Go at least sometimes. We still had some other languages but only for specific uses. For example, python for data science tasks, but the default was Go for everything. We took the hit of rewriting services not already in Go over time. In the end, it cost a couple of months to get back to where we were for the MVP.

I do not think anyone thought the MVP code would survive long-term. I certainly did not. We were always going to rewrite, expand the services and remove all the last-minute fixes we needed to get the project out the door. If those services had already been in Go, that would have been an incremental refactoring process. We would always build a shippable version of the project. Instead, we broke everything and could not ship anything for what seemed like aeons. in start-up time. We were lucky and only needed to demonstrate the project on one or two occasions. Each time was a painful experience until we had finished the rewrite.

Hiring was more focused. We had less of a laundry list of skills and languages—this ultimately allowed us to hire some junior engineers. You can not expect someone at the start of their career to be able to write production code in three or four languages. Maintenance was more manageable with only a single language. Everyone in engineering could help each other. The general quality of code went up.

Painful lesson learnt.

At my current place we started off standardising on Node. Not because it is my favourite language but because the centre of gravity in the project is around Node. The same with yarn.

Building Products With Kent Beck

I went north up to Euston to Facebook London to hear Mike Perrow and Kent Beck talk about building products.

Mike kicked things off, talking about building and shipping Workplace. The most interesting part was using the War room model when they launched.

The main talk was Kent Beck. Talking about 3X: Explore/Expand/Extract. Covering the shifting risk profile of software product development as products mature.

Kent Beck: 3X
Read More about Building Products With Kent Beck

Ada Lovelace Day – Thayer Prime

Entrepreneurs and startups seem to be our new heroes but most of the people you read about are male. This is especially true of CEO’s and other senior managers. Much better informed people than me have written about why this is a problem and how we can go about fixing it.

I thought it would be worth highlighting one of the women in a senior position that have inspired me, Thayer Prime, who beside having just the best name, is currently CEO and founder of Team Prime and Primed.is.

She started in technology as a developer but moved on to running multiple successful startups, helped many well-known company’s and organisations. In addition to all that she has also run a wonderful conference, some very enjoyable christmas parties and mentored people new to the London tech scene. She managed to find the time to ran a marathon.

One of the biggest thing that continues to inspire me, is the way she does business differently, giving to charity via her company, not working all hours, spending time with her family. More people should follow her example

Ada Lovelace Day – Emma Mulqueeny

Every so often a story pops up in the press about how the UK need more engineers or about the state of computing teaching in schools.

I grew up just as the BBC was coming into schools, we had one at home, my friends had between them most of the 8-bit machines, we all played around with BASIC, programming some simple things. I didn’t do much actual programming at school, my first formal teaching was at University. Instead as we all moved over to ST‘s and Amiga‘s many of use got into STOS and AMOS, a few even progressed to 68000 assembly. Much of this motivated by wanting to create games and demos. This is how most people around my age learnt programming.

Today, consoles are more popular, we have smartphones with apps, PC’s don’t tend to ship with programming languages installed by default, so simply being a consumer is much easier but we have the web, with all free tools for creating applications, so the opportunities are still around, just different. Culturally programming has become more specialist than in the 80’s, not something for the average person, even as computers have moved into more areas of everyday life.

One person helping to increase the number of people exposed to programming is Emma Mulqueeny (aka @HubMum). She is behind Rewired State and the offshoot Young Rewired State for people 18 and under, if that was not enough she is also involved in Coding for Kids. Also she is an advisor to the mayor of London on Digital issues. So she is making a difference to the way computers are taught in school, maybe in the future we will see less of those articles telling us we need more engineers in part because of the work she is doing today.