Udostępnij za pośrednictwem

Prosta składnia zapytań w usłudze Azure AI Search

  • Artykuł

W przypadku scenariuszy wyszukiwania pełnotekstowego usługa Azure AI Search implementuje dwa języki zapytań oparte na lucene, z których każdy jest wyrównany do analizatora zapytań. Analizator prostych zapytań jest domyślny. Obejmuje on typowe przypadki użycia i próby interpretacji żądania, nawet jeśli nie jest idealnie skomponowany. Innym analizatorem jest analizator zapytań Lucene i obsługuje bardziej zaawansowane konstrukcje zapytań.

W tym artykule znajduje się dokumentacja składni zapytań dla prostego analizatora zapytań.

Składnia zapytania dla obu analizatorów ma zastosowanie do wyrażeń zapytań przekazywanych w search parametrze żądania zapytania, a nie mylić ze składnią OData, z własną składnią i regułami dla filter i orderby wyrażeń w tym samym żądaniu.

Chociaż prosty analizator jest oparty na klasie analizatora prostego zapytań Apache Lucene, jego implementacja w usłudze Azure AI Search wyklucza wyszukiwanie rozmyte. Jeśli potrzebujesz wyszukiwania rozmytego, rozważ alternatywną pełną składnię zapytań Lucene.

Przykład (prosta składnia)

W tym przykładzie przedstawiono proste zapytanie, wyróżniające się i "queryType": "simple" prawidłową składnię. Mimo że typ zapytania jest ustawiony poniżej, jest to wartość domyślna i można ją pominąć, chyba że zostanie przywrócony typ alternatywny. Poniższy przykład to wyszukiwanie niezależnych terminów z wymaganiem, że wszystkie pasujące dokumenty obejmują "pulę".

POST https://{{service-name}}.search.windows.net/indexes/hotel-rooms-sample/docs/search?api-version=2024-07-01
{
  "queryType": "simple",
  "search": "budget hotel +pool",
  "searchMode": "all"
}

Parametr searchMode jest istotny w tym przykładzie. Za każdym razem, gdy operatory logiczne znajdują się w zapytaniu, należy ogólnie ustawić searchMode=all , aby upewnić się, że wszystkie kryteria są zgodne. W przeciwnym razie możesz użyć wartości domyślnej searchMode=any , która faworyzuje kompletność z dokładnością.

Aby uzyskać więcej przykładów, zobacz Proste przykłady składni zapytań. Aby uzyskać szczegółowe informacje o żądaniu i parametrach zapytania, zobacz Wyszukiwanie dokumentów (interfejs API REST).

Wyszukiwanie słów kluczowych według terminów i fraz

Ciągi przekazywane do parametru search mogą zawierać terminy lub frazy w dowolnym obsługiwanym języku, operatorach logicznych, operatorach pierwszeństwa, symbolach wieloznacznych lub prefiksach dla zapytań "rozpoczyna się od", znaków ucieczki i znaków kodowania adresu URL. Parametr search jest opcjonalny. Nieokreślone, wyszukiwanie (search=* lub search=" ") zwraca 50 pierwszych dokumentów w dowolnej kolejności (nieskonfigurowane).

  • Wyszukiwanie terminów jest zapytaniem o co najmniej jeden termin, w którym dowolny z terminów jest traktowany jako dopasowanie.

  • Wyszukiwanie fraz jest dokładną frazą ujętą w cudzysłowie " ". Na przykład chociaż Roach Motel (bez cudzysłowów) będzie wyszukiwać dokumenty zawierające Roach i/lub Motel w dowolnym miejscu w dowolnej kolejności, "Roach Motel" (z cudzysłowami) będą pasować tylko do dokumentów zawierających te całe frazy razem i w tej kolejności (analiza leksykalna nadal ma zastosowanie).

