Aplikacje inteligentne i sztuczna inteligencja — często zadawane pytania

Dotyczy: SQL Server 2025 (17.x) Azure SQL DatabaseAzure SQL Managed InstanceBaza danych SQL w Microsoft Fabric

Ten artykuł zawiera często zadawane pytania dotyczące wektorów i osadzania w Database Engine SQL.

Aby uzyskać próbki i przykłady, odwiedź repozytorium SQL AI Samples.

Czy mogę stworzyć rozwiązanie typu retrieval-augmented generation (RAG) w całości w T-SQL?

Tak, możesz utworzyć rozwiązanie RAG (generowania wspomaganego wyszukiwaniem) oparte na natywnych funkcjach silnika bazy danych SQL. Język T-SQL umożliwia zaimplementowanie niezbędnej logiki pobierania i przetwarzania danych, a jednocześnie integrowanie z zewnętrznymi usługami sztucznej inteligencji na potrzeby aspektu generowania. Wektory mogą być przechowywane natywnie w silniku SQL, a połączenia z modelami LLM, które zapewniają możliwości rozumienia języka naturalnego, są możliwe za pośrednictwem sp_invoke_external_rest_endpoint.

Dlaczego miałbym utworzyć rozwiązanie RAG w całości w języku T-SQL?

Jeśli chcesz ulepszyć istniejącą aplikację bez konieczności ponownego tworzenia architektury w celu obsługi funkcji sztucznej inteligencji, użyj wbudowanych funkcji aparatu SQL, aby zaimplementować funkcje sztucznej inteligencji bezpośrednio w zapytaniach bazy danych. Wystarczy zaktualizować kod T-SQL, aby uwzględnić funkcje sztucznej inteligencji, zamiast wprowadzać obszerne zmiany w architekturze aplikacji.

Czy istnieją kompleksowe przykłady korzystające z usługi Azure SQL lub Fabric SQL for RAG?

Na pewno możesz znaleźć kompleksowe przykłady dla programu RAG przy użyciu usług Azure SQL i Fabric SQL tutaj:

Czy RAG może działać na danych ustrukturyzowanych, na przykład kolumnach i wierszach?

Jeśli musisz pracować z danymi ustrukturyzowanymi, nadal możesz wykorzystać funkcję RAG, łącząc ją z innymi technikami, takimi jak użycie osadzania w celu reprezentowania danych strukturalnych w sposób zrozumiały dla modelu sztucznej inteligencji. Dzięki temu można wykonywać zadania pobierania i generowania danych strukturalnych, jednocześnie korzystając z możliwości programu RAG.

Dlaczego wysyłanie pełnego, złożonego schematu do usługi LLM prowadzi do słabego generowania kodu SQL i jak mogę go naprawić?

Jeśli masz złożony i duży schemat bazy danych z setkami tabel i widoków, lepiej jest użyć podejścia obejmującego wiele agentów, aby zmniejszyć szum i umożliwić modelom sztucznej inteligencji skupienie się na określonych obszarach schematu. Pełny opis wraz z kompletnym przykładem pracy jest dostępny tutaj:

Czy mogę nawiązać połączenie z usługą Azure OpenAI przy użyciu tożsamości zarządzanej?

Tak, możesz nawiązać połączenie z usługą Azure OpenAI przy użyciu tożsamości zarządzanej. Dzięki temu można bezpiecznie uwierzytelniać się i uzyskiwać dostęp do usługi Azure OpenAI Bez konieczności bezpośredniego zarządzania poświadczeniami. Aby uzyskać więcej informacji, zobacz:

Czy moje dane są używane przez Microsoft do trenowania modeli?

No. Dane nie są używane przez firmę Microsoft do trenowania modeli. Aby uzyskać więcej informacji, zobacz dokumentację odpowiedzialnej sztucznej inteligencji.

Jakie dane przetwarza usługa Azure OpenAI?

Aby uzyskać szczegółowe informacje o tym, jak przetwarzane są dane przekazywane przez użytkownika do modeli Azure Direct Models w usłudze Microsoft Foundry, zobacz Dane, prywatność i zabezpieczenia w usłudze Azure OpenAI Service. Model "Azure Direct Model" to model sztucznej inteligencji wyznaczony i wdrożony jako model "Azure Direct Model" w narzędziu Foundry i obejmuje modele Azure OpenAI.

Jak mogę chronić moje dane przed nieautoryzowanym dostępem agenta sztucznej inteligencji?

Usługi Azure SQL i SQL Server zapewniają rozbudowaną obsługę szczegółowych zabezpieczeń dostępu:

  • Rozpoczęcie pracy z uprawnieniami silnika bazy danych: Kontroluj dostęp do obiektów bazy danych na szczegółowym poziomie za pomocą uprawnień.
  • Użyj procedur składowanych, które wykonują specjalnie autoryzowane operacje w ramach barier zabezpieczających. Przyznaj agentowi uprawnienia EXECUTE tylko w razie potrzeby, zamiast udzielać bezpośredniego dostępu do bazowych tabel. W ten sposób agenci wchodzą w interakcję z bazą danych deterministycznie przy użyciu wstępnie napisanych instrukcji języka T-SQL.
  • Row-Level Security (RLS): Kontrolowanie dostępu do wierszy w tabeli na podstawie cech użytkownika wykonującego zapytanie. Możesz zobaczyć RLS w działaniu w tym wideo.
  • Dynamiczne maskowanie danych: ogranicz narażenie poufnych danych, maskując je użytkownikom niebędącym uprzywilejowanymi.
  • Always Encrypted: chroń poufne dane, szyfrując je magazynowane i przesyłane, zapewniając, że tylko autoryzowani użytkownicy mogą uzyskiwać dostęp do niezaszyfrowanych danych.

Aby uzyskać więcej informacji na temat inspekcji w Database Engine SQL, zobacz: