The trick to better answers from generative AI

Miso.ai co-founders Lucky Gunasekara and Andy Hsieh discuss how going beyond RAG basics to break down question context and assumptions is key for enterprise-grade service.

Generative AI offers great potential as an interface for enabling users to query your data in unique ways to receive answers honed for their needs. For example, as query assistants, generative AI tools can help customers better navigate an extensive product knowledge base using a simple question-and-answer format.

But before using generative AI to answer questions about your data, it’s important to first evaluate the questions being asked.

That’s the advice Lucky Gunasekara, CEO and co-founder of Miso.ai, has for teams developing generative AI tools today.

Miso.ai is the vendor partner for the Smart Answers project here at CIO.com and four of our sister sites. Smart Answers uses generative AI to answer questions about articles published on CIO.com and Foundry websites Computerworld, CSO, InfoWorld, and Network World. Miso.ai also built a similar Answers project for IDG’s consumer technology websites PCWorld, Macworld, and TechHive.

Interested in how Smart Answers surfaces its insights, I asked Gunasekara to discuss more deeply Miso.ai’s approach to understanding and answering users’ questions.

Large language models (LLMs) “are actually much more naive than we may think,” Gunasekara says. For example, if asked a question with a strong opinion, an LLM will likely go off and look to cherry-pick data that confirms the opinion, even if available data shows the opinion is wrong. So, if asked “Why did Project X fail?”, an LLM might scare up a list of reasons why the project was bad — even if it was a success. And that’s not something you want a public-facing app to do.

Evaluating questions is a step typically missed in so-called RAG (retrieval augmented generation) applications, Gunasekara notes. RAG apps point an LLM to a specific body of data and tell it to answer questions based only on that data.

Such apps usually follow this (somewhat simplified) pattern for setup:

Split the existing data into chunks, because all the data would be too large to fit into a single LLM query.

Generate what are known as embeddings for each chunk, to represent the semantic meaning of that chunk as a string of numbers, and store them. Update as needed as data changes.

And then per question:

Generate embeddings.

Find text chunks that are most similar in meaning to the question, using calculations based on the embeddings.

Feed the user’s question into an LLM and tell it to answer based solely on the most relevant chunks.

Here is where Gunasekara’s team takes a different approach, adding a step to check the question before searching for relevant information. “Instead of asking that question directly, we first ask if that assumption is correct,” explains Andy Hsieh, Miso CTO and co-founder.

In addition to checking assumptions inherent in questions, there are other ways to enhance the basic RAG pipeline to help improve results. Gunasekara advises going beyond the basics especially when moving from the experiment phase toward a production-worthy solution.

“There’s a lot of emphasis on ‘Get a vector database, do a RAG setup, and everything will work out of the box,’” Gunasekara says. “It’s a great way to get a proof of concept. But if you need to make an enterprise-grade service that doesn’t create unintended consequences, it’s always context, context, context.”

That can mean using other signals besides semantic meaning of text, such as recency and popularity. Gunasekara points to another project Miso is working on with a cooking website, deconstructing the question: “What’s the best bake-ahead cake for a party?”

“You need to separate out what you really need signals on” for the query, he says. “Make-ahead” cake means it doesn’t need to be served right away; “for a party” means it needs to serve more than a few people. Then there’s the issue of how an LLM can determine what recipes are “best.” That might mean using other website data, such as which recipes have the highest traffic, top reader rankings, or were awarded an editor’s pick — all of which is separate from finding and summarizing related text chunks.

“A lot of the sort of spooky magic of getting these things right is more in those context cues,” Gunasekara says.

And while quality of LLM is another important factor, Miso doesn’t believe it’s necessary to use the most highly rated and pricey commercial LLMs. Instead, Miso is fine-tuning Llama 2-based models for some client projects in part to keep costs down, and because some clients don’t want their data going off to a third-party. Miso is also doing so due to what Gunasekara calls “a huge ground force happening right now in open-source [LLMs].”

“Open source is really catching up,” Hsieh adds. “Open-source models are very, very close to surpassing GPT-4.”

SUBSCRIBE TO OUR NEWSLETTER