The bar for production rises with the possible cost of a wrong answer, from minor business impact to regulatory, reputational, financial, health, or safety consequences.
2
Teams should match deterministic tools, language models, retrieval, and human review to the kind of answer and level of risk they have.
3
Production work needs early evaluation data, realistic cost and latency targets, visible AI behavior, and a clear understanding of how users will interact with the system.
Summary
Philip Rathle frames production readiness around the stakes of an AI application. A bedtime-story summarizer can tolerate a different error rate from a system that affects loans, health, safety, regulation, or a company's reputation. Retrieval augmented generation can add current domain information, while knowledge graphs provide structured facts that machines can reason over and people can inspect. The discussion then turns to practical lessons from teams building real systems. Use deterministic databases or reasoning engines for exact questions, and let the language model translate questions or present answers. Start evaluation work when application development starts, because teams need data to measure whether prompts, fine-tuning, or models help. Avoid premature optimization, but account for production cost and speed. Participants also describe showing sources, allowing human edits, and giving regulated users several options instead of one definitive recommendation. The talk is candid about the gap between a convincing prototype and a system people can safely use.
Production requirements rise with the stakes of the answer
Rathle defines stakes as what a project can gain or lose from good and bad answers. At the low end, a business-peripheral task such as summarizing a children's bedtime story has no single correct answer. At the high end, an error can affect dollar value, brand reputation, health and human safety, regulation, or bias. A middle zone uses mitigations such as a human in the loop. He connects this spectrum to the difference between a pilot, which operates more independently, and a co-pilot, where a person remains involved. The higher the stakes, the tighter the acceptable error rate becomes.
Retrieval and graphs address different limits of language models
Rathle says retrieval augmented generation with vectors can bring enterprise and up-to-date domain knowledge into an application and can help with hallucinations. He also describes a further class of use cases where vectors are insufficient. Knowledge graphs and GraphRAG provide a more structured representation that people can understand and machines can reason over. Vector search represents an apple through proximity to other items, while a graph can represent facts and relationships. Rathle describes language models and vector-based retrieval as statistically driven, sometimes creative, and occasionally wrong without an obvious reason. Graphs add facts, reasoning, discernment, and long-term memory when combined with a language model.
Exact questions should use deterministic systems where possible
Rathle recommends locating the reasoning in the component that is suited to it. When a question has an exact answer, a language model's inherent non-determinism may be a poor fit by itself. Databases and other reasoning engines can produce the deterministic answer, while the language model translates a user's question into a query and turns the result back into text. The presentation can then change for its audience. Rathle gives the example of using a serious tone for a regulator and a different style for an outbound marketing email. The model handles language and presentation while another system handles the exact computation.
A model can write the reasoning code and then leave the loop
One participant describes asking a language model to write code for a task instead of asking it to solve the task directly. For an outlier-finding request, the model can generate Python or another machine-learning procedure, and the application can run that procedure outside the language-model loop. Rathle calls this a useful workaround for reasoning tasks the model may not perform reliably itself. The pattern separates generating a method from executing it. That can make the final operation more deterministic and easier to inspect than accepting the model's direct answer.
User behavior can invalidate a technically strong search experience
A participant explains that their team invested in retrieval, indexing, and semantic search, then discovered that customers still used keyword queries because that was how they had been trained to search. The team had to distinguish whether an input was really a keyword query or a natural-language question. Rathle draws out the lesson that teams need to understand how users will use a new capability before production. A technically capable interface does not automatically change user habits. The product may need to recognize familiar input patterns or teach people what the new system can do.
Teams should choose fewer projects and carry them through production
One participant says their team experimented with too many projects and would now focus on one or two that could reach production. Some experiments never met users' accuracy expectations, even with substantial effort. The selection process should consider both achievable performance and user value. Another participant warns that choosing the best model and fastest response without understanding the actual need can overspend. A small test set can encourage teams to select maximum accuracy, while production traffic can consume a year's budget in a day. The right model size and architecture depend on the required quality, speed, and cost.
A participant recommends building the evaluation pipeline at the same time as the application. Teams need to know from the start whether they have suitable data for evaluation. If the application reaches production before that data exists, they may be unable to tell whether a prompt change or fine-tuning improved or damaged the result. Generating evaluation data from day zero avoids a long delay later. Rathle connects this with the need for development, evaluation, and data practices that fit together. The participant's example involves extracting structured data with a language model before passing it to traditional machine-learning models.
Visible AI behavior gives users a reason to check the result
One team deliberately avoids hiding the AI from its users. It generates responses slowly as a signal that the user should pay attention, uses colors and icons to mark AI-related actions, and provides tools to inspect the answer's sources. Rathle says that seeing the response arrive can remind users that it came from a machine and should be considered carefully. In a behavioral-health setting, another participant shows source documentation beside a knowledge lookup and displays source data beside generated therapy-session summaries. Users can edit the summary, and the team also uses user feedback and clinical evaluation to assess outputs.
"If there's something if there's a question that has an exact answer and it's a deterministic question, then maybe you can use the LLM to complement some other technology that can give you a deterministic answer."07:02
Who should watch
You are moving a generative AI prototype toward production and need to decide how much accuracy, review, or explanation the application requires.
Your team is choosing models, retrieval methods, or evaluation practices without a clear view of cost, latency, user behavior, or the consequences of errors.
You build software in a regulated or sensitive area and need practical patterns for citations, user edits, human review, or multiple recommendations.
