Prosta składnia zapytań w Wyszukiwanie AI platformy Azure

W przypadku scenariuszy wyszukiwania pełnotekstowego Wyszukiwanie AI platformy Azure implementuje dwa języki zapytań oparte na Lucene, z których każdy jest związany z analizatorem 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ń zapytania przekazywanych w parametrze searchżądania zapytania, przy czym nie należy mylić z składnią OData, która ma własną składnię i zasady dla wyrażeń filter i orderby w tym samym żądaniu.

Chociaż prosty analizator oparty jest na klasie Apache Lucene Simple Query Parser, jego implementacja w Wyszukiwanie AI platformy Azure 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, które wyróżnia się "queryType": "simple" oraz 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 zawierają "pool".

POST https://{{service-name}}.search.windows.net/indexes/hotel-rooms-sample/docs/search?api-version=2026-04-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ść kosztem 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 (niesklasyfikowane).

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

  • Wyszukiwanie frazy to dokładne wyrażenie ujęte w cudzysłów " ". 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 fraz "Roach Motel" w treści żądania może być określone jako "\"Roach Motel\"". Jeśli używasz Azure SDKs, 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ć sposób, w jaki terminy są tokenizowane podczas przetwarzania 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. Wyszukiwanie AI platformy Azure dopasuje dokumenty zawierające dowolne lub wszystkie terminy wyszukiwania, w tym różne odmiany znalezione podczas analizy tekstu.

Tak proste, jak to brzmi, istnieje jeden aspekt realizacji zapytań w Wyszukiwanie AI platformy Azure, który może generować nieoczekiwane wyniki, zwiększając zamiast zmniejszać wyniki wyszukiwania, gdy więcej terminów i operatorów zostaje dodanych do ciągu wejściowego. To, czy do rozszerzenia rzeczywiście dojdzie, zależy od uwzględnienia operatora NOT w połączeniu z ustawieniem parametru searchMode, które określa, jak NOT jest interpretowany w kategoriach AND lub OR zachowania. Aby uzyskać więcej informacji, zobacz operatora NOT w obszarze Operatory logiczne.

Operatory logiczne

Operatory logiczne (Boolean) można osadzić w zapytaniu, aby zwiększyć precyzję dopasowania. W prostej składni operatory logiczne są reprezentowane znakami. Operatory tekstu, takie jak słowo AND, nie są obsługiwane.

Znak Przykład Zastosowanie
+ 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 albo pool, albo ocean, albo oba. 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 zapytania reguluje, czy termin z operatorem NOT jest łączony czy oddzielany z innymi terminami w zapytaniu (zakładając brak operatorów logicznych w innych terminach). Prawidłowe wartości to any lub all.

searchMode=any zwiększa przypominanie zapytań, uwzględniając więcej wyników, a domyślnie - będzie interpretowany 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, z searchMode=any zapytaniem pool - ocean dopasowane zostaną dokumenty zawierające termin "pool" oraz 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 zamiast przypomnienia, a użytkownicy często używają operatora - podczas wyszukiwań.

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 z prefiksem

W przypadku zapytań "rozpoczyna się od" dodaj operator sufiksu (*) jako symbol zastępczy dla pozostałej części terminu. Przed dodaniem operatora sufiksu zapytanie musi zaczynać się od co najmniej jednego znaku zwykłego tekstu.

Znak Przykład Zastosowanie
* lingui* będzie pasowała do "językowych" lub "linguini" Gwiazdka (*) reprezentuje jeden lub więcej znaków o 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 krawędziowa n-gramów, 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 infiksu do końca lub środka terminu użyj pełnej składni Lucene do wyszukiwania z użyciem 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, standardowy analizator usuwa i dzieli wyrazy na łącznikach, białych znakach, ampersandach oraz innych znakach 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 Microsoft, które zachowują pisownię łączoną wyrazó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 jako %23, jeśli jest używany w adresie URL. "&" i "=" są przykładami znaków zastrzeżonych, ponieważ ograniczają parametry i określają wartości w Wyszukiwanie AI platformy Azure. 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 znaków specjalnych, 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 language, taki jak analizator języka angielskiego Microsoft (en.microsoft), użyje ciągu "$" lub "€" jako tokenu.

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).

Zadbaj o to, aby podczas używania znaków Unicode symbole były prawidłowo escapowane w adresie URL zapytania (na przykład dla znaku "❤" należy użyć sekwencji ucieczki %E2%9D%A4+). Niektórzy klienci internetowi wykonują to tłumaczenie automatycznie.

Pierwszeństwo (grupowanie)

Możesz używać nawiasów do tworzenia podzapytań, włączając w to operatory wewnątrz instrukcji nawiasowej. 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 zajmujesz się tworzeniem zapytań programowo, przejrzyj Pełnotekstowe wyszukiwanie w Wyszukiwanie AI platformy Azure, aby zrozumieć etapy przetwarzania zapytań oraz implikacje analizy tekstu.

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

  • Last updated on