<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/feed.rss.xml" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Matthew Honnibal</title>
    <description>Matthew Honnibal is the co-founder of &lt;a href="https://explosion.ai" target="_blank"&gt;Explosion&lt;/a&gt; and a leading expert in AI technology, known for his research, software and writings. He completed his PhD in 2009, and spent a further 5 years publishing research on state-of-the-art natural language understanding systems. Anticipating the AI boom, he left academia in 2014 to develop &lt;a href="https://spacy.io" target="_blank"&gt;spaCy&lt;/a&gt;, a popular open-source library for industrial-strength Natural Language Processing.</description>
    <link>https://speakerdeck.com/honnibal</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/honnibal.rss"/>
    <lastBuildDate>2018-07-08 17:36:05 -0400</lastBuildDate>
    <item>
      <title>Practical Tips for Bootstrapping Information Extraction Pipelines</title>
      <description>In this presentation, I will build on &lt;a href="https://speakerdeck.com/inesmontani" target="_blank"&gt;Ines Montani&lt;/a&gt;'s keynote, "Applied NLP in the Age of Generative AI", by demonstrating how to create an information extraction pipeline. The talk will focus on using the &lt;a href="https://spacy.io" target="_blank"&gt;spaCy&lt;/a&gt; NLP library and the &lt;a href="https://prodi.gy" target="_blank"&gt;Prodigy&lt;/a&gt; annotation tool, although the principles discussed will also apply to other frameworks.</description>
      <media:content url="https://files.speakerdeck.com/presentations/54fc3834d25b459ba88d3753cc949901/preview_slide_0.jpg?31304006" type="image/jpeg" medium="image"/>
      <content:encoded>In this presentation, I will build on &lt;a href="https://speakerdeck.com/inesmontani" target="_blank"&gt;Ines Montani&lt;/a&gt;'s keynote, "Applied NLP in the Age of Generative AI", by demonstrating how to create an information extraction pipeline. The talk will focus on using the &lt;a href="https://spacy.io" target="_blank"&gt;spaCy&lt;/a&gt; NLP library and the &lt;a href="https://prodi.gy" target="_blank"&gt;Prodigy&lt;/a&gt; annotation tool, although the principles discussed will also apply to other frameworks.</content:encoded>
      <pubDate>Fri, 09 Aug 2024 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/practical-tips-for-bootstrapping-information-extraction-pipelines</link>
      <guid>https://speakerdeck.com/honnibal/practical-tips-for-bootstrapping-information-extraction-pipelines</guid>
    </item>
    <item>
      <title>Designing for tomorrow's programming workflows</title>
      <description>&lt;strong&gt;Video:&lt;/strong&gt; https://www.youtube.com/watch?v=6t80gIb-HBI

New tools are changing how people program, and even who programs. Type hints, modern editor support and, more recently, AI-powered tools like GitHub Copilot and ChatGPT are truly transforming our workflows and improving developer productivity. But what does this mean for how we should be writing and designing our APIs and libraries?

In this talk, I'll share what I've learned from developing open-source tools used by thousands of developers, strategies for how to design future-proof developer APIs and why, contrary to what you might think, making tools programmable is becoming even more important, not less.

If how people program is changing, how should we adjust how we’re designing our APIs, whether they’re Python, REST or some other technology? In this talk, I’ll suggest three implications.

First, programmatic interfaces are becoming more accessible. More professional tools can be optionally programmable, and more users will be able to take advantage of that feature to make their tasks more reliable and less repetitive.

Second, libraries can lean more towards composable building blocks, instead of offering a large flat surface of entry point functions. Guiding users through multi-step workflows is hard, so a "horizontal" design with lots of all-in-one functions can be easier to adopt from documentation. But the horizontal design is also harder for users to extend and debug. Generative AI tools can help address the learning curve problem, and give users more control.

Third, backwards compatibility will be more important than ever. Evolving versions already made it much harder to find usage from sites such as StackOverflow, and it causes an even bigger problem for current generative AI technologies. This is another point in favour of composable building blocks, as it's much harder to maintain backwards compatibility for a horizontal API style.</description>
      <media:content url="https://files.speakerdeck.com/presentations/52c5bcdfdec24ae3a205548a29ceb0d1/preview_slide_0.jpg?29604663" type="image/jpeg" medium="image"/>
      <content:encoded>&lt;strong&gt;Video:&lt;/strong&gt; https://www.youtube.com/watch?v=6t80gIb-HBI

