GitHub Copilot gets smarter at finding your code: Inside our new embedding model

A new retrieval backbone for Copilot context search

GitHub has replaced the embedding model that powers context retrieval in Copilot chat and agentic modes within VS Code. The new model, trained specifically for code and documentation, targets a common failure point in AI coding assistants: pulling up near-miss snippets that look related but miss the developer's actual intent.

The update yields a 37.6% relative lift in retrieval quality, roughly 2x higher embedding throughput, and an 8x smaller index size. In practice, that means faster results, lower memory use in the editor, and snippets that more closely match the query.

Why embeddings matter for coding agents

Copilot's "find" step relies on embeddings — vector representations that allow it to fetch semantically relevant code, tests, docs, and error-handling logic even when exact keywords don't match. Higher-quality embeddings translate into better context, which is what makes agentic coding and chat responses more accurate. The gains show up in several common workflows:

• Searching for a test function inside a large monorepo
• Locating a helper method spread across multiple files
• Debugging questions such as "show me where this error string is handled"

Measured improvements

The new model improved an average retrieval score from 0.362 to 0.498 across a multi-benchmark evaluation. In production telemetry from VS Code, C# developers saw a +110.7% lift in code acceptance ratios, while Java developers saw +113.1%.

Efficiency also improved: throughput roughly doubled for a lower retrieval latency, and the index now uses about 8x less memory, easing scaling on client and server alike.

A concrete example highlights the difference. For the query "Which method is invoked to find a single namespace by its name within the project?", the top result from the current model correctly surfaces a findOne function. The previous model's top result returned a semantically similar but incorrect find function instead.

class Namespace extends K8Object {
  /*...*/
  static findOne(params = {}, options = {}) {
    return Model.findOne(params, options).then((namespace) => {
      console.log(namespace);
      if (namespace) {
        return new Namespace(namespace).setResourceVersion();
      }
    });
  }
  /*...*/
}

class Namespace extends K8Object {
  /*...*/
  static find(params = {}, options = {}) {
    return Model.find(params, options).then((namespaces) => {
      if (namespaces) {
        return Promise.all(
          namespaces.map((namespace) =>
            new Namespace(namespace).setResourceVersion()
          )
        );
      }
    });
  }
  /*...*/
}

Training approach

The team optimized retrieval quality for real developer workloads while holding latency and memory within budget. Training used contrastive learning with InfoNCE loss and Matryoshka Representation Learning, which helps the model tell nearly identical snippets apart while supporting multiple embedding sizes.

Hard negatives were a key ingredient: code examples that look plausible but don't answer the query. Since most code-search failures stem from these near misses, teaching the model to separate "almost right" from "actually right" drove the largest gains. The pipeline mined hard negatives from public GitHub plus Microsoft and GitHub internal repositories, and used LLMs to surface tricky close calls. That reduces shortcut learning and improves generalization.

For example, with the query "How is the stop word table populated?", the relevant sample shows the function that loads the table from a file. Functions that load words into a table, or read stop words from a file, serve as hard negatives because they don't answer the original question.

The top five programming languages in the training data were:

Benchmarks beyond a single test

Evaluation ran across multiple benchmarks covering four distinct retrieval scenarios:

• Natural language to code — answering NL queries with relevant functions and snippets
• Code to natural language — generating summaries that match code
• Code to code — finding similar functions, including refactored or translated versions
• Problems to code — mapping problem descriptions to suggested fixes

Roadmap

The new model is one step in improving retrieval reliability for daily development. Current and planned work includes:

• Expanding training and evaluation coverage to more languages and repositories
• Refining the hard-negative mining pipeline for higher-quality results
• Using the efficiency headroom to deploy larger, more accurate models