Anish Shah and Morgan McGuire use LLMs for contained tasks such as documentation translation, code suggestions, data cleanup, and internal support rather than forcing them into every product workflow.
2
Anish Shah evaluates models across multiple tasks and datasets, while Morgan McGuire stresses that retrieval quality and final answer quality can move in different directions.
3
Their Weights & Biases support bot evaluation started from real user questions, with clustered queries forming a smaller, higher-quality evaluation set that they plan to make harder as performance improves.
Summary
Anish Shah and Morgan McGuire describe their work on the growth team at Weights & Biases, which combines machine learning engineering, user support, education, integrations, and community work. They discuss practical LLM uses, including documentation translation, pre-written code, dirty-data cleanup, and Wanbot, an internal support bot that retrieves information from Weights & Biases documentation. Their central concern is whether an LLM solves a real task well. They explain why benchmark scores can mislead when datasets have leaked into training data or when teams optimize for one narrow result. For retrieval systems, they track context precision, context recall, faithfulness, relevancy, and answer correctness. A model update lowered context precision while improving final answers because it could ignore poor retrieved context. The guests also describe building evaluations from real user queries and debate whether evaluation or hallucination mitigation could become an external service. They remain cautious about services that hide their data and methods.
The growth team combines education, community work, and hands-on ML engineering
Morgan McGuire explains that the growth team began with local events, blog content, integrations, and examples. It later added a courses program focused on delivering useful machine learning education. The team also joins user calls, helps with debugging, and shares information about new models and architectures with the product group. Anish Shah adds that the team watches what the community builds with or without Weights & Biases, then turns those real projects into useful material. Their work sits between internal engineering and external developer relations, with direct contact with users and practitioners.
LLMs are most useful when they solve a defined task
Anish Shah describes several contained uses for LLMs at Weights & Biases. They help create better documentation translations, draft pull requests with code in the right places, and provide a starting point for internal work. Wanbot handles questions about proprietary Weights & Biases knowledge by using retrieval over public-facing documentation and other data sources. Morgan McGuire says the team is still looking for strong product use cases and sees many shorter-term gains in back-office productivity. They avoid adding an LLM only because a product needs an AI feature, since a chatbot can still misunderstand users or hallucinate.
Small production uses build practical experience and credibility
Morgan McGuire says the team wants to build experience with real LLM applications rather than toy examples based on the latest open-source model. One example standardizes countries submitted through user-facing forms. GPT-4 maps inconsistent values such as 'USA' to 'United States of America' and handles values such as 'Antarctica' according to the team's desired category. Morgan calls the task overkill for GPT-4, but says it works better than complicated regular expressions or manual correction at their request volume. Anish Shah connects these production examples to credibility because the team can point to systems they actually put into use.
Anish Shah questions how much confidence teams should place in standard benchmarks when evaluation data may have appeared in training data. He recommends covering multiple topics, datasets, and tasks instead of optimizing for one benchmark result. He mentions the LLM Evaluation Harness and describes radar-style views that compare models across a consistent collection of datasets. Morgan McGuire adds that developers may choose a model from a leaderboard without understanding what metrics such as MMLU measure. Leaderboards can also be gamed accidentally or deliberately. A serious evaluation process therefore needs task-specific data and repeated checks that the data remains valid.
Retrieval metrics can fall while final answers improve
While evaluating Wanbot, the team tracked more than answer correctness. They also measured how well the retriever selected useful context. When they moved from the November GPT Turbo preview to the January preview, context precision fell while answer correctness improved. Morgan McGuire explains that the newer model could recognize when retrieved documentation was weak or irrelevant and answer from knowledge already present in the model. That result looked positive in the final metric, yet it did not prove that the retrieval system had improved. The team needs to inspect individual samples and should not depend on future models already knowing all of their documentation.
Real user questions provide a better evaluation set
Morgan McGuire describes an evaluation set built from questions asked in the wild. The team clustered the queries, selected representative questions, and initially created about 130 or 140 examples. Later, they removed duplicated or less relevant items and reduced the set to 98 higher-quality questions. Performance moved from about 50% to about 80%, with a goal above 90%. Anish Shah says this process uses ordinary user-data mining techniques. A support application should reflect the topics people actually ask about. Morgan also says the evaluation must become harder as scores rise, since a high score can look good while leaving difficult cases unresolved.
Anish Shah says the team uses retrieval evaluation to learn about its documentation as well as its model. Wanbot runs in a Slack channel, where people can see when an answer is outdated or when the system retrieved the wrong material. If the relevant context does not exist, the failure may point to missing documentation. This gives the team a way to update docs based on actual questions and responses. The guests also discuss answers that produce working code through an inferior workaround. Demetrios Brinkmann considers that answer incorrect if the recommended API method was missed, showing that evaluation depends on the product phase and the quality standard the team has chosen.
Evaluation services need visible methods and credible data
Anish Shah is skeptical of evaluation-as-a-service when customers cannot inspect the underlying data. He says machine learning engineers and security teams will struggle to trust a score from a service that only describes its dataset on a marketing page. A collaborative model review would be more convincing, especially if the service could create synthetic evaluation data for a customer's use case and explain where the model performs poorly. The discussion extends this idea to hallucination mitigation. Morgan McGuire cites a paper that organizes 32 mitigation techniques, while Anish Shah imagines a harness that tests those methods against generated or synthetic data.