New tools are changing how people program, and even who programs. Type hints, modern editor support and, more recently, AI-powered tools like GitHub Copilot and ChatGPT are truly transforming our workflows and improving developer productivity. But what does this mean for how we should be writing and designing our APIs and libraries?

In this talk, I'll share what I've learned from developing open-source tools used by thousands of developers, strategies for how to design future-proof developer APIs and why, contrary to what you might think, making tools programmable is becoming even more important, not less.

If how people program is changing, how should we adjust how we’re designing our APIs, whether they’re Python, REST or some other technology? In this talk, I’ll suggest three implications.

First, programmatic interfaces are becoming more accessible. More professional tools can be optionally programmable, and more users will be able to take advantage of that feature to make their tasks more reliable and less repetitive.

Second, libraries can lean more towards composable building blocks, instead of offering a large flat surface of entry point functions. Guiding users through multi-step workflows is hard, so a "horizontal" design with lots of all-in-one functions can be easier to adopt from documentation. But the horizontal design is also harder for users to extend and debug. Generative AI tools can help address the learning curve problem, and give users more control.

Third, backwards compatibility will be more important than ever. Evolving versions already made it much harder to find usage from sites such as StackOverflow, and it causes an even bigger problem for current generative AI technologies. This is another point in favour of composable building blocks, as it's much harder to maintain backwards compatibility for a horizontal API style.</content:encoded>
      <pubDate>Thu, 04 Apr 2024 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/designing-for-tomorrows-programming-workflows</link>
      <guid>https://speakerdeck.com/honnibal/designing-for-tomorrows-programming-workflows</guid>
    </item>
    <item>
      <title>How many Labelled Examples do you need for a BERT-sized Model to Beat GPT-4 on Predictive Tasks?</title>
      <description>&lt;strong&gt;Video:&lt;/strong&gt; https://www.youtube.com/watch?v=3iaxLTKJROc

Large Language Models (LLMs) offer a new machine learning interaction paradigm: in-context learning. This approach is clearly much better than approaches that rely on explicit labelled data for a wide variety of generative tasks (e.g. summarisation, question answering, paraphrasing). In-context learning can also be applied to predictive tasks such as text categorization and entity recognition, with few or no labelled exemplars.

But how does in-context learning actually compare to supervised approaches on those tasks? The key advantage is you need less data, but how many labelled examples do you need on different problems before a BERT-sized model can beat GPT4 in accuracy?

The answer might surprise you: models with fewer than 1b parameters are actually very good at classic predictive NLP, while in-context learning struggles on many problem shapes — especially tasks with many labels or that require structured prediction. Methods of improving in-context learning accuracy involve increasing trade-offs of speed for accuracy, suggesting that distillation and LLM-guided annotation will be the most practical approaches.

Implementation of this approach is discussed with reference to the &lt;a href="https://spacy.io" target="_blank"&gt;spaCy&lt;/a&gt; open-source library and the &lt;a href="https://prodi.gy" target="_blank"&gt;Prodigy&lt;/a&gt; annotation tool.</description>
      <media:content url="https://files.speakerdeck.com/presentations/29dbc12e80ac4b3b926a382c4ff26a63/preview_slide_0.jpg?27549396" type="image/jpeg" medium="image"/>
      <content:encoded>&lt;strong&gt;Video:&lt;/strong&gt; https://www.youtube.com/watch?v=3iaxLTKJROc

Large Language Models (LLMs) offer a new machine learning interaction paradigm: in-context learning. This approach is clearly much better than approaches that rely on explicit labelled data for a wide variety of generative tasks (e.g. summarisation, question answering, paraphrasing). In-context learning can also be applied to predictive tasks such as text categorization and entity recognition, with few or no labelled exemplars.

But how does in-context learning actually compare to supervised approaches on those tasks? The key advantage is you need less data, but how many labelled examples do you need on different problems before a BERT-sized model can beat GPT4 in accuracy?

The answer might surprise you: models with fewer than 1b parameters are actually very good at classic predictive NLP, while in-context learning struggles on many problem shapes — especially tasks with many labels or that require structured prediction. Methods of improving in-context learning accuracy involve increasing trade-offs of speed for accuracy, suggesting that distillation and LLM-guided annotation will be the most practical approaches.

