As Vice President of Research at OpenAI, Mia Glaese leads teams focused on model alignment, human data, and capability evaluations. She develops practical methods to test AI safety and performance, including factuality benchmarks, policy adherence tests, and audits of coding datasets for contamination. This profile covers how she spots bad evaluations, gets models to cite evidence, and monitors frontier risks.

Part 1: Evaluating Code Generation Models

  1. On Benchmark Saturation: When frontier model scores cluster above 80 percent and progress increments shrink to tiny fractions, the evaluation tool no longer effectively measures coding ability and instead measures statistical noise. — Reference: Latent Space
  2. On Flawed Test Specifications: Many persistent failures in software engineering benchmarks stem from poorly defined tests, such as those that reject correct code due to narrow naming expectations or those that search for features never mentioned in the problem description. — Reference: Latent Space
  3. On Moving to Harder Benchmarks: As older coding benchmarks saturate, the industry should transition to harder, more diverse alternatives like SWE-Bench Pro, which contains longer tasks and spans multiple programming languages and repositories. — Reference: Latent Space
  4. On Future Coding Evaluations: Next-generation benchmarks for code generation need to move beyond simple pass-fail checks to evaluate long-term tasks, open-ended design decisions, code quality, and maintainability. — Reference: Spotify Podcast
  5. On the Lifecycle of Benchmarks: Even evaluations that eventually saturate and suffer from contamination are highly valuable during their prime, as they provide the industry with a standardized metric for improvement until model capabilities outgrow them. — Reference: Latent Space
  6. On Auditing Unsolved Problems: When models consistently fail specific benchmark tasks, developers should have human experts deeply review those specific failures to determine if the test itself is unsolvable or unfairly specified. — Reference: Latent Space
  7. On Contextual Problem Reviews: Cleaning up complex benchmarks requires software engineers to review problems in the context of the entire codebase, rather than simply analyzing the code patch in isolation. — Reference: Wave AI Notes
  8. On Multi-Expert Review Costs: Reviewing complex software engineering problems is a highly complex task that justifies tripling evaluation costs to ensure multiple domain experts independently verify the validity of tasks. — Reference: Wave AI Notes

Part 2: Identifying Benchmark Contamination

  1. On Detecting Contamination: Contamination can be identified by using an auditor agent that asks models open-ended questions about task descriptions to see if they can recall repository-specific details or gold patches from memory. — Reference: SignalCast Summary
  2. On Chain-of-Thought Auditing: Reading a model's internal reasoning can expose training data leakage, such as when a model spontaneously uses specific historical repository arguments that were never provided in the prompt. — Reference: Wave AI Notes
  3. On Open-Source Data Leakage: Relying on popular open-source repositories for benchmarks makes models highly susceptible to contamination, because these repositories are frequently included in pre-training datasets without intentional cheating. — Reference: Wave AI Notes
  4. On the Limits of Canaries: Standard canary strings are insufficient for protecting benchmark datasets if the evaluation tasks are sourced directly from public repositories that are scraped for training data. — Reference: Wave AI Notes

Part 3: Assessing Model Factuality

  1. On Evaluating Short Queries: Factuality is inherently difficult to measure on long generations, so focusing a benchmark on short, fact-seeking queries provides a much more tractable and reliable evaluation method. — Reference: OpenAI SimpleQA
  2. On Question Verification: Creating a high-quality factuality dataset requires ensuring that each question has a single, indisputable answer that does not change over time, and verifying the answer with multiple independent human trainers. — Reference: OpenAI SimpleQA
  3. On Measuring Calibration: By asking a model to state its confidence as a percentage along with its guess, developers can plot the correlation between stated confidence and actual accuracy to see if the model knows its own limitations. — Reference: OpenAI SimpleQA
  4. On Frequency as Confidence: An alternative way to measure model calibration is to ask the same question repeatedly; a well-calibrated model's accuracy will correspond to how frequently it produces the same answer. — Reference: OpenAI SimpleQA
  5. On Reasoning and Hallucinations: Models designed with extended reasoning capacity tend to abstain from attempting questions they do not know, reducing hallucinations compared to standard models that guess. — Reference: OpenAI SimpleQA
  6. On Model Overconfidence: Despite showing positive correlations between stated confidence and correctness, large language models consistently overstate their confidence across various tests, revealing significant room for improvement in self-calibration. — Reference: OpenAI SimpleQA

