Synonyms for cities

Rasa Open Source
1

Version: dev-CC I am trying to make it work with entities for swiss cities, but they don’t get recognized through the NER. e…g entering just ZH or Züri won’t give me any entities. It works when I say “Ich suche was in ZH”. How can I do a fallback when someone just types in ZH?

NLU.md

intent:request_job

  • Ich suche was in [ZH](location
  • Ich suche was in [züri](location
  • Ich suche was in [Züri](location
  • Ich suche was in [Zürich](location

synonym:Zürich

  • ZH
  • züri
  • Züri

location.txt ZH Züri züri

config.yml

language: en

pipeline:

  • name: WhitespaceTokenizer
  • name: LexicalSyntacticFeaturizer
  • name: CountVectorsFeaturizer token_pattern: (?u)\b\w+\b
  • name: DucklingHTTPExtractor url: http://localhost:8000 dimensions:
    • number
  • name: DIETClassifier epochs: 100
  • name: EntitySynonymMapper

policies:

  • name: FallbackPolicy
  • name: MemoizationPolicy
  • name: FormPolicy
  • name: MappingPolicy
2

Hi @plotti

  1. If you are trying to fill the slot location, then do checkout the slot mappings in forms. You can fill the slot using not just entity, from intent and text too. In this case you might not need any fall back as ZH is a location by itself and slot will be filled.

  2. If you want the bot to fall back, Run the bot in debug mode and see the NLU confidence at which ZH is entered and use it as NLU treshold in config file under the fall back policy.

  - name: "FallbackPolicy"
    nlu_threshold: 0.4
    fallback_action_name: "action_default_fallback"
3

So if I understand correctly:

  1. I can use slot filling with a text policy and then make sure to somehow parse this text, based on whitelists etc in the form action … Slot Filling . I guess I could write all variations of Cities and simply match it by some form of distance e.g. levensthein ? Right now I was using a mapping based on entity: e.g. self.from_entity(entity=“location”)

  2. I can change the FallbackPolicy and give it a higher confidence value? I mean it does get the intent of the ZH entry right, but not the entity. see: ZH { “intent”: { “name”: “request_job”, “confidence”: 0.9957953095436096 }, “entities”: [], “intent_ranking”: [

4

  1. Yes, it is correct.

  2. The fallback that we are talking about is related to intent classification and not entity extraction. If entity is not extratced properly, you might have to go for different entity extractors with a combination of correct slot mappings.