Přesun velkých jazykových modelů (LLM) do reálných obchodních aplikací

Velké jazykové modely jsou všude. Každá zákaznická konverzace nebo VC prezentace zahrnuje otázky o tom, jak je LLM technologie připravena a jak bude pohánět budoucí aplikace. Některé vzorce jsem již pokryl v mém předchozím příspěvku. Zde budu mluvit o některých reálných vzorcích pro aplikaci v farmaceutickém průmyslu, na které pracovala společnost Persistent Systems.

Velké jazykové modely a jejich jádrové přednosti

LLM jsou dobré v porozumění jazyka, to je jejich silná stránka. Nejčastějším vzorcem, který vidíme u aplikací, je generace s podporou vyhledávání (RAG), kde je znalost externě sestavena z datových zdrojů a poskytnuta v kontextu jako podnět pro LLM, aby parafrázoval odpověď. V tomto případě slouží jako první linie vyhledávání velmi rychlá vyhledávací mechanismy, jako jsou vektorové databáze a Elasticsearch-based enginy. Poté jsou výsledky vyhledávání sestaveny do podnětu a odeslány do LLM většinou jako API volání.

Dalším vzorcem je generování dotazu na strukturovaná data tím, že se LLM nakrmí datovým modelem jako podnětem a konkrétním uživatelským dotazem. Tento vzorec by mohl být použit pro vývoj pokročilého rozhraní “mluvte se svými daty” pro SQL databáze, jako je Snowflake, a také pro grafické databáze, jako je Neo4j.

Využití vzorců LLM pro reálné poznatky

Společnost Persistent Systems nedávno prozkoumala vzorec pro Blast Motion, sportovní telemetrickou společnost (analýza swingů pro baseball, golf atd.), kde jsme analyzovali časové řady shrnutí hráčů, abychom získali doporučení.

Pro složitější aplikace často potřebujeme řetězit požadavky LLM s procesy mezi voláními. Pro farmaceutickou společnost jsme vyvinuli inteligentní aplikaci pro klinické studie, která filtruje pacienty pro klinické studie na základě kritérií extrahovaných z dokumentů klinických studií. Zde jsme použili přístup založený na řetězení LLM. Nejprve jsme vyvinuli LLM pro čtení dokumentů klinických studií a použili vzorec RAG pro extrakci kritérií pro zařazení a vyloučení.

Pro tento účel jsme použili relativně jednodušší LLM, jako je GPT-3.5-Turbo (ChatGPT). Poté jsme kombinovali tyto extrahované entity s datovým modelem SQL databáze v Snowflake, abychom vytvořili podnět. Tento podnět jsme pak zadali do výkonnějšího LLM, jako je GPT4, abychom získali SQL dotaz pro filtrování pacientů, který je připraven k spuštění na Snowflake. Díky tomu, že používáme řetězení LLM, můžeme použít několik LLM pro každou fázi řetězce, což nám umožňuje spravovat náklady.

V současné době jsme se rozhodli ponechat tento řetězec deterministický pro lepší kontrolu. To znamená, že jsme se rozhodli mít více inteligence v řetězci a udržet orchestraci velmi jednoduchou a předvídatelnou. Každý prvek řetězce je složitou aplikací, která by sama o sobě vyžadovala několik měsíců vývoje v předchozích dnech LLM.

Pohon pokročilejších případů použití

Pro pokročilejší případ bychom mohli použít agenty, jako je ReAct, aby LLM vytvořil krok za krokem instrukce pro konkrétní uživatelský dotaz. To by samozřejmě vyžadovalo vysoce výkonný LLM, jako je GPT4 nebo Cohere nebo Claude 2. Avšak pak existuje riziko, že model provede nesprávný krok, který bude muset být ověřen pomocí ochranných mechanismů. To je kompromis mezi přesunutím inteligence do ovladatelných odkazů řetězce nebo vytvořením celého řetězce autonomního.

Dnes, když se zvykáme na éru generativní umělé inteligence pro jazyk, průmysl začíná přijímat aplikace LLM s předvídatelnými řetězci. Jakmile se toto přijetí rozšíří, brzy začneme experimentovat s více autonomií pro tyto řetězce prostřednictvím agentů. To je to, o čem se vede debata o AGI, a jsme zvědavi, jak se vše bude vyvíjet v průběhu času.