Wyszukiwanie częściowe terminy i wzorce ze znakami specjalnymi (łączniki, symbole wieloznaczne, regex, wzorce)
Wyszukiwanie częściowe terminy odnosi się do zapytań składających się z fragmentów terminów, w których zamiast całego terminu może istnieć tylko początek, środek lub koniec terminu (czasami nazywane prefiksem, prefiksem lub zapytaniami sufiksu). Wyszukiwanie częściowego terminu może zawierać kombinację fragmentów, często z znakami specjalnymi, takimi jak łączniki, kreski lub ukośniki będące częścią ciągu zapytania. Typowe przypadki użycia obejmują części numeru telefonu, adresu URL, kodów lub wyrazów złożonych.
Częściowe terminy i znaki specjalne mogą być problematyczne, jeśli indeks nie ma tokenu reprezentującego fragment tekstu, którego chcesz wyszukać. W fazie analizy leksykalnej indeksowania słów kluczowych (przy założeniu domyślnego analizatora standardowego) znaki specjalne są odrzucane, złożone wyrazy są dzielone, a odstępy są usuwane. Jeśli szukasz fragmentu tekstu zmodyfikowanego podczas analizy leksykalnej, zapytanie kończy się niepowodzeniem, ponieważ nie znaleziono dopasowania. Rozważmy następujący przykład: numer telefonu, taki jak +1 (425) 703-6214
(tokenizowany jako "1"
, "425"
, "703"
, "6214"
) nie będzie wyświetlany w "3-62"
zapytaniu, ponieważ ta zawartość nie istnieje w indeksie.
Rozwiązaniem jest wywołanie analizatora podczas indeksowania, który zachowuje pełny ciąg, w tym spacje i znaki specjalne w razie potrzeby, aby można było uwzględnić spacje i znaki w ciągu zapytania. Mając cały, niezpowiedziany ciąg umożliwia dopasowywanie wzorca dla zapytań "rozpoczyna się od" lub "kończy się", gdzie wzorzec, który podajesz, można ocenić względem terminu, który nie jest przekształcany przez analizę leksykową.
Jeśli potrzebujesz obsługiwać scenariusze wyszukiwania, które wymagają analizowania i nieanalizowanej zawartości, rozważ utworzenie dwóch pól w indeksie, po jednym dla każdego scenariusza. Jedno pole przechodzi analizę leksykalizaną. Drugie pole przechowuje nienaruszony ciąg przy użyciu analizatora zachowującego zawartość, który emituje tokeny całego ciągu na potrzeby dopasowywania wzorców.
Informacje o częściowym wyszukiwaniu terminów
Usługa Azure AI Search skanuje całe tokenizowane terminy w indeksie i nie znajdzie dopasowania w okresie częściowym, chyba że dołączysz operatory symboli zastępczych z symbolami wieloznacznymi (*
i ?
) lub sformatuj zapytanie jako wyrażenie regularne.
Terminy częściowe są określane przy użyciu następujących technik:
Zapytania wyrażeń regularnych mogą być dowolnym wyrażeniem regularnym, które jest prawidłowe w obszarze Apache Lucene.
Operatory symboli wieloznacznych z dopasowaniem prefiksu odnoszą się do powszechnie rozpoznawanego wzorca zawierającego początek terminu, a następnie
*
operatorów sufiksów,?
takich jaksearch=cap*
dopasowywanie w "Cap'n Jack's Waterfront Inn" lub "Highline Capital". Dopasowywanie prefiksów jest obsługiwane zarówno w prostej, jak i pełnej składni zapytań Lucene.Symbol wieloznaczny z przyrostkiem i dopasowaniem
*
sufiksów umieszcza operatory i?
wewnątrz lub na początku terminu i wymaga składni wyrażenia regularnego (gdzie wyrażenie jest ujęte w ukośniki). Na przykład ciąg zapytania (search=/.*numeric.*/
) zwraca wyniki na "alfanumeryczne" i "alfanumeryczne" jako sufiks i dopasowania przyrostkowe.
W przypadku wyrażeń regularnych, symboli wieloznacznych i wyszukiwania rozmytego analizatory nie są używane w czasie wykonywania zapytań. W przypadku tych formularzy zapytań, które analizator wykrywa obecność operatorów i ograniczników, ciąg zapytania jest przekazywany do aparatu bez analizy leksykalnej. W przypadku tych formularzy zapytań analizator określony w polu jest ignorowany.
Uwaga
Jeśli częściowy ciąg zapytania zawiera znaki, takie jak ukośniki w fragmentcie adresu URL, może być konieczne dodanie znaków ucieczki. W formacie JSON ukośnik /
do przodu jest uniknął ukośnika \
wstecznego . W związku z tym search=/.*microsoft.com\/azure\/.*/
jest składnią fragmentu adresu URL "microsoft.com/azure/".
Rozwiązywanie problemów z wyszukiwaniem częściowym/wzorcu
Jeśli musisz wyszukać fragmenty lub wzorce lub znaki specjalne, możesz zastąpić analizator domyślny analizatorem niestandardowym, który działa w ramach prostszych reguł tokenizacji, zachowując cały ciąg w indeksie.
Podejście wygląda następująco:
- Zdefiniuj drugie pole do przechowywania nienaruszonej wersji ciągu (przy założeniu, że chcesz analizować i nieanalizowany tekst w czasie zapytania)
- Oceń i wybierz spośród różnych analizatorów, które emitują tokeny na odpowiednim poziomie szczegółowości
- Przypisywanie analizatora do pola
- Kompilowanie i testowanie indeksu
1 — Tworzenie dedykowanego pola
Analizatory określają, jak terminy są tokenizowane w indeksie. Ponieważ analizatory są przypisywane dla poszczególnych pól, można tworzyć pola w indeksie w celu optymalizacji pod kątem różnych scenariuszy. Można na przykład zdefiniować frazę "featureCode" i "featureCodeRegex", aby obsługiwać regularne wyszukiwanie pełnotekstowe w pierwszym i zaawansowane dopasowywanie wzorca w drugim. Analizatory przypisane do każdego pola określają, w jaki sposób zawartość każdego pola jest tokenizowana w indeksie.
{
"name": "featureCode",
"type": "Edm.String",
"retrievable": true,
"searchable": true,
"analyzer": null
},
{
"name": "featureCodeRegex",
"type": "Edm.String",
"retrievable": true,
"searchable": true,
"analyzer": "my_custom_analyzer"
},
2 — Ustawianie analizatora
Podczas wybierania analizatora, który generuje tokeny pełnookresowe, typowe opcje są następujące analizatory:
Analizator | Zachowania |
---|---|
analizatory języków | Zachowuje łączniki w złożonych słowach lub ciągach, mutacjach samogłosek i formach czasowników. Jeśli wzorce zapytań zawierają kreski, użycie analizatora języka może być wystarczające. |
słowo kluczowe | Zawartość całego pola jest tokenizowana jako pojedynczy termin. |
Odstępu | Oddziela tylko białe spacje. Terminy zawierające kreski lub inne znaki są traktowane jako pojedynczy token. |
analizator niestandardowy | (zalecane) Tworzenie analizatora niestandardowego umożliwia określenie zarówno tokenizatora, jak i filtru tokenu. Poprzednie analizatory muszą być używane w stanie rzeczywistym. Analizator niestandardowy umożliwia wybranie tokenizatorów i filtrów tokenów do użycia. Zalecaną kombinacją jest tokenizer słowa kluczowego z filtrem tokenu małego liter. Sam wbudowany analizator słów kluczowych nie ma małego liter tekstu, co może spowodować niepowodzenie zapytań. Analizator niestandardowy udostępnia mechanizm dodawania filtru tokenu małego liter. |
Za pomocą klienta REST można dodać wywołanie REST analizatora testów, aby sprawdzić tokenizowane dane wyjściowe.
Indeks musi istnieć w usłudze wyszukiwania, ale może być pusty. Biorąc pod uwagę istniejący indeks i pole zawierające kreski lub częściowe terminy, możesz wypróbować różne analizatory na określonych terminach, aby zobaczyć, jakie tokeny są emitowane.
Najpierw sprawdź analizator w warstwie Standardowa, aby zobaczyć, jak terminy są domyślnie tokenizowane.
{ "text": "SVP10-NOR-00", "analyzer": "standard" }
Oceń odpowiedź, aby zobaczyć, jak tekst jest tokenizowany w indeksie. Zwróć uwagę, że każdy termin ma małe litery, usunięte łączniki i podciągy podzielone na poszczególne tokeny. Tylko te zapytania pasujące do tych tokenów będą zwracać ten dokument w wynikach. Zapytanie zawierające wartość "10-NOR" zakończy się niepowodzeniem.
{ "tokens": [ { "token": "svp10", "startOffset": 0, "endOffset": 5, "position": 0 }, { "token": "nor", "startOffset": 6, "endOffset": 9, "position": 1 }, { "token": "00", "startOffset": 10, "endOffset": 12, "position": 2 } ] }
Teraz zmodyfikuj żądanie, aby użyć analizatora
whitespace
lubkeyword
:{ "text": "SVP10-NOR-00", "analyzer": "keyword" }
Tym razem odpowiedź składa się z pojedynczego tokenu z wielkimi literami z kreskami zachowanymi jako część ciągu. Jeśli musisz wyszukać wzorzec lub termin częściowy, taki jak "10-NOR", aparat zapytań ma teraz podstawę do znalezienia dopasowania.
{ "tokens": [ { "token": "SVP10-NOR-00", "startOffset": 0, "endOffset": 12, "position": 0 } ] }
Ważne
Należy pamiętać, że analizatory zapytań często mają małe litery w wyrażeniu wyszukiwania podczas kompilowania drzewa zapytań. Jeśli używasz analizatora, który nie wprowadza małych liter tekstu podczas indeksowania i nie otrzymujesz oczekiwanych wyników, może to być przyczyna. Rozwiązaniem jest dodanie filtru tokenu małego przypadku, zgodnie z opisem w sekcji "Korzystanie z analizatorów niestandardowych" poniżej.
3 — Konfigurowanie analizatora
Niezależnie od tego, czy oceniasz analizatory, czy przechodzisz do przodu przy użyciu określonej konfiguracji, musisz określić analizator w definicji pola i ewentualnie skonfigurować sam analizator, jeśli nie używasz wbudowanego analizatora. Podczas zamiany analizatorów zwykle trzeba ponownie skompilować indeks (upuść, utworzyć ponownie i ponownie załadować).
Korzystanie z wbudowanych analizatorów
Wbudowane analizatory można określić według nazwy we analyzer
właściwości definicji pola, bez dodatkowej konfiguracji wymaganej w indeksie. W poniższym przykładzie pokazano, jak ustawić whitespace
analizator w polu.
Aby uzyskać więcej informacji na temat innych wbudowanych analizatorów, zobacz Wbudowane analizatory.
{
"name": "phoneNumber",
"type": "Edm.String",
"key": false,
"retrievable": true,
"searchable": true,
"analyzer": "whitespace"
}
Korzystanie z analizatorów niestandardowych
Jeśli używasz analizatora niestandardowego, zdefiniuj go w indeksie za pomocą zdefiniowanej przez użytkownika kombinacji tokenizatora, filtru tokenu z możliwymi ustawieniami konfiguracji. Następnie odwołaj się do niej w definicji pola, tak jak w przypadku wbudowanego analizatora.
Gdy celem jest tokenizacja całego terminu, zalecany jest niestandardowy analizator składający się z tokenizatora słowa kluczowego i filtr tokenu małego liter.
- Tokenizer słowa kluczowego tworzy pojedynczy token dla całej zawartości pola.
- Filtr tokenu z małymi literami przekształca wielkie litery na małe litery. Analizatory zapytań zwykle małe litery wszystkich wielkich danych wejściowych tekstu. Małe litery homogenizuje dane wejściowe przy użyciu tokenizowanych terminów.
Poniższy przykład ilustruje analizator niestandardowy, który udostępnia tokenizer słowa kluczowego i filtr tokenu małe litery.
{
"fields": [
{
"name": "accountNumber",
"analyzer":"myCustomAnalyzer",
"type": "Edm.String",
"searchable": true,
"filterable": true,
"retrievable": true,
"sortable": false,
"facetable": false
}
],
"analyzers": [
{
"@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
"name":"myCustomAnalyzer",
"charFilters":[],
"tokenizer":"keyword_v2",
"tokenFilters":["lowercase"]
}
],
"tokenizers":[],
"charFilters": [],
"tokenFilters": []
}
Uwaga
Tokenizer keyword_v2
i lowercase
filtr tokenu są znane systemowi i używają ich domyślnych konfiguracji, dlatego można odwoływać się do nich według nazwy bez konieczności ich wcześniejszego definiowania.
4 — Kompilowanie i testowanie
Po zdefiniowaniu indeksu za pomocą analizatorów i definicji pól, które obsługują twój scenariusz, załaduj dokumenty zawierające reprezentatywne ciągi, aby można było przetestować zapytania dotyczące ciągów częściowych.
Użyj klienta REST, aby wykonywać zapytania dotyczące częściowych terminów i znaków specjalnych opisanych w tym artykule.
W poprzednich sekcjach wyjaśniono logikę. W tej sekcji opisano poszczególne interfejsy API, które należy wywołać podczas testowania rozwiązania.
Usuń indeks usuwa istniejący indeks o tej samej nazwie, aby można było go ponownie utworzyć.
Tworzenie indeksu tworzy strukturę indeksu w usłudze wyszukiwania, w tym definicje analizatora i pola ze specyfikacją analizatora.
Załaduj dokumenty importuje dokumenty o tej samej strukturze co indeks, a także zawartość z możliwością wyszukiwania. Po wykonaniu tego kroku indeks jest gotowy do wykonywania zapytań lub testowania.
Analizator testów został wprowadzony w temacie Ustawianie analizatora. Przetestuj niektóre ciągi w indeksie przy użyciu różnych analizatorów, aby zrozumieć, jak są tokenizowane terminy.
Dokumenty wyszukiwania wyjaśniają, jak utworzyć żądanie zapytania przy użyciu prostej składni lub pełnej składni Lucene dla symboli wieloznacznych i wyrażeń regularnych.
W przypadku zapytań częściowych terminów, takich jak wykonywanie zapytań "3-6214", aby znaleźć dopasowanie dla "+1 (425) 703-6214", można użyć prostej składni:
search=3-6214&queryType=simple
.W przypadku zapytań infiksowych i sufiksów, takich jak wykonywanie zapytań "num" lub "numeryczne" w celu znalezienia dopasowania w elemencie "alfanumeryczne", użyj pełnej składni Lucene i wyrażenia regularnego:
search=/.*num.*/&queryType=full
Optymalizowanie zapytań prefiksu i sufiksów
Dopasowywanie prefiksów i sufiksów przy użyciu analizatora domyślnego wymaga dodatkowych funkcji zapytania. Prefiksy wymagają wyszukiwania symboli wieloznacznych i sufiksów, które wymagają wyszukiwania wyrażeń regularnych. Obie te funkcje mogą zmniejszyć wydajność zapytań.
Poniższy przykład dodaje element w EdgeNGramTokenFilter
celu szybszego dopasowania prefiksu lub sufiksu. Tokeny są generowane w kombinacjach 2–25 znaków, które zawierają znaki. Oto przykładowy postęp z dwóch do siedmiu tokenów: MS, MSF, MSFT, MSFT/, MSFT/S, MSFT/SQ, MSFT/SQL. EdgeNGramTokenFilter
wymaga parametru side
, który określa, na której stronie są generowane kombinacje znaków ciągu. Służy front
do obsługi zapytań prefiksów i back
zapytań sufiksów.
Dodatkowa tokenizacja powoduje większy indeks. Jeśli masz wystarczającą pojemność, aby pomieścić większy indeks, takie podejście z krótszym czasem odpowiedzi może być najlepszym rozwiązaniem.
{
"fields": [
{
"name": "accountNumber_prefix",
"indexAnalyzer": "ngram_front_analyzer",
"searchAnalyzer": "keyword",
"type": "Edm.String",
"searchable": true,
"filterable": false,
"retrievable": true,
"sortable": false,
"facetable": false
},
{
"name": "accountNumber_suffix",
"indexAnalyzer": "ngram_back_analyzer",
"searchAnalyzer": "keyword",
"type": "Edm.String",
"searchable": true,
"filterable": false,
"retrievable": true,
"sortable": false,
"facetable": false
}
],
"analyzers": [
{
"@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
"name":"ngram_front_analyzer",
"charFilters":[],
"tokenizer":"keyword_v2",
"tokenFilters":["lowercase", "front_edgeNGram"]
},
{
"@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
"name":"ngram_back_analyzer",
"charFilters":[],
"tokenizer":"keyword_v2",
"tokenFilters":["lowercase", "back_edgeNGram"]
}
],
"tokenizers":[],
"charFilters": [],
"tokenFilters": [
{
"@odata.type":"#Microsoft.Azure.Search.EdgeNGramTokenFilterV2",
"name":"front_edgeNGram",
"minGram": 2,
"maxGram": 25,
"side": "front"
},
{
"@odata.type":"#Microsoft.Azure.Search.EdgeNGramTokenFilterV2",
"name":"back_edgeNGram",
"minGram": 2,
"maxGram": 25,
"side": "back"
}
]
}
Aby wyszukać numery kont rozpoczynające się od 123
, możemy użyć następującego zapytania:
{
"search": "123",
"searchFields": "accountNumber_prefix"
}
Aby wyszukać numery kont kończące się ciągiem 456
, możemy użyć następującego zapytania:
{
"search": "456",
"searchFields": "accountNumber_suffix"
}
Następne kroki
W tym artykule wyjaśniono, jak analizatory przyczyniają się zarówno do problemów z zapytaniami, jak i rozwiązywania problemów z zapytaniami. W następnym kroku przyjrzyj się bliżej analizatorom wpływającym na indeksowanie i przetwarzanie zapytań.