Years back, I was lucky enough to stumble across something called Information Mapping. You’ve probably never heard of it. But in essence it’s about structured writing.
Sounds deathly dull, I know; but it transformed my ability to communicate – especially using the written word; and, it helped me think about most things much more clearly and logically.
After learning to use it, I became an Information Mapping trainer, teaching other people how to use the method. Eventually this led to the formation of Pacific Blue in 2002, with my colleague Sherryl, so that we could become the main provider of Information Mapping training in the UK – something we did until 2010.
I’ve been a great advocate for the method ever since learning it; but over the last 15 years or so I’ve noticed that interest in the method has waned. I could speculate about why that shift has happened but that’s a diary entry for another day.
Anyway, imagine my surprise when I realised that LLMs love structured content. You will typically get much better LLM output from your GPT if the content in your knowledge base is well-structured. In fact, you may have noticed that most of the output from your AI is generally well-structured and chunked.
That is no accident.
Because chunking of content (a principle deeply embedded in the Information Mapping method) is going to have a big impact on how your content is stored and referenced in a custom GPT’s knowledge base. When you put your content into a knowledge base, it will automatically get chunked by default.
But depending on the tool you are using to build your custom GPT, this could end up being done rather crudely and won’t necessarily follow the logic of any chunks (or paragraphs) you have intentionally created.
Additionally, these default chunks can end up being quite large.
Overall, the purpose of chunking is to help the LLM match content in a chunk with a user’s input, so it can provide a relevant response; but the larger the chunk of content being matched to the user input, the more likely it is the response will include extraneous or inaccurate information.
Worse still, if content has been chunked crudely, connected information might get spread across two separate chunks. For example, 80% in one chunk and 20% in another chunk.
The LLM may not pick up on the 20% in that second chunk and just use the 80% chunk for its response – possibly making something up in the process. And imagine how much worse the ‘hallucination’ might be if you reverse that around – it uses the 20% but for some reason misses the 80%!
The good news is that there are ways to have more system control over how your knowledge base content is chunked and, therefore, how well a chunk of content gets matched to a user’s input. The greater the system control over how something gets chunked, the greater the accuracy and relevance of output.
But you’ll only really reap the benefits of that more granular level of system control if the original content has been intentionally chunked with relevance and logic by the author or provider of that content.
If there are any LLM nerds or super-experts reading this, I’m sure they could nit-pick over the absolute accuracy of what I’ve just described. There is more detail I could add in but have deliberately left out because this is not a tutorial in all things AI.
My purpose here is to demystify some of the tech language and concepts that I’m learning about on my journey to building a no-code app.
Until next time…