Implementation of this approach is discussed with reference to the &lt;a href="https://spacy.io" target="_blank"&gt;spaCy&lt;/a&gt; open-source library and the &lt;a href="https://prodi.gy" target="_blank"&gt;Prodigy&lt;/a&gt; annotation tool.</content:encoded>
      <pubDate>Wed, 25 Oct 2023 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/how-many-labelled-examples-do-you-need-for-a-bert-sized-model-to-beat-gpt-4-on-predictive-tasks</link>
      <guid>https://speakerdeck.com/honnibal/how-many-labelled-examples-do-you-need-for-a-bert-sized-model-to-beat-gpt-4-on-predictive-tasks</guid>
    </item>
    <item>
      <title>spaCy meets Transformers</title>
      <description>Huge transformer models like BERT, GPT-2 and XLNet have set a new standard for accuracy on almost every Natural Language Processing leaderboard. However, these models are very new, and most of the software ecosystem surrounding them is oriented towards the many opportunities for further research that they provide. In this talk, I’ll describe how you can now use these models in spaCy, a popular library for putting Natural Language Processing to work on real problems. I’ll also discuss the many opportunities that new transfer learning technologies can offer production NLP, regardless of which specific software packages you choose to get the job done.</description>
      <media:content url="https://files.speakerdeck.com/presentations/529734e8b61647e984fccac98d2a4b7f/preview_slide_0.jpg?13857866" type="image/jpeg" medium="image"/>
      <content:encoded>Huge transformer models like BERT, GPT-2 and XLNet have set a new standard for accuracy on almost every Natural Language Processing leaderboard. However, these models are very new, and most of the software ecosystem surrounding them is oriented towards the many opportunities for further research that they provide. In this talk, I’ll describe how you can now use these models in spaCy, a popular library for putting Natural Language Processing to work on real problems. I’ll also discuss the many opportunities that new transfer learning technologies can offer production NLP, regardless of which specific software packages you choose to get the job done.</content:encoded>
      <pubDate>Sat, 12 Oct 2019 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/spacy-meets-transformers</link>
      <guid>https://speakerdeck.com/honnibal/spacy-meets-transformers</guid>
    </item>
    <item>
      <title>Building new NLP solutions with spaCy and Prodigy</title>
      <description>Commercial machine learning projects are currently like start-ups: many projects fail, but some are extremely successful, justifying the total investment. While some people will tell you to "embrace failure", I say failure sucks — so what can we do to fight it? In this talk, I will discuss how to address some of the most likely causes of failure for new Natural Language Processing (NLP) projects. My main recommendation is to take an iterative approach: don't assume you know what your pipeline should look like, let alone your annotation schemes or model architectures. I will also discuss a few tips for figuring out what's likely to work, along with a few common mistakes. To keep the advice well-grounded, I will refer specifically to our open-source library spaCy, and our commercial annotation tool Prodigy.</description>
      <media:content url="https://files.speakerdeck.com/presentations/fd68c02c13a04ae88853e68b68254262/preview_slide_0.jpg?10363293" type="image/jpeg" medium="image"/>
      <content:encoded>Commercial machine learning projects are currently like start-ups: many projects fail, but some are extremely successful, justifying the total investment. While some people will tell you to "embrace failure", I say failure sucks — so what can we do to fight it? In this talk, I will discuss how to address some of the most likely causes of failure for new Natural Language Processing (NLP) projects. My main recommendation is to take an iterative approach: don't assume you know what your pipeline should look like, let alone your annotation schemes or model architectures. I will also discuss a few tips for figuring out what's likely to work, along with a few common mistakes. To keep the advice well-grounded, I will refer specifically to our open-source library spaCy, and our commercial annotation tool Prodigy.</content:encoded>
      <pubDate>Sat, 07 Jul 2018 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/building-new-nlp-solutions-with-spacy-and-prodigy</link>
      <guid>https://speakerdeck.com/honnibal/building-new-nlp-solutions-with-spacy-and-prodigy</guid>
    </item>
    <item>
      <title>Multi-lingual natural language understanding with spaCy</title>
      <description>spaCy is a popular open-source Natural Language Processing library designed for practical usage. In this talk, I'll outline the new parsing model we've been developing to improve spaCy's support for more languages and text types. Like other transition-based parsers, the model predicts a sequence of actions that push tokens to and from a stack and build arcs between them. However, we expect the arc-eager system with actions that can also repair previous parse errors, introduce sentence boundaries, and split or merge the pre-segmented tokens. The joint approach improves parse accuracy on many types of text, especially for non-whitespace writing systems. We have also found significant practical advantage to short pipelines. Short pipelines are easier to reason about, and increase runtime flexibility by reducing the risk of train/test skew.</description>
      <media:content url="https://files.speakerdeck.com/presentations/fec2db47a6c3452b9210e43b88d09ec7/preview_slide_0.jpg?10363257" type="image/jpeg" medium="image"/>
      <content:encoded>spaCy is a popular open-source Natural Language Processing library designed for practical usage. In this talk, I'll outline the new parsing model we've been developing to improve spaCy's support for more languages and text types. Like other transition-based parsers, the model predicts a sequence of actions that push tokens to and from a stack and build arcs between them. However, we expect the arc-eager system with actions that can also repair previous parse errors, introduce sentence boundaries, and split or merge the pre-segmented tokens. The joint approach improves parse accuracy on many types of text, especially for non-whitespace writing systems. We have also found significant practical advantage to short pipelines. Short pipelines are easier to reason about, and increase runtime flexibility by reducing the risk of train/test skew.</content:encoded>
      <pubDate>Sun, 15 Apr 2018 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/multi-lingual-natural-language-understanding-with-spacy</link>
      <guid>https://speakerdeck.com/honnibal/multi-lingual-natural-language-understanding-with-spacy</guid>
    </item>
    <item>
      <title>Embed, encode, attend, predict: A four-step framework for understanding neural network approaches to Natural Language Understanding problems</title>
      <description>While there is a wide literature on developing neural networks for natural language understanding, the networks all have the same general architecture, determined by basic facts about the nature of linguistic input. In this talk I name and explain the four components (embed, encode, attend, predict), give a brief history of approaches to each subproblem, and explain two sophisticated networks in terms of this framework -- one for text classification, and another for textual entailment. The talk assumes a general knowledge of neural networks and machine learning. The talk should be especially suitable for people who have been working on computer vision or other problems.