W zależności od klienta wyszukiwania może być konieczne ucieczka znaków cudzysłowu w wyszukiwaniu fraz. Na przykład w żądaniu POST wyszukiwanie "Roach Motel" fraz w treści żądania może być określone jako "\"Roach Motel\"". Jeśli używasz zestawów SDK platformy Azure, klient wyszukiwania uniknie znaków cudzysłowu podczas serializacji tekstu wyszukiwania. Frazę wyszukiwania można wysłać jako "Roach Motel".

Domyślnie wszystkie ciągi przekazywane w parametrze search są poddawane analizie leksykalnej. Upewnij się, że rozumiesz zachowanie tokenizacji używanego analizatora. Często, gdy wyniki zapytania są nieoczekiwane, przyczyną może być śledzenie sposobu tokenizacji terminów w czasie zapytania. Tokenizację można przetestować na określonych ciągach , aby potwierdzić dane wyjściowe.

Każde wprowadzanie tekstu z co najmniej jednym terminem jest uznawane za prawidłowy punkt wyjścia do wykonywania zapytania. Usługa Azure AI Search będzie zgodna z dokumentami zawierającymi dowolne lub wszystkie terminy, w tym wszelkie odmiany znalezione podczas analizy tekstu.

Tak proste, jak to brzmi, istnieje jeden aspekt wykonywania zapytań w usłudze Azure AI Search, który może generować nieoczekiwane wyniki, zwiększając zamiast zmniejszać wyniki wyszukiwania, ponieważ więcej terminów i operatorów jest dodawanych do ciągu wejściowego. To, czy rozszerzenie rzeczywiście występuje, zależy od włączenia operatora NOT, w połączeniu z ustawieniem searchMode parametru, który określa, jak NIE jest interpretowany w kategoriach AND lub OR zachowaniach. Aby uzyskać więcej informacji, zobacz NOT operator w obszarze Operatory logiczne.

Operatory logiczne

Operatory logiczne można osadzić w ciągu zapytania, aby zwiększyć dokładność dopasowania. W prostej składni operatory logiczne są oparte na znakach. Operatory tekstu, takie jak słowo AND, nie są obsługiwane.

Znak Przykład Użycie
+ pool + ocean Operacja AND . Na przykład przewiduje, pool + ocean że dokument musi zawierać oba terminy.
| pool | ocean Operacja OR znajduje dopasowanie po znalezieniu dowolnego terminu. W tym przykładzie aparat zapytań zwróci dopasowanie do dokumentów zawierających elementy pool lub ocean oba te elementy. Ponieważ OR jest domyślnym operatorem połączenia, możesz również pominąć go, tak aby pool ocean był odpowiednikiem pool | ocean.
- pool – ocean NOT Operacja zwraca dopasowania w dokumentach, które wykluczają termin.

searchMode Parametr żądania zapytania określa, czy termin z NOT operatorem jest ANDed, czy ORz innymi terminami w zapytaniu (przy założeniu, że nie ma operatorów logicznych na innych terminach). Prawidłowe wartości to any lub all.

searchMode=any zwiększa kompletność zapytań, uwzględniając więcej wyników, a domyślnie - będzie interpretowana jako "OR NOT". Na przykład pool - ocean będzie pasuje do dokumentów, które zawierają termin pool lub te, które nie zawierają terminu ocean.

searchMode=all zwiększa dokładność zapytań, uwzględniając mniej wyników, a domyślnie - będzie interpretowana jako "AND NOT". Na przykład w przypadku polecenia zapytanie pool - ocean będzie zgodne z dokumentami searchMode=anyzawierającymi termin "pula" i wszystkie dokumenty, które nie zawierają terminu "ocean". Jest to prawdopodobnie bardziej intuicyjne zachowanie - operatora. Dlatego należy rozważyć użycie searchMode=all zamiast searchMode=any , jeśli chcesz zoptymalizować wyszukiwania pod kątem precyzji, a nie przypomnieć, a użytkownicy często używają - operatora wyszukiwania.

Podczas podejmowania decyzji o ustawieniu searchMode należy wziąć pod uwagę wzorce interakcji użytkownika dla zapytań w różnych aplikacjach. Użytkownicy, którzy szukają informacji, są bardziej skłonni do uwzględnienia operatora w zapytaniu, w przeciwieństwie do witryn handlu elektronicznego, które mają bardziej wbudowane struktury nawigacji.

Zapytania prefiksu

W przypadku zapytań "rozpoczyna się od" dodaj operator sufiksu (*) jako symbol zastępczy dla pozostałej części terminu. Kwerenda prefiksu musi zaczynać się od co najmniej jednego znaku alfanumerycznego, zanim będzie można dodać operator sufiksu.

Znak Przykład Użycie
* lingui* będzie pasowała do "językowych" lub "linguini" Gwiazdka (*) reprezentuje co najmniej jeden znak dowolnej długości, ignorując wielkość liter.

Podobnie jak w przypadku filtrów, zapytanie prefiksu szuka dokładnego dopasowania. W związku z tym nie ma oceniania istotności (wszystkie wyniki otrzymują wynik wyszukiwania 1,0). Należy pamiętać, że zapytania prefiksów mogą być powolne, zwłaszcza jeśli indeks jest duży, a prefiks składa się z niewielkiej liczby znaków. Alternatywna metodologia, taka jak tokenizacja n-gram krawędzi, może działać szybciej. Terminy korzystające z wyszukiwania prefiksów nie mogą być dłuższe niż 1000 znaków.

Prosta składnia obsługuje tylko dopasowywanie prefiksów. W przypadku dopasowania sufiksu lub poprawki do końca lub środka terminu użyj pełnej składni Lucene do wyszukiwania symboli wieloznacznych.

Ucieczka operatorów wyszukiwania

W prostej składni operatory wyszukiwania zawierają następujące znaki: + | " ( ) ' \

Jeśli którykolwiek z tych znaków jest częścią tokenu w indeksie, należy go uniknąć, prefiksując go jednym ukośnikiem odwrotnym (\) w zapytaniu. Załóżmy na przykład, że użyto analizatora niestandardowego do tokenizacji całego terminu, a indeks zawiera ciąg "Luxury+Hotel". Aby uzyskać dokładne dopasowanie dla tego tokenu, wstaw znak ucieczki: search=luxury\+hotel.

Aby ułatwić kwestie dla bardziej typowych przypadków, istnieją dwa wyjątki od tej reguły, w przypadku których ucieczka nie jest wymagana:

  • Operator - NOT musi zostać usunięty tylko wtedy, gdy jest to pierwszy znak po białym znaku. Jeśli element - pojawi się w środku (na przykład w 3352CDD0-EF30-4A2E-A512-3B30AF40F3FDpliku ), możesz pominąć ucieczkę.

  • Operator * sufiksu musi zostać usunięty tylko wtedy, gdy jest to ostatni znak przed białym znakiem. Jeśli element * pojawi się w środku (na przykład w 4*4=16pliku ), nie jest wymagane żadne ucieczki.

Uwaga

Domyślnie analizator standardowy usuwa i przerywa wyrazy łączników, biały znak, znaki i znaki oraz inne znaki podczas analizy leksykalnej. Jeśli wymagane jest, aby znaki specjalne pozostały w ciągu zapytania, może być potrzebny analizator, który zachowuje je w indeksie. Niektóre opcje obejmują analizatory języka naturalnego firmy Microsoft, które zachowują wyrazy łączników lub analizator niestandardowy dla bardziej złożonych wzorców. Aby uzyskać więcej informacji, zobacz Częściowe terminy, wzorce i znaki specjalne.

Kodowanie niebezpiecznych i zastrzeżonych znaków w adresach URL