Part 4: Teaching Models to Cite Evidence

  1. On Grounding AI Claims: Users cannot implicitly trust factual claims made by large language models, necessitating systems that can generate answers while explicitly citing specific evidence to allow for human fact-checking. — Reference: arXiv Paper
  2. On Human Preferences for Citing: Reinforcement learning from human preferences can successfully train models to operate in an open-book setting, fetching and quoting from external documents to support their responses. — Reference: arXiv Paper
  3. On the Abstention Strategy: A model's overall correctness improves significantly when it is trained to abstain from answering questions where it feels unsure, approaching human baselines in factual reliability. — Reference: arXiv Paper
  4. On the Limitations of Evidence: While citing evidence helps evaluate correctness, it is not a complete safety solution, as models can still find and quote external claims that are fundamentally untrue. — Reference: arXiv Paper

Part 5: Understanding Ethical and Social Risks

  1. On Risk Taxonomies: The ethical risks of large language models can be structured into areas including discrimination and toxicity, information hazards, misinformation, malicious use, human-computer interaction harms, and environmental impacts. — Reference: arXiv Paper
  2. On Information Hazards: Models present significant privacy risks, including the potential leakage of private data or the unauthorized inference of sensitive information about individuals based on seemingly benign inputs. — Reference: arXiv Paper
  3. On Interaction Harms: Conversational agents built on large language models carry unique risks for users, including the potential for deception, manipulation, or unsafe attachment during interactions. — Reference: arXiv Paper
  4. On Broad Societal Impacts: Beyond immediate output harms, language models pose systemic challenges such as job automation, environmental degradation from computing resources, and disparate impacts on specific communities. — Reference: arXiv Paper

Part 6: Defining Model Specifications

  1. On Policy Specification: Creating a comprehensive document that guides how a model should handle conflicting instructions, sensitive topics, and default behaviors serves as a fundamental north star for ongoing alignment work. — Reference: OpenAI Model Spec Evals
  2. On Measuring Adherence: A dedicated evaluation suite can measure how well a model follows its defined behavioral specification, complementing traditional safety tests that focus solely on direct harms. — Reference: OpenAI Model Spec Evals
  3. On Using Grader Models: Checking specification adherence can be automated by having a powerful reasoning model evaluate the target model's response against the core policy and a prompt-specific rubric. — Reference: OpenAI Model Spec Evals
  4. On Reasoning for Compliance: Models equipped with explicit reasoning capabilities consistently show higher compliance with complex behavioral guidelines than non-reasoning models from the same generation. — Reference: OpenAI Model Spec Evals
  5. On the Resolution of Evaluations: Initial specification evaluations often provide a zoomed-out view by testing straightforward scenarios, requiring continuous expansion to handle adversarial prompts and broader contexts like images or agents. — Reference: OpenAI Model Spec Evals

Part 7: Unsupervised Learning and Model EQ

  1. On the Role of Unsupervised Learning: Scaling up unsupervised learning increases a model's intuition and general world knowledge, which in turn helps to naturally reduce hallucination rates. — Reference: YouTube GPT-4.5
  2. On Synthetic Data Generation: Using data derived from smaller models to train larger ones unlocks deeper world models and allows for more scalable alignment techniques. — Reference: YouTube GPT-4.5
  3. On Emotional Intelligence: Fine-tuning can align a model to be a better collaborator by teaching it to pick up on emotional cues, resulting in responses that feel warmer and more nuanced rather than purely robotic. — Reference: YouTube GPT-4.5
  4. On Training Ratios: As models grow significantly larger, the ratio between the training data and the parameter size shifts drastically from the pre-training to the post-training stages, requiring entirely new optimization mechanisms to fine-tune effectively. — Reference: YouTube GPT-4.5

Part 8: Tracking Frontier Risks

  1. On Identifying Capabilities: Anticipating the impact of advanced AI requires tracking frontier capabilities that are inherently dual-use, ensuring that organizations can prepare for both their beneficial applications and potential downsides. — Reference: Castbox Podcast
  2. On Categories of Concern: A structured preparedness framework should monitor specific high-impact risk domains such as biological threats, cybersecurity vulnerabilities, and the capability of models to automate scientific research. — Reference: Castbox Podcast
  3. On the Evolution of Autonomy: Early evaluations for model autonomy focused on coding benchmarks like SWE-Bench, but measuring true autonomy must expand to see if models can handle the complete workflows of actual researchers. — Reference: Latent Space
  4. On Open Collaboration: Tracking the capabilities and risks of AI requires building and sharing benchmarks openly, encouraging the entire field to contribute new evaluations to better understand where model progress is heading. — Reference: Latent Space