Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 er en mixture-of-experts-språkmodell utformet for agentbasert koding og langvarig arbeid. Den har 118B parametere totalt og omtrent 8B aktive per token, noe som plasserer den mellom den mindre Laguna XS 2.1 og den større Laguna M.1 i produsentens serie. Modellen behandler tekst og produserer tekst, kode, resonnering og forespørsler om verktøykall i en verktøytilkoblet applikasjon.

Arkitekturen kombinerer global oppmerksomhet og oppmerksomhet med glidende vindu over 48 lag: 12 globale lag og 36 lag med glidende vindu. Det glidende vinduet på 512 token beskriver lokal oppmerksomhet i disse lagene, mens den dokumenterte modellkonteksten er på 1,048,576 token. Dette er ulike mål. Den større konteksten støtter oppgaver som samler kildefiler, observasjoner og beslutninger over mange trinn. Hold arbeidsmålet og meningsfullt belegg samlet, og reserver plass til senere resonnering og sluttsvaret innenfor gjeldende konfigurasjon.

Modellens hovedformål er programvarearbeid som krever utholdenhet, kontroll og revisjon. For en oppgave i en kodebase bør du oppgi forventet oppførsel, relevante filer som tekst, avhengighetsinformasjon og de faktiske utdataene som viser svikten. Be om et avgrenset resultat: «Spor årsaken til denne regresjonen, foreslå en endring som bevarer det dokumenterte grensesnittet, og identifiser kontrollene som vil skille en retting fra en uvedkommende endring.» I en verktøytilkoblet arbeidsflyt bør modellen få resultatet av hver utførte kontroll før den velger neste trinn.

For optimaliseringsarbeid bør du oppgi målinger og et uttrykkelig mål. Et eksempel er: «Bruk denne profilen og allokeringsrapporten til å identifisere en flaskehals. Foreslå én endring, forklar forventet effekt, og sammenlign med utgangspunktet etter at samme måling er gjentatt.» Dette gjør en ytelsespåstand mulig å etterprøve. Poolsides utgivelse omtaler verifikasjon og fortsatt fremdrift som viktige egenskaper, men en overbevisende forklaring alene fastslår ikke at en revisjon er raskere, riktig eller fullstendig. Bevar observasjonene som støtter å beholde eller forkaste endringen.

Laguna S 2.1 støtter innflettet tenkning før og mellom verktøykall. Produsenten anbefaler å bevare resonneringsinnhold fra tidligere assistentmeldinger i påfølgende historikk; å utelate disse blokkene kan få resonneringen til å stoppe i oppfølgingstrinn. Hold assistentsvaret, informasjonen om verktøykallet og det tilhørende verktøyresultatet samlet. Dette hjelper en lengre oppgave med å fortsette fra sin faktiske tilstand fremfor gjentatte ganger å rekonstruere det som allerede er forsøkt.

De dokumenterte valgene for tenkning er off og max, med max aktivert som standard i oppsettet produsenten beskriver. Modellen bestemmer tenkebudsjettet i denne modusen; utgivelsen presenterer ikke egne kontroller for nivåene low, medium og high. For agentbasert koding anbefaler Poolside å aktivere tenkning og beholde den mellom trinnene. Oppgi sluttprodukt og fullføringskriterier uttrykkelig, og skill en lang resonneringssekvens fra det fullførte resultatet. Produsenten identifiserer overtenkning, særlig i konkurransematematikk, som en vesentlig begrensning.

Verktøydefinisjoner krever særlig omtanke. Poolside rapporterer at S 2.1 innledningsvis kan støtte seg på et kjent verktøygrensesnitt fremfor å følge et lignende, men forskjellig skjema nøye. Den kan også produsere feilformet eller feilaktig escaped JSON når et verktøyargument inneholder en nestet matrise. Oppgi de faktiske argumentdefinisjonene, valider foreslåtte kall, og returner en presis feil når kallet ikke samsvarer. Produsenten beskriver korrigering gjennom tilbakemelding i konteksten som en måte å løse enkelte av disse avvikene på. Hold den resulterende verktøyobservasjonen tilgjengelig for neste beslutning.

Produsenten publiserer egne BF16- og kvantiserte varianter og en valgfri DFlash-utkastmodell. Dette er separate produkter og serveringsoppskrifter, så minnebruken til et kvantisert sjekkpunkt eller ytelsen ved spekulativ dekoding bør ikke antas ut fra det generelle modellnavnet. For vanlig tekstarbeid bør du klargjøre kildekode, kommandoutdata og dokumentutdrag som lesbar tekst. Utgivelsen bemerker at modellen mangler synsevne; et skjermbilde trenger en tekstlig observasjon eller et passende eksternt inspeksjonstrinn før det kan støtte analysen.

Be om en sluttleveranse som identifiserer det endrede produktet, viktige beslutninger, observerte kontroller og eventuelle uavklarte forhold. Ved kodegjennomgang bør funn knyttes til relevant kildekode, med en forklaring på hvorfor hvert problem påvirker oppførselen. Ved en retting bør den foreslåtte endringen skilles fra en endring der oppførselen faktisk er kontrollert. Å beholde resonnering og verktøyhistorikk hjelper modellen gjennom oppgaven, mens sluttproduktet og registrerte resultater fastslår hva som ble oppnådd.