Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 je jazykový model s architekturou mixture-of-experts navržený pro agentní programování a dlouhodobé úlohy. Má celkem 118 miliard parametrů a přibližně 8 miliard aktivních parametrů na token, čímž se v řadě výrobce řadí mezi menší Laguna XS 2.1 a větší Laguna M.1. Model zpracovává text a v aplikaci propojené s nástroji vytváří text, kód, uvažování a požadavky na volání nástrojů.

Jeho architektura kombinuje globální pozornost a pozornost s posuvným oknem ve 48 vrstvách: 12 globálních vrstvách a 36 vrstvách s posuvným oknem. Posuvné okno 512 tokenů popisuje lokální pozornost v těchto vrstvách, zatímco zdokumentovaný kontext modelu má 1 048 576 tokenů. Jde o různá měření. Větší kontext podporuje úlohy, v nichž se během mnoha kroků hromadí zdrojové soubory, pozorování a rozhodnutí. Pracovní cíl a smysluplné podklady uchovávejte společně a v rámci příslušné konfigurace vyhraďte prostor pro následné uvažování a konečnou odpověď.

Hlavním účelem modelu je softwarová práce vyžadující vytrvalost, kontrolu a revize. U úlohy v repozitáři poskytněte očekávané chování, příslušné soubory jako text, informace o závislostech a skutečný neúspěšný výstup. Požadujte cílený výsledek: „Vysleduj příčinu této regrese, navrhni změnu, která zachová zdokumentované rozhraní, a urči kontroly, které odliší opravu od nesouvisející změny.“ V postupu propojeném s nástroji dodejte modelu výsledek každé provedené kontroly, než zvolí další krok.

U optimalizace poskytněte měření a výslovný cíl. Příkladem je: „Pomocí tohoto profilu a přehledu alokací urči úzké místo. Navrhni jednu změnu, vysvětli očekávaný účinek a porovnej ji s výchozím stavem po zopakování stejného měření.“ Tvrzení o výkonu tak bude možné zkontrolovat. Vydání Poolside popisuje ověřování a pokračující postup jako důležité chování, samotné přesvědčivé vysvětlení však nedokládá, že je revize rychlejší, správná nebo úplná. Zachovejte pozorování, která podporují ponechání nebo zamítnutí změny.

Laguna S 2.1 podporuje průběžné uvažování před voláními nástrojů a mezi nimi. Výrobce doporučuje v následné historii zachovat obsah uvažování z dřívějších zpráv asistenta; vynechání těchto bloků může v navazujících krocích způsobit zastavení uvažování. Odpověď asistenta, informace o volání nástroje a odpovídající výsledek nástroje uchovávejte pohromadě. Delší úloha tak může navazovat na svůj skutečný stav namísto opakovaného rekonstruování již vyzkoušených kroků.

Zdokumentované možnosti uvažování jsou off a max, přičemž v nastavení popsaném výrobcem je ve výchozím stavu zapnuto max. V tomto režimu model určuje svůj rozpočet uvažování; vydání nepředstavuje samostatné volby úsilí low, medium a high. Pro agentní programování Poolside doporučuje uvažování zapnout a uchovávat je mezi kroky. Výslovně uveďte konečný artefakt a kritéria dokončení a odlišujte dlouhou posloupnost uvažování od dokončeného výsledku. Výrobce označuje nadměrné přemýšlení, zvláště u soutěžní matematiky, za podstatné omezení.

Definice nástrojů vyžadují zvláštní péči. Poolside uvádí, že S 2.1 se může zpočátku opírat o známé rozhraní nástroje namísto pozorného dodržení podobného, ale odlišného schématu. Může také vytvářet chybně formátovaný nebo nesprávně escapovaný JSON, pokud argument nástroje obsahuje vnořené pole. Poskytněte skutečné definice argumentů, ověřujte navržená volání a při neshodě vraťte přesnou chybu. Výrobce popisuje opravu pomocí zpětné vazby v kontextu jako způsob řešení některých těchto neshod. Výsledné pozorování nástroje ponechte dostupné pro další rozhodnutí.

Výrobce vydává samostatné varianty BF16 a kvantizované varianty a volitelný pomocný návrhový model DFlash. Jde o odlišné artefakty a postupy obsluhy, takže paměťovou spotřebu kvantizovaného checkpointu nebo výkon spekulativního dekódování nelze odvozovat z obecného názvu modelu. Pro běžnou textovou práci připravte zdrojový kód, výstupy příkazů a úryvky dokumentů jako čitelný text. Vydání uvádí, že model nemá obrazové schopnosti; snímek obrazovky proto potřebuje textové pozorování nebo vhodný externí krok kontroly, než může podpořit analýzu.

Požadujte konečný výstup, který určí změněný artefakt, důležitá rozhodnutí, pozorované kontroly a případnou nevyřešenou podmínku. Při revizi kódu propojte zjištění s příslušným zdrojem a ukažte, proč každý problém ovlivňuje chování. U opravy oddělte navrženou změnu od změny, jejíž chování bylo skutečně ověřeno. Zachování historie uvažování a nástrojů pomáhá modelu úlohou projít, zatímco konečný artefakt a zaznamenané výsledky dokládají, čeho bylo dosaženo.