Posts in category: OpenAI

We’ve released new versions of GPT-3 and Codex which can edit or insert content into existing text, rather than just completing existing text. These new capabilities make it practical to use the OpenAI API to revise existing content, such as rewriting a paragraph of text or refactoring code. This unlocks new use cases and improves existing ones; for example, insertion is already being piloted in GitHub Copilot with promising early results.

def___

fib(10)

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n):
    if n 
fib(10)=>

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n =>

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n =>

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n =>

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n =>

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        if (n in memo) return memo[n];
        var f;
        if (n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        return n in memo ? memo[n] : (memo[n] = n =>

function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        return n in memo ? memo[n] : (memo[n] = n =>

/
function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        return n in memo ? memo[n] : (memo[n] = n =>

/**
function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        return n in memo ? memo[n] : (memo[n] = n =>

/**___
function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        return n in memo ? memo[n] : (memo[n] = n =>

/**​
 * Recursive Fibonacci function with memoization.
 * @param {number} n
 * @returns {number}
 */
function fibonacci(n) {
    var memo = {};
    return (function fib(n, memo) {
        return n in memo ? memo[n] : (memo[n] = n =>

GPT-3 and Codex have traditionally added text to the end of existing content, based on the text that came before. Whether working with text or code, writing is more than just appending—it’s an iterative process where existing text is revised. GPT-3 and Codex can now edit text, changing what’s currently there or adding text to the middle of content.

Inserting into the middle of text

The new insert capability adds contextually relevant text in the middle of existing content. Providing future context to the model can improve the quality of completions for applications such as writing long-form text, transitioning between paragraphs, following an outline, or guiding the model toward an ending.

In the example above, the desire is to fill-in text between two section headers of an outline. Without the context of future sections, the model generates a completion that isn’t relevant to the second section. When the context of future sections are accounted for, the model generates a completion that ties the two sections together.

def get_files(path: str, size: int):
    def___
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

def get_files(path: str, size: int):
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

def get_files(path: str, size: int):
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

___
def get_files(path: str, size: int):
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

import os
def get_files(path: str, size: int):
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

import os
def get_files(path: str, size: int):
    """
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

import os
def get_files(path: str, size: int):
    """___
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

import os
def get_files(path: str, size: int):
    """___"""
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

import os
def get_files(path: str, size: int):
    """Yields files in the path tree of min size"""
    def prune(dirp, files):
        for file in files:
            file = os.path.join(dirp, file)
            if os.path.getsize(file) > size:
                yield file
    for (dirp, _, files) in os.walk(path):
        yield from prune(dirp, files)

Insert is particularly useful for writing code. In fact, Codex was our original motivation for developing this capability, since in software development we typically add code to the middle of an existing file where code is present before and after the completion. In the example above, the model successfully completes the missing function prune, while connecting to code already written. We also add a docstring and missing imports, which is not possible without knowing the code that comes after. In GitHub Copilot, Insert is currently being piloted with early promising results.

The insert capability is available in the API today in beta, as part of the completions endpoint and via a new interface in Playground. The capability can be used with the latest versions of GPT-3 and Codex, text-davinci-002 and code-davinci-002. Pricing is the same as previous versions of Davinci.

Editing existing text

A meaningful part of writing text and code is spent editing existing content. We’ve released a new endpoint in beta called edits that changes existing text via an instruction, instead of completing it.

Editing works by specifying existing text as a prompt and an instruction on how to modify it. The edits endpoint can be used to change the tone or structure of text, or make targeted changes like fixing spelling. We’ve also observed edits to work well on empty prompts, thus enabling text generation similar to the completions endpoint. In the example above, we use edits to (1) add a poem, (2) change the poem to be in first-person, (3) transform the poem into a letter, with the appropriate salutation and signature.

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

The three US cities with the worst traffic are:

1. Boston, MA (164 hours)
2. Washington, DC (155 hours)
3. Chicago, IL (138 hours)

[
  {"rank": 1, "city": "Boston", "state": "MA", "hours": 164},
  {"rank": 2, "city": "Washington DC", "state": "DC", "hours": 155},
  {"rank": 3, "city": "Chicago", "state": "IL", "hours": 138}
]

[
  {"rank": 1, "city": "Boston", "state": "MA", "hours": 164},
  {"rank": 2, "city": "Washington DC", "state": "DC", "hours": 155},
  {"rank": 3, "city": "Chicago", "state": "IL", "hours": 138}
]

[
  {"rank": 1, "city": "Boston", "state": "MA", "hours": 164},
  {"rank": 2, "city": "Washington DC", "state": "DC", "hours": 155},
  {"rank": 3, "city": "Chicago", "state": "IL", "hours": 138}
]

[
  {"rank": 1, "city": "Boston", "state": "MA", "hours": 164},
  {"rank": 2, "city": "Washington DC", "state": "DC", "hours": 155},
  {"rank": 3, "city": "Chicago", "state": "IL", "hours": 138}
]

[
  {"rank": 1, "city": "Boston", "state": "MA", "hours": 164},
  {"rank": 2, "city": "Washington DC", "state": "DC", "hours": 155},
  {"rank": 3, "city": "Chicago", "state": "IL", "hours": 138}
]

[
  {"rank": 1, "city": "Boston", "state": "MA", "hours": 164},
  {"rank": 2, "city": "Washington DC", "state": "DC", "hours": 155},
  {"rank": 3, "city": "Chicago", "state": "IL", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

[
  {"city": "Boston", "state": "Massachusetts", "hours": 164},
  {"city": "Washington DC", "state": "District of Columbia", "hours": 155},
  {"city": "Chicago", "state": "Illinois", "hours": 138}
]

def get_yaml():
    return """
    - city: Boston
      state: Massachusetts
      hours: 164
    - city: Washington DC
      state: District of Columbia
      hours: 155
    - city: Chicago
      state: Illinois
      hours: 138
    """

The edits endpoint is particularly useful for writing code. It works well for tasks like refactoring, adding documentation, translating between programming languages, and changing coding style. The example above starts with JSON input containing cities ranked by population. With our first edit, Codex removes the rank field from the JSON, and changes the state abbreviations into full names. The second edit converts the JSON file into YAML returned from a function.

Editing is available as a specialized endpoint in the API and through a new interface in Playground. It is supported by models text-davinci-edits-001 and code-davinci-edits-001. The edits endpoint is currently free to use and publicly available as a beta.

OpenAI

The deployment of powerful AI systems has enriched our understanding of safety and misuse far more than would have been possible through research alone. Notably:

• API-based language model misuse often comes in different forms than we feared most.
• We have identified limitations in existing language model evaluations that we are addressing with novel benchmarks and classifiers.
• Basic safety research offers significant benefits for the commercial utility of AI systems.

Here, we describe our latest thinking in the hope of helping other AI developers address safety and misuse of deployed models.

Over the past two years, we’ve learned a lot about how language models can be used and abused—insights we couldn’t have gained without the experience of real-world deployment. In June 2020, we began giving access to developers and researchers to the OpenAI API, an interface for accessing and building applications on top of new AI models developed by OpenAI. Deploying GPT-3, Codex, and other models in a way that reduces risks of harm has posed various technical and policy challenges.

Overview of Our Model Deployment Approach

Large language models are now capable of performing a very wide range of tasks, often out of the box. Their risk profiles, potential applications, and wider effects on society remain poorly understood. As a result, our deployment approach emphasizes continuous iteration, and makes use of the following strategies aimed at maximizing the benefits of deployment while reducing associated risks:

• Pre-deployment risk analysis, leveraging a growing set of safety evaluations and red teaming tools (e.g., we checked our InstructGPT for any safety degradations using the evaluations discussed below)
• Starting with a small user base (e.g., both GPT-3 and our InstructGPT series began as private betas)
• Studying the results of pilots of novel use cases (e.g., exploring the conditions under which we could safely enable longform content generation, working with a small number of customers)
• Implementing processes that help keep a pulse on usage (e.g., review of use cases, token quotas, and rate limits)
• Conducting detailed retrospective reviews (e.g., of safety incidents and major deployments)

---

Note that this diagram is intended to visually convey the need for feedback loops in the continuous process of model development and deployment and the fact that safety must be integrated at each stage. It is not intended to convey a complete or ideal picture of our or any other organization’s process.

There is no silver bullet for responsible deployment, so we try to learn about and address our models’ limitations, and potential avenues for misuse, at every stage of development and deployment. This approach allows us to learn as much as we can about safety and policy issues at small scale and incorporate those insights prior to launching larger-scale deployments.

While not exhaustive, some areas where we’ve invested so far include^[1]:

• Pre-training data curation and filtering
• Fine-tuning models to better follow instructions
• Risk analysis of potential deployments
• Providing detailed user documentation
• Building tools to screen harmful model outputs
• Reviewing use cases against our policies
• Monitoring for signs of misuse
• Studying the impacts of our models

Since each stage of intervention has limitations, a holistic approach is necessary.

There are areas where we could have done more and where we still have room for improvement. For example, when we first worked on GPT-3, we viewed it as an internal research artifact rather than a production system and were not as aggressive in filtering out toxic training data as we might have otherwise been. We have invested more in researching and removing such material for subsequent models. We have taken longer to address some instances of misuse in cases where we did not have clear policies on the subject, and have gotten better at iterating on those policies. And we continue to iterate towards a package of safety requirements that is maximally effective in addressing risks, while also being clearly communicated to developers and minimizing excessive friction.

Still, we believe that our approach has enabled us to measure and reduce various types of harms from language model use compared to a more hands-off approach, while at the same time enabling a wide range of scholarly, artistic, and commercial applications of our models.^[2]

The Many Shapes and Sizes of Language Model Misuse

OpenAI has been active in researching the risks of AI misuse since our early work on the malicious use of AI in 2018 and on GPT-2 in 2019, and we have paid particular attention to AI systems empowering influence operations. We have worked with external experts to develop proofs of concept and promoted careful analysis of such risks by third parties. We remain committed to addressing risks associated with language model-enabled influence operations and recently co-organized a workshop on the subject.^[3]

Yet we have detected and stopped hundreds of actors attempting to misuse GPT-3 for a much wider range of purposes than producing disinformation for influence operations, including in ways that we either didn’t anticipate or which we anticipated but didn’t expect to be so prevalent.^[4] Our use case guidelines, content guidelines, and internal detection and response infrastructure were initially oriented towards risks that we anticipated based on internal and external research, such as generation of misleading political content with GPT-3 or generation of malware with Codex. Our detection and response efforts have evolved over time in response to real cases of misuse encountered “in the wild” that didn’t feature as prominently as influence operations in our initial risk assessments. Examples include spam promotions for dubious medical products and roleplaying of racist fantasies.

To support the study of language model misuse and mitigation thereof, we are actively exploring opportunities to share statistics on safety incidents this year, in order to concretize discussions about language model misuse.

The Difficulty of Risk and Impact Measurement

Many aspects of language models’ risks and impacts remain hard to measure and therefore hard to monitor, minimize, and disclose in an accountable way. We have made active use of existing academic benchmarks for language model evaluation and are eager to continue building on external work, but we have also have found that existing benchmark datasets are often not reflective of the safety and misuse risks we see in practice.^[5]

Such limitations reflect the fact that academic datasets are seldom created for the explicit purpose of informing production use of language models, and do not benefit from the experience gained from deploying such models at scale. As a result, we’ve been developing new evaluation datasets and frameworks for measuring the safety of our models, which we plan to release soon. Specifically, we have developed new evaluation metrics for measuring toxicity in model outputs and have also developed in-house classifiers for detecting content that violates our content policy, such as erotic content, hate speech, violence, harassment, and self-harm. Both of these in turn have also been leveraged for improving our pre-training data^[6]—specifically, by using the classifiers to filter out content and the evaluation metrics to measure the effects of dataset interventions.

Reliably classifying individual model outputs along various dimensions is difficult, and measuring their social impact at the scale of the OpenAI API is even harder. We have conducted several internal studies in order to build an institutional muscle for such measurement, but these have often raised more questions than answers.

We are particularly interested in better understanding the economic impact of our models and the distribution of those impacts. We have good reason to believe that the labor market impacts from the deployment of current models may be significant in absolute terms already, and that they will grow as the capabilities and reach of our models grow. We have learned of a variety of local effects to date, including massive productivity improvements on existing tasks performed by individuals like copywriting and summarization (sometimes contributing to job displacement and creation), as well as cases where the API unlocked new applications that were previously infeasible, such as synthesis of large-scale qualitative feedback. But we lack a good understanding of the net effects.

We believe that it is important for those developing and deploying powerful AI technologies to address both the positive and negative effects of their work head-on. We discuss some steps in that direction in the concluding section of this post.

The Relationship Between the Safety and Utility of AI Systems

In our Charter, published in 2018, we say that we “are concerned about late-stage AGI development becoming a competitive race without time for adequate safety precautions.” We then published a detailed analysis of competitive AI development, and we have closely followed subsequent research. At the same time, deploying AI systems via the OpenAI API has also deepened our understanding of the synergies between safety and utility.

For example, developers overwhelmingly prefer our InstructGPT models—which are fine-tuned to follow user intentions^[7]—over the base GPT-3 models. Notably, however, the InstructGPT models were not originally motivated by commercial considerations, but rather were aimed at making progress on long-term alignment problems. In practical terms, this means that customers, perhaps not surprisingly, much prefer models that stay on task and understand the user’s intent, and models that are less likely to produce outputs that are harmful or incorrect.^[8] Other fundamental research, such as our work on leveraging information retrieved from the Internet in order to answer questions more truthfully, also has potential to improve the commercial utility of AI systems.^[9]

These synergies will not always occur. For example, more powerful systems will often take more time to evaluate and align effectively, foreclosing immediate opportunities for profit. And a user’s utility and that of society may not be aligned due to negative externalities—consider fully automated copywriting, which can be beneficial for content creators but bad for the information ecosystem as a whole.

It is encouraging to see cases of strong synergy between safety and utility, but we are committed to investing in safety and policy research even when they trade off with commercial utility.

Ways to Get Involved

Each of the lessons above raises new questions of its own. What kinds of safety incidents might we still be failing to detect and anticipate? How can we better measure risks and impacts? How can we continue to improve both the safety and utility of our models, and navigate tradeoffs between these two when they do arise?

We are actively discussing many of these issues with other companies deploying language models. But we also know that no organization or set of organizations has all the answers, and we would like to highlight several ways that readers can get more involved in understanding and shaping our deployment of state of the art AI systems.

First, gaining first-hand experience interacting with state of the art AI systems is invaluable for understanding their capabilities and implications. We recently ended the API waitlist after building more confidence in our ability to effectively detect and respond to misuse. Individuals in supported countries and territories can quickly get access to the OpenAI API by signing up here.

Second, researchers working on topics of particular interest to us such as bias and misuse, and who would benefit from financial support, can apply for subsidized API credits using this form. External research is vital for informing both our understanding of these multifaceted systems, as well as wider public understanding.

Finally, today we are publishing a research agenda exploring the labor market impacts associated with our Codex family of models, and a call for external collaborators on carrying out this research. We are excited to work with independent researchers to study the effects of our technologies in order to inform appropriate policy interventions, and to eventually expand our thinking from code generation to other modalities.

If you’re interested in working to responsibly deploy cutting-edge AI technologies, apply to work at OpenAI!

OpenAI

We are introducing embeddings, a new endpoint in the OpenAI API that makes it easy to perform natural language and code tasks like semantic search, clustering, topic modeling, and classification. Embeddings are numerical representations of concepts converted to number sequences, which make it easy for computers to understand the relationships between those concepts. Our embeddings outperform top models in 3 standard benchmarks, including a 20% relative improvement in code search.

Embeddings are useful for working with natural language and code, because they can be readily consumed and compared by other machine learning models and algorithms like clustering or search.

Embeddings that are numerically similar are also semantically similar. For example, the embedding vector of “canine companions say” will be more similar to the embedding vector of “woof” than that of “meow.”

The new endpoint uses neural network models, which are descendants of GPT-3, to map text and code to a vector representation—“embedding” them in a high-dimensional space. Each dimension captures some aspect of the input.

The new /embeddings endpoint in the OpenAI API provides text and code embeddings with a few lines of code:

import openai
response = openai.Embedding.create(
    input="canine companions say",
    engine="text-similarity-davinci-001")

print(response)
{
  "data": [
    {
      "embedding": [
        0.000108064,
        0.005860855,
        -0.012656143,
        ...
        -0.006642727,
        0.002583989,
        -0.012567150
      ],
      "index": 0,
      "object": "embedding"
    }
  ],
  "model": "text-similarity-babbage:001",
  "object": "list"
}

We’re releasing three families of embedding models, each tuned to perform well on different functionalities: text similarity, text search, and code search. The models take either text or code as input and return an embedding vector.

Text Similarity Models

Text similarity models provide embeddings that capture the semantic similarity of pieces of text. These models are useful for many tasks including clustering, data visualization, and classification.

The following interactive visualization shows embeddings of text samples from the DBpedia dataset:

To compare the similarity of two pieces of text, you simply use the dot product on the text embeddings. The result is a “similarity score”, sometimes called “cosine similarity,” between 0 and 1, where a higher number means more similarity. In most applications, the embeddings can be pre-computed, and then the dot product comparison is extremely fast to carry out.

import openai, numpy as np

resp = openai.Embedding.create(
    input=["feline friends go", "meow"],
    engine="text-similarity-davinci-001")

embedding_a = resp['data'][0]['embedding']
embedding_b = resp['data'][1]['embedding']

similarity_score = np.dot(embedding_a, embedding_b)

One popular use of embeddings is to use them as features in machine learning tasks, such as classification. In machine learning literature, when using a linear classifier, this classification task is called a “linear probe.” Our text similarity models achieve new state-of-the-art results on linear probe classification in SentEval (Conneau et al., 2018), a commonly used benchmark for evaluating embedding quality.

Text Search Models

Text search models provide embeddings that enable large-scale search tasks, like finding a relevant document among a collection of documents given a text query. Embedding for the documents and query are produced separately, and then cosine similarity is used to compare the similarity between the query and each document.

Embedding-based search can generalize better than word overlap techniques used in classical keyword search, because it captures the semantic meaning of text and is less sensitive to exact phrases or words. We evaluate the text search model’s performance on the BEIR (Thakur, et al. 2021) search evaluation suite and obtain better search performance than previous methods. Our text search guide provides more details on using embeddings for search tasks.

Code Search Models

Code search models provide code and text embeddings for code search tasks. Given a collection of code blocks, the task is to find the relevant code block for a natural language query. We evaluate the code search models on the CodeSearchNet (Husian et al., 2019) evaluation suite where our embeddings achieve significantly better results than prior methods. Check out the code search guide to use embeddings for code search.

Examples of the Embeddings API in Action

JetBrains Research

JetBrains Research’s Astroparticle Physics Lab analyzes data like The Astronomer’s Telegram and NASA’s GCN Circulars, which are reports that contain astronomical events that can’t be parsed by traditional algorithms.

Powered by OpenAI’s embeddings of these astronomical reports, researchers are now able to search for events like “crab pulsar bursts” across multiple databases and publications. Embeddings also achieved 99.85% accuracy on data source classification through k-means clustering.

FineTune Learning

FineTune Learning is a company building hybrid human-AI solutions for learning, like adaptive learning loops that help students reach academic standards.

OpenAI’s embeddings significantly improved the task of finding textbook content based on learning objectives. Achieving a top-5 accuracy of 89.1%, OpenAI’s text-search-curie embeddings model outperformed previous approaches like Sentence-BERT (64.5%). While human experts are still better, the FineTune team is now able to label entire textbooks in a matter of seconds, in contrast to the hours that it took the experts.

Fabius

Fabius helps companies turn customer conversations into structured insights that inform planning and prioritization. OpenAI’s embeddings allow companies to more easily find and tag customer call transcripts with feature requests.

For instance, customers might use words like “automated” or “easy to use” to ask for a better self-service platform. Previously, Fabius was using fuzzy keyword search to attempt to tag those transcripts with the self-service platform label. With OpenAI’s embeddings, they’re now able to find 2x more examples in general, and 6x–10x more examples for features with abstract use cases that don’t have a clear keyword customers might use.

All API customers can get started with the embeddings documentation for using embeddings in their applications.

Read documentation

OpenAI