Interview Insights Extraction — lab audio overview

Host: Welcome back. You're in AI Solution Delivery — a course about taking artificial intelligence projects from a client conversation all the way to a running system. This chapter is called AI Use Case Discovery and Data Readiness Assessment. In plain words, it's about figuring out, early on, which AI ideas are actually worth building and whether the client has the data to support them. And the specific skill we're tackling today is one every consultant and solutions engineer runs into: turning messy interview conversations into structured, usable insights. Expert: Picture this. You're a senior engineer at a consulting firm, maybe fifty people, and your team just landed a discovery engagement with a large insurance company. You've got three weeks to interview twenty different stakeholders — claims managers, underwriters, IT leads, frontline agents — and come back with a prioritized list of AI opportunities. Here's what breaks without the skill we're covering today. Your junior consultants conduct interviews, but they ask generic questions, they miss the follow-ups that would have exposed the real pain point, and when it's time to synthesize, you end up with sixty pages of transcripts and no structured way to compare what one claims manager said against what another said. The partner asks, "So what are the top three opportunities?" and your team is flipping through notes. This exercise fixes exactly that — it gives you a system that listens to an interview in progress, suggests the smart next question to ask, and then pulls structured insights out of the transcript automatically. Host: Good — that's a scenario I've watched play out. Now let's connect the dots. In the previous exercise, students built the conversation controller — the piece that keeps track of where an interview is, what's been asked, and what should happen next. So what are we adding on top of that? Expert: Right, so the previous exercise gave you the skeleton — the thing that remembers the state of an interview and moves it through stages. What was missing from that skeleton is intelligence. It knew the interview had stages, but it didn't know how to react to what the interviewee actually said. That's what you're building today. Two pieces. First, a smart follow-up question generator. This is code that looks at the conversation so far — what you asked, what the person answered — and uses a large language model, meaning a general-purpose AI like the ones behind ChatGPT or Claude, to suggest a genuinely good next question. Not a scripted question — a contextual one. If the claims manager just mentioned that processing takes too long on weekends, the generator should probe that, not move on to the next topic on the list. Second, an insight extractor. After the interview, this part reads the whole transcript and pulls out three categories of information: pain points, which are things that hurt today; opportunities, which are places AI could help; and requirements, which are constraints the solution has to respect. And here's the key idea. Instead of getting back a wall of text from the language model, you force it to return answers in a fixed shape — a predictable structure with specific fields, every time. The library that enforces that shape is called Pydantic, a popular Python tool for defining and validating data structures. It's the difference between getting a freeform essay back and getting a filled-out form. Host: That structured-output idea is the heart of it. Before they dive in, what's the thing that typically trips people up on this one? Expert: The tricky part is the follow-up question generator getting too greedy. Beginners feed the entire conversation history into the language model every single turn, and two things go wrong. One, the cost and the response time balloon as the interview gets longer. Two, the model starts losing focus — it tries to follow up on everything and ends up asking vague, unfocused questions. The fix is to be deliberate about what context you pass in. Usually you want the current stage of the interview, the last two or three exchanges, and a short summary of what's been covered. Not the whole transcript. Treat the model like a sharp colleague who only needs the relevant slice, not the full history. Host: That's a great mental model. Let's close it out — what will students be able to do after this, and where does it lead? Expert: After this exercise, you'll be able to take a raw interview transcript and produce a clean, structured summary of pain points, opportunities, and requirements — automatically. And you'll know how to make a language model ask smarter, context-aware follow-up questions in the middle of a live conversation. For your team, this is a reusable building block. Any time your firm runs a discovery workshop, a requirements-gathering session, or even a customer research interview, this pattern plugs right in and standardizes the output. Next up, you'll wrap all of this — the conversation controller from the first exercise and the insight extraction you're building today — into a web service with save-and-resume sessions, so a consultant can pause an interview, come back tomorrow, and pick up exactly where they left off. That's the final piece that turns these components into something your team can actually deploy. Thanks for listening, and good luck with the build.