Upewnij się, że wszystkie niebezpieczne i zastrzeżone znaki są kodowane w adresie URL. Na przykład "#" jest niebezpiecznym znakiem, ponieważ jest to identyfikator fragmentu/kotwicy w adresie URL. Znak musi być zakodowany tak, aby %23 był używany w adresie URL. Znaki "&" i "=" są przykładami znaków zarezerwowanych, ponieważ ograniczą parametry i określają wartości w usłudze Azure AI Search. Aby uzyskać więcej informacji, zobacz RFC1738: Uniform Resource Locators (URL).

Niebezpieczne znaki to " ` < > # % { } | \ ^ ~ [ ]. Zastrzeżone znaki to ; / ? : @ = + &.

Znaki specjalne

Znaki specjalne mogą zawierać symbole waluty, takie jak "$" lub "€", po emoji. Wiele analizatorów, w tym domyślny analizator standardowy, wyklucza znaki specjalne podczas indeksowania, co oznacza, że nie będą one reprezentowane w indeksie.

Jeśli potrzebujesz reprezentacji znaku specjalnego, możesz przypisać analizator, który je zachowuje:

  • Analizator białych znaków uwzględnia dowolną sekwencję znaków oddzieloną białymi spacjami jako tokeny (więc emoji "❤" będzie traktowana jako token).

  • Analizator języka, taki jak Analizator języka angielskiego firmy Microsoft (en.microsoft), będzie przyjmować ciąg "$" lub "€" jako token.

Aby potwierdzić, możesz przetestować analizator, aby zobaczyć, jakie tokeny są generowane dla danego ciągu. Jak można się spodziewać, nie można uzyskać pełnej tokenizacji z jednego analizatora. Obejściem jest utworzenie wielu pól zawierających tę samą zawartość, ale przy użyciu różnych przypisań analizatora (na przykład description_en, description_fri tak dalej dla analizatorów języka).

W przypadku używania znaków Unicode upewnij się, że symbole są prawidłowo ucieczki w adresie URL zapytania (na przykład dla znaku "❤" będzie używać sekwencji ucieczki %E2%9D%A4+). Niektórzy klienci internetowi wykonują to tłumaczenie automatycznie.

Pierwszeństwo (grupowanie)

Nawiasy umożliwiają tworzenie podzapytań, w tym operatorów w instrukcji nawiasów. Na przykład motel+(wifi|luxury) wyszuka dokumenty zawierające termin "motel" i "wifi" lub "luxury" (lub oba).

Limity rozmiaru zapytania

Jeśli aplikacja generuje zapytania wyszukiwania programowo, zalecamy zaprojektowanie go w taki sposób, aby nie generował zapytań o niezwiązany rozmiar.

  • W przypadku polecenia GET długość adresu URL nie może przekraczać 8 KB.

  • W przypadku żądania POST (i innych żądań), gdzie treść żądania zawiera search i inne parametry, takie jak filter i orderby, maksymalny rozmiar to 16 MB. Dodatkowe limity obejmują:

    • Maksymalna długość klauzuli wyszukiwania wynosi 100 000 znaków.
    • Maksymalna liczba klauzul w ( search wyrażeniach oddzielonych wartościami AND lub OR) wynosi 1024.
    • Maksymalny rozmiar terminu wyszukiwania to 1000 znaków dla wyszukiwania prefiksów.
    • Istnieje również limit około 32 KB dla rozmiaru dowolnego pojedynczego terminu w zapytaniu.

Aby uzyskać więcej informacji na temat limitów zapytań, zobacz Limity żądań interfejsu API.

Następne kroki

Jeśli utworzysz zapytania programowo, zapoznaj się z tematem Wyszukiwanie pełnotekstowe w usłudze Azure AI Search , aby zrozumieć etapy przetwarzania zapytań i implikacje analizy tekstu.

Możesz również zapoznać się z następującymi artykułami, aby dowiedzieć się więcej o tworzeniu zapytań: