mirror of
https://github.com/explosion/spaCy.git
synced 2024-11-14 21:57:15 +03:00
554df9ef20
* Rename all MDX file to `.mdx`
* Lock current node version (#11885)
* Apply Prettier (#11996)
* Minor website fixes (#11974) [ci skip]
* fix table
* Migrate to Next WEB-17 (#12005)
* Initial commit
* Run `npx create-next-app@13 next-blog`
* Install MDX packages
Following: 77b5f79a4d/packages/next-mdx/readme.md
* Add MDX to Next
* Allow Next to handle `.md` and `.mdx` files.
* Add VSCode extension recommendation
* Disabled TypeScript strict mode for now
* Add prettier
* Apply Prettier to all files
* Make sure to use correct Node version
* Add basic implementation for `MDXRemote`
* Add experimental Rust MDX parser
* Add `/public`
* Add SASS support
* Remove default pages and styling
* Convert to module
This allows to use `import/export` syntax
* Add import for custom components
* Add ability to load plugins
* Extract function
This will make the next commit easier to read
* Allow to handle directories for page creation
* Refactoring
* Allow to parse subfolders for pages
* Extract logic
* Redirect `index.mdx` to parent directory
* Disabled ESLint during builds
* Disabled typescript during build
* Remove Gatsby from `README.md`
* Rephrase Docker part of `README.md`
* Update project structure in `README.md`
* Move and rename plugins
* Update plugin for wrapping sections
* Add dependencies for plugin
* Use plugin
* Rename wrapper type
* Simplify unnessary adding of id to sections
The slugified section ids are useless, because they can not be referenced anywhere anyway. The navigation only works if the section has the same id as the heading.
* Add plugin for custom attributes on Markdown elements
* Add plugin to readd support for tables
* Add plugin to fix problem with wrapped images
For more details see this issue: https://github.com/mdx-js/mdx/issues/1798
* Add necessary meta data to pages
* Install necessary dependencies
* Remove outdated MDX handling
* Remove reliance on `InlineList`
* Use existing Remark components
* Remove unallowed heading
Before `h1` components where not overwritten and would never have worked and they aren't used anywhere either.
* Add missing components to MDX
* Add correct styling
* Fix broken list
* Fix broken CSS classes
* Implement layout
* Fix links
* Fix broken images
* Fix pattern image
* Fix heading attributes
* Rename heading attribute
`new` was causing some weird issue, so renaming it to `version`
* Update comment syntax in MDX
* Merge imports
* Fix markdown rendering inside components
* Add model pages
* Simplify anchors
* Fix default value for theme
* Add Universe index page
* Add Universe categories
* Add Universe projects
* Fix Next problem with copy
Next complains when the server renders something different then the client, therfor we move the differing logic to `useEffect`
* Fix improper component nesting
Next doesn't allow block elements inside a `<p>`
* Replace landing page MDX with page component
* Remove inlined iframe content
* Remove ability to inline HTML content in iFrames
* Remove MDX imports
* Fix problem with image inside link in MDX
* Escape character for MDX
* Fix unescaped characters in MDX
* Fix headings with logo
* Allow to export static HTML pages
* Add prebuild script
This command is automatically run by Next
* Replace `svg-loader` with `react-inlinesvg`
`svg-loader` is no longer maintained
* Fix ESLint `react-hooks/exhaustive-deps`
* Fix dropdowns
* Change code language from `cli` to `bash`
* Remove unnessary language `none`
* Fix invalid code language
`markdown_` with an underscore was used to basically turn of syntax highlighting, but using unknown languages know throws an error.
* Enable code blocks plugin
* Readd `InlineCode` component
MDX2 removed the `inlineCode` component
> The special component name `inlineCode` was removed, we recommend to use `pre` for the block version of code, and code for both the block and inline versions
Source: https://mdxjs.com/migrating/v2/#update-mdx-content
* Remove unused code
* Extract function to own file
* Fix code syntax highlighting
* Update syntax for code block meta data
* Remove unused prop
* Fix internal link recognition
There is a problem with regex between Node and browser, and since Next runs the component on both, this create an error.
`Prop `rel` did not match. Server: "null" Client: "noopener nofollow noreferrer"`
This simplifies the implementation and fixes the above error.
* Replace `react-helmet` with `next/head`
* Fix `className` problem for JSX component
* Fix broken bold markdown
* Convert file to `.mjs` to be used by Node process
* Add plugin to replace strings
* Fix custom table row styling
* Fix problem with `span` inside inline `code`
React doesn't allow a `span` inside an inline `code` element and throws an error in dev mode.
* Add `_document` to be able to customize `<html>` and `<body>`
* Add `lang="en"`
* Store Netlify settings in file
This way we don't need to update via Netlify UI, which can be tricky if changing build settings.
* Add sitemap
* Add Smartypants
* Add PWA support
* Add `manifest.webmanifest`
* Fix bug with anchor links after reloading
There was no need for the previous implementation, since the browser handles this nativly. Additional the manual scrolling into view was actually broken, because the heading would disappear behind the menu bar.
* Rename custom event
I was googeling for ages to find out what kind of event `inview` is, only to figure out it was a custom event with a name that sounds pretty much like a native one. 🫠
* Fix missing comment syntax highlighting
* Refactor Quickstart component
The previous implementation was hidding the irrelevant lines via data-props and dynamically generated CSS. This created problems with Next and was also hard to follow. CSS was used to do what React is supposed to handle.
The new implementation simplfy filters the list of children (React elements) via their props.
* Fix syntax highlighting for Training Quickstart
* Unify code rendering
* Improve error logging in Juniper
* Fix Juniper component
* Automatically generate "Read Next" link
* Add Plausible
* Use recent DocSearch component and adjust styling
* Fix images
* Turn of image optimization
> Image Optimization using Next.js' default loader is not compatible with `next export`.
We currently deploy to Netlify via `next export`
* Dont build pages starting with `_`
* Remove unused files
* Add Next plugin to Netlify
* Fix button layout
MDX automatically adds `p` tags around text on a new line and Prettier wants to put the text on a new line. Hacking with JSX string.
* Add 404 page
* Apply Prettier
* Update Prettier for `package.json`
Next sometimes wants to patch `package-lock.json`. The old Prettier setting indended with 4 spaces, but Next always indends with 2 spaces. Since `npm install` automatically uses the indendation from `package.json` for `package-lock.json` and to avoid the format switching back and forth, both files are now set to 2 spaces.
* Apply Next patch to `package-lock.json`
When starting the dev server Next would warn `warn - Found lockfile missing swc dependencies, patching...` and update the `package-lock.json`. These are the patched changes.
* fix link
Co-authored-by: Sofie Van Landeghem <svlandeg@users.noreply.github.com>
* small backslash fixes
* adjust to new style
Co-authored-by: Marcus Blättermann <marcus@essenmitsosse.de>
150 lines
7.0 KiB
Plaintext
150 lines
7.0 KiB
Plaintext
Similarity is determined by comparing **word vectors** or "word embeddings",
|
||
multi-dimensional meaning representations of a word. Word vectors can be
|
||
generated using an algorithm like
|
||
[word2vec](https://en.wikipedia.org/wiki/Word2vec) and usually look like this:
|
||
|
||
```python {title="banana.vector"}
|
||
array([2.02280000e-01, -7.66180009e-02, 3.70319992e-01,
|
||
3.28450017e-02, -4.19569999e-01, 7.20689967e-02,
|
||
-3.74760002e-01, 5.74599989e-02, -1.24009997e-02,
|
||
5.29489994e-01, -5.23800015e-01, -1.97710007e-01,
|
||
-3.41470003e-01, 5.33169985e-01, -2.53309999e-02,
|
||
1.73800007e-01, 1.67720005e-01, 8.39839995e-01,
|
||
5.51070012e-02, 1.05470002e-01, 3.78719985e-01,
|
||
2.42750004e-01, 1.47449998e-02, 5.59509993e-01,
|
||
1.25210002e-01, -6.75960004e-01, 3.58420014e-01,
|
||
# ... and so on ...
|
||
3.66849989e-01, 2.52470002e-03, -6.40089989e-01,
|
||
-2.97650009e-01, 7.89430022e-01, 3.31680000e-01,
|
||
-1.19659996e+00, -4.71559986e-02, 5.31750023e-01], dtype=float32)
|
||
```
|
||
|
||
<Infobox title="Important note" variant="warning">
|
||
|
||
To make them compact and fast, spaCy's small [pipeline packages](/models) (all
|
||
packages that end in `sm`) **don't ship with word vectors**, and only include
|
||
context-sensitive **tensors**. This means you can still use the `similarity()`
|
||
methods to compare documents, spans and tokens – but the result won't be as
|
||
good, and individual tokens won't have any vectors assigned. So in order to use
|
||
_real_ word vectors, you need to download a larger pipeline package:
|
||
|
||
```diff
|
||
- python -m spacy download en_core_web_sm
|
||
+ python -m spacy download en_core_web_lg
|
||
```
|
||
|
||
</Infobox>
|
||
|
||
Pipeline packages that come with built-in word vectors make them available as
|
||
the [`Token.vector`](/api/token#vector) attribute.
|
||
[`Doc.vector`](/api/doc#vector) and [`Span.vector`](/api/span#vector) will
|
||
default to an average of their token vectors. You can also check if a token has
|
||
a vector assigned, and get the L2 norm, which can be used to normalize vectors.
|
||
|
||
```python {executable="true"}
|
||
import spacy
|
||
|
||
nlp = spacy.load("en_core_web_md")
|
||
tokens = nlp("dog cat banana afskfsd")
|
||
|
||
for token in tokens:
|
||
print(token.text, token.has_vector, token.vector_norm, token.is_oov)
|
||
```
|
||
|
||
> - **Text**: The original token text.
|
||
> - **has vector**: Does the token have a vector representation?
|
||
> - **Vector norm**: The L2 norm of the token's vector (the square root of the
|
||
> sum of the values squared)
|
||
> - **OOV**: Out-of-vocabulary
|
||
|
||
The words "dog", "cat" and "banana" are all pretty common in English, so they're
|
||
part of the pipeline's vocabulary, and come with a vector. The word "afskfsd" on
|
||
the other hand is a lot less common and out-of-vocabulary – so its vector
|
||
representation consists of 300 dimensions of `0`, which means it's practically
|
||
nonexistent. If your application will benefit from a **large vocabulary** with
|
||
more vectors, you should consider using one of the larger pipeline packages or
|
||
loading in a full vector package, for example,
|
||
[`en_core_web_lg`](/models/en#en_core_web_lg), which includes **685k unique
|
||
vectors**.
|
||
|
||
spaCy is able to compare two objects, and make a prediction of **how similar
|
||
they are**. Predicting similarity is useful for building recommendation systems
|
||
or flagging duplicates. For example, you can suggest a user content that's
|
||
similar to what they're currently looking at, or label a support ticket as a
|
||
duplicate if it's very similar to an already existing one.
|
||
|
||
Each [`Doc`](/api/doc), [`Span`](/api/span), [`Token`](/api/token) and
|
||
[`Lexeme`](/api/lexeme) comes with a [`.similarity`](/api/token#similarity)
|
||
method that lets you compare it with another object, and determine the
|
||
similarity. Of course similarity is always subjective – whether two words, spans
|
||
or documents are similar really depends on how you're looking at it. spaCy's
|
||
similarity implementation usually assumes a pretty general-purpose definition of
|
||
similarity.
|
||
|
||
> #### 📝 Things to try
|
||
>
|
||
> 1. Compare two different tokens and try to find the two most _dissimilar_
|
||
> tokens in the texts with the lowest similarity score (according to the
|
||
> vectors).
|
||
> 2. Compare the similarity of two [`Lexeme`](/api/lexeme) objects, entries in
|
||
> the vocabulary. You can get a lexeme via the `.lex` attribute of a token.
|
||
> You should see that the similarity results are identical to the token
|
||
> similarity.
|
||
|
||
```python {executable="true"}
|
||
import spacy
|
||
|
||
nlp = spacy.load("en_core_web_md") # make sure to use larger package!
|
||
doc1 = nlp("I like salty fries and hamburgers.")
|
||
doc2 = nlp("Fast food tastes very good.")
|
||
|
||
# Similarity of two documents
|
||
print(doc1, "<->", doc2, doc1.similarity(doc2))
|
||
# Similarity of tokens and spans
|
||
french_fries = doc1[2:4]
|
||
burgers = doc1[5]
|
||
print(french_fries, "<->", burgers, french_fries.similarity(burgers))
|
||
```
|
||
|
||
### What to expect from similarity results {id="similarity-expectations"}
|
||
|
||
Computing similarity scores can be helpful in many situations, but it's also
|
||
important to maintain **realistic expectations** about what information it can
|
||
provide. Words can be related to each other in many ways, so a single
|
||
"similarity" score will always be a **mix of different signals**, and vectors
|
||
trained on different data can produce very different results that may not be
|
||
useful for your purpose. Here are some important considerations to keep in mind:
|
||
|
||
- There's no objective definition of similarity. Whether "I like burgers" and "I
|
||
like pasta" is similar **depends on your application**. Both talk about food
|
||
preferences, which makes them very similar – but if you're analyzing mentions
|
||
of food, those sentences are pretty dissimilar, because they talk about very
|
||
different foods.
|
||
- The similarity of [`Doc`](/api/doc) and [`Span`](/api/span) objects defaults
|
||
to the **average** of the token vectors. This means that the vector for "fast
|
||
food" is the average of the vectors for "fast" and "food", which isn't
|
||
necessarily representative of the phrase "fast food".
|
||
- Vector averaging means that the vector of multiple tokens is **insensitive to
|
||
the order** of the words. Two documents expressing the same meaning with
|
||
dissimilar wording will return a lower similarity score than two documents
|
||
that happen to contain the same words while expressing different meanings.
|
||
|
||
<Infobox title="Tip: Check out sense2vec" emoji="💡">
|
||
|
||
<Image
|
||
src="/images/sense2vec.jpg"
|
||
href="https://github.com/explosion/sense2vec"
|
||
/>
|
||
|
||
[`sense2vec`](https://github.com/explosion/sense2vec) is a library developed by
|
||
us that builds on top of spaCy and lets you train and query more interesting and
|
||
detailed word vectors. It combines noun phrases like "fast food" or "fair game"
|
||
and includes the part-of-speech tags and entity labels. The library also
|
||
includes annotation recipes for our annotation tool [Prodigy](https://prodi.gy)
|
||
that let you evaluate vectors and create terminology lists. For more details,
|
||
check out [our blog post](https://explosion.ai/blog/sense2vec-reloaded). To
|
||
explore the semantic similarities across all Reddit comments of 2015 and 2019,
|
||
see the [interactive demo](https://explosion.ai/demos/sense2vec).
|
||
|
||
</Infobox>
|