Just as computer vision models are designed around the fact that images are two or three-dimensional arrays of continuous values, NLP models are designed around the fact that text is a linear sequence of discrete symbols that form a hierarchical structure: letters are grouped into words, which are grouped into larger syntactic units (phrases, clauses, etc), which are grouped into larger discursive structures (utterances, paragraphs, sections, etc).

Because the input symbols are discrete (letters, words, etc), the first step is "embed": map the discrete symbols into continuous vector representations. Because the input is a sequence, the second step is "encode": update the vector representation for each symbol given the surrounding context. You can't understand a sentence by looking up each word in the dictionary --- context matters. Because the input is hierarchical, sentences mean more than the sum of their parts. This motivates step three, attend: learn a further mapping from a variable-length matrix to a fixed-width vector, which we can then use to predict some specific information about the meaning of the text.</description>
      <media:content url="https://files.speakerdeck.com/presentations/e82075001c2e42049ef53814912fb669/preview_slide_0.jpg?10363234" type="image/jpeg" medium="image"/>
      <content:encoded>While there is a wide literature on developing neural networks for natural language understanding, the networks all have the same general architecture, determined by basic facts about the nature of linguistic input. In this talk I name and explain the four components (embed, encode, attend, predict), give a brief history of approaches to each subproblem, and explain two sophisticated networks in terms of this framework -- one for text classification, and another for textual entailment. The talk assumes a general knowledge of neural networks and machine learning. The talk should be especially suitable for people who have been working on computer vision or other problems.

Just as computer vision models are designed around the fact that images are two or three-dimensional arrays of continuous values, NLP models are designed around the fact that text is a linear sequence of discrete symbols that form a hierarchical structure: letters are grouped into words, which are grouped into larger syntactic units (phrases, clauses, etc), which are grouped into larger discursive structures (utterances, paragraphs, sections, etc).

Because the input symbols are discrete (letters, words, etc), the first step is "embed": map the discrete symbols into continuous vector representations. Because the input is a sequence, the second step is "encode": update the vector representation for each symbol given the surrounding context. You can't understand a sentence by looking up each word in the dictionary --- context matters. Because the input is hierarchical, sentences mean more than the sum of their parts. This motivates step three, attend: learn a further mapping from a variable-length matrix to a fixed-width vector, which we can then use to predict some specific information about the meaning of the text.</content:encoded>
      <pubDate>Thu, 12 Apr 2018 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/honnibal/embed-encode-attend-predict-a-four-step-framework-for-understanding-neural-network-approaches-to-natural-language-understanding-problems</link>
      <guid>https://speakerdeck.com/honnibal/embed-encode-attend-predict-a-four-step-framework-for-understanding-neural-network-approaches-to-natural-language-understanding-problems</guid>
    </item>
  </channel>
</rss>
