# Non binary active learning

**URL:** <https://support.prodi.gy/t/non-binary-active-learning/6015>\
**Category:** Uncategorized\
**Tags:** ner, best-practices\
**Created:** [October 7, 2022, 8:01am UTC](https://support.prodi.gy/t/non-binary-active-learning/6015 "2022-10-07T08:01:22Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![ryanwesslen](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ryanwesslen/32/2969_2.png) [@ryanwesslen](https://support.prodi.gy/u/ryanwesslen)\
**Post date:** [October 7, 2022, 12:28pm UTC](https://support.prodi.gy/t/non-binary-active-learning/6015/2 "2022-10-07T12:28:02Z")

</div>

hi @nsorros!

Thanks for your questions!

This is a common question and has been answered in older posts like this one:

> [@Why is there no active learning for manual/gold standard annotations?](https://support.prodi.gy/t/why-is-there-no-active-learning-for-manual-gold-standard-annotations/1507/2):
>
> You can definitely provide an update() callback function in a recipe that uses the manual interface. Custom recipes are very useful in general, as the Python API is much more powerful than the recipe arguments. Ultimately we decided to avoid trying to cram every combination of possible options into the built-in CLI. If you make the CLI too complicated, you end up programming via the CLI, and learning too many arbitrary details. At some point it’s better to switch over to Python. The source for …

To better understand the design philosophy, I would recommend watching some of Matt and Ines' early talks around 2018 ([slides repo](https://github.com/explosion/talks) and [YouTube talks playlist](https://www.youtube.com/playlist?list=PLBmcuObd5An7oE73XacDNJ3ZxO82ogc6j)). One example is [this talk/slides](https://github.com/explosion/talks/blob/master/2018-04_12_Rapid-NLP-Annotation.pdf) and [a related YouTube talk](https://youtu.be/jB1-NukGZm0?t=2340) on binary active learning.

> [@nsorros](#):
>
> I assume this is to increase speed but I wonder whether in some cases its faster to be able to correct the annotation while keeping the sorting that comes from the model in the loop.

Fair point! Have you tried to create your [own custom recipe](https://prodi.gy/docs/custom-recipes) to experiment?

A major design philosophy of Prodigy is to provide smart defaults, but enable extensibility to developers because the best solutions are likely custom. Custom recipes are the way to implement customized tasks.

For example, you can find some details in [our docs about customizing active learning recipes with NER](https://prodi.gy/docs/named-entity-recognition#active-learning-custom).

Alternatively, you can find many open recipes in our prodigy-recipes repo, including [multiple NER examples](https://github.com/explosion/prodigy-recipes/tree/master/ner). Perhaps try to combine the `ner.teach` with the `ner.manual` and try it out!

> [@nsorros](#):
>
> This is motivated from a test to annotate ORG entities in a news dataset. ORG entities in that dataset are not that infrequent. Manual annotation gives me predictable performance gains as data size increases whereas active learning using en\_core\_web\_md struggles with the first hundred examples since I have to reject a lot of recommendations and keep only the ones that it already finds as correct. I still feel sorting the examples with a model in the loop provides benefits but i think what might work better in this example is to actively correct the labels instead of accept / reject.

Interesting idea - you should experiment and see what works! Keep us informed if you make any discoveries. We're always curious to hear about unique use cases. 🙂

---

_[View the full topic](https://support.prodi.gy/t/non-binary-active-learning/6015)._
