VoyageAI by MongoDB: rerank-3

Voyage rerank-3 on tekstin uudelleenjärjestäjä, joka on suunniteltu parantamaan haetun näytön laatua. Se vastaanottaa kyselyn ja ehdokasasiakirjojen luettelon, tarkastelee jokaista paria yhdessä ja palauttaa ehdokkaat relevanssijärjestyksessä. Upotukset ja avainsanahaku voivat ensin rajata suuren kokoelman hallittavaan ehdokasluetteloon; rerank-3 soveltaa sitten tähän luetteloon tarkempaa relevanssiarviota. Sen tulos on pisteytettyä hakunäyttöä, jonka sovellus voi näyttää tai välittää erilliseen vastauksen generointivaiheeseen.

Laatupainotteinen Rerank 3 Valmistaja asemoi rerank-3:n tarkkuuteen keskittyväksi versioksi ja rerank-3-liten viiveherkän haun versioksi. Kolmas sukupolvi päivittää mallin rungon ja koulutusaineistoyhdistelmän ja parantaa erityisesti pitkien asiakirjojen ja lähdekoodin hakua verrattuna vastaaviin 2.5-edeltäjiin. Valmistaja arvioi sitä teknisessä dokumentaatiossa, koodissa, monikielisessä aineistossa ja muilla asiakirja-aloilla. Tulokset tukevat sen hakuroolia; valitse versio oman kokoelmasi kannalta tärkeiden kysymysten ja ehdokasasiakirjojen avulla.

Pitkät asiakirjat riittävällä kontekstilla Pitkä ehdokas voi sisältää hyödyllistä kontekstia paljon aloituskappaletta kauempana. Toimita yhtenäinen osio tai asiakirja otsikkoineen ja olennaisine ympäröivine aineistoineen, jotta malli voi arvioida varsinaisen kysymyksen suhdetta sisältöön. Tuotekäytäntöjen haussa säilytä kiinnostavan tekstikohdan ympärillä olevat otsikot ja poikkeukset. Jos useita haettuja osioita tulee samasta lähteestä, säilytä niiden asiakirja- ja osiotunnisteet; sovellus voi sitten näyttää valitun näytön alkuperän.

Konteksti-ikkuna jaetaan kyselyn ja kunkin ehdokkaan kesken. Valmistajan nykyinen opas määrittää parin kooksi 32 000 tokenia, joihin sisältyy enintään 8 000 tokenin kysely. Siksi 3 000 tokenin kysely jättää kullekin asiakirjalle enintään 29 000 tokenia. Valmistele syöte niin, että sen olennainen sisältö mahtuu mukaan, etenkin jos pitkä johdanto tai toistuva vakioteksti muuten kuluttaisi ikkunan. Dokumentoitu katkaisuvaihtoehto on oletusarvoisesti käytössä ja voi lyhentää liian pitkää kysely- tai asiakirjatekstiä ennen pisteytystä. Tarkasta säilyvä sisältö, kun tekstikohdan sijainnilla on merkitystä.

Koodin ja teknisen aineiston haku Ohjelmointiavustajan hakuvaiheessa ehdokkaat voivat sisältää funktiototeutuksia, API-dokumentaatiota tai teknisiä selityksiä tekstinä. Liitä mukaan symbolit, funktiosignatuurit ja konteksti, joita tarvitaan samankaltaisten ehdokkaiden erottamiseen. Esimerkiksi kysely ”Etsi funktio, joka normalisoi polut säilyttäen lopussa olevan erottimen” antaa konkreettisen täsmäytettävän toiminnan. Liitä olennaiset kieli-, alusta- tai versiorajoitteet. Tarkasta järjestämisen jälkeen valittu koodi ja sen riippuvuudet ennen sen käyttämistä kontekstina; relevanssipiste ei todista toteutuksen täyttävän jokaista ilmoitettua vaatimusta.

Ohjeet määrittävät relevanssin Malli säilyttää Rerank 2.5:ssä esitellyn ohjeita noudattavan uudelleenjärjestämisen kyvyn. Lisää tiivis ohje kyselyn alkuun tai loppuun, kun käyttäjän tarkoitus tarvitsee täsmennystä. Selitä tutkimusasiakirjojen haussa, painotetaanko otsikkoa, tiettyä menetelmää vai sovellusalaa. Määritä sisäisessä luettelossa, koskeeko pyyntö asennusta, vianmääritystä vai yhteensopivuutta. Pidä ohje linjassa kysymyksen kanssa; pääpyynnön kanssa ristiriitaiset lisätoiveet voivat muuttaa sitä, mitä järjestys pyrkii optimoimaan.

Valmistele ehdokasasiakirjat ja budjetit Syöte on tekstimerkkijonojen luettelo. Poimi lähdeasiakirjoista käyttökelpoinen teksti, säilytä mielekkäät osiorajat ja pidä luettelon rinnalla järjestettyä tietuekarttaa. Valmistaja sallii enintään 1 000 asiakirjaa yhdessä pyynnössä. Se määrittää myös 600 000 tokenin yhteisen syöterajan: kyselytokenit kerrottuna asiakirjojen määrällä sekä kaikkien asiakirjatokenien summa. Tämä eroaa parikohtaisesta kontekstirajasta. Ylimääräisen kyselytekstin vähentäminen voi säästää sekä parin kapasiteettia että pyynnön kokonaisbudjettia.

Laske tokenit asianmukaiselle mallille sen sijaan, että olettaisit sana- tai merkkimäärän olevan tokenimäärä. Valitse suurista ehdokkaista yhtenäiset tekstikohdat tai jaa aineisto hyödyllisten otsikoiden mukaan säilyttäen tiedot päälähteestä. Uudelleenjärjestäminen on hyödyllisintä sen jälkeen, kun ensimmäinen haku on jo löytänyt mahdollisia ehdokkaita: se ei voi sijoittaa puuttuvaa lähdettä, joka ei koskaan päätynyt luetteloon.

Järjestetyt tulokset ja jatkokäyttö Tulos sisältää relevanssipisteet ja alkuperäisiin syöteasiakirjoihin viittaavat indeksit laskevassa relevanssijärjestyksessä. top_k-vaihtoehto rajaa palautettavien järjestettyjen tulosten määrää; muuten palautetaan kaikki syöte-ehdokkaat. Valmistajan REST-rajapinta sallii myös asiakirjatekstin sisällyttämisen. Käytä kutakin alkuperäistä indeksiä otsikon, lähdetunnisteen ja sovelluksesi tarvitsemien metatietojen hakemiseen ja näytä sitten valitut kohteet tai kokoa olennainen teksti vastauksen näyttökontekstiin.

Tarkasta ylimmät tulokset kysymystä vasten ja pidä lähteen identiteetti näkyvissä. Korkea suhteellinen sijoitus ei varmista asiakirjan tietojen oikeellisuutta, ja vain huonoja ehdokkaita sisältävällä luettelolla on silti ensimmäinen kohde. Erota relevanssin valitseminen sen päättämisestä, riittääkö valittu näyttö käyttäjälle vastaamiseen.

Version vaihtaminen Valmistaja kuvaa rerank-3:a suoraan käyttöön sopivaksi rerank-2.5:n seuraajaksi, jonka API-semantiikka on sama ja pisteet on kalibroitu vastaavan edeltäjän jakaumaan. Yhteensopivuus tukee nykyisen hakuvaiheen ja tietueiden kohdistuksen säilyttämistä. Vertaa merkityksellisiä tulosjärjestyksiä ja mahdollisia pisterajoja nykyisellä aineistolla ennen vaihtoon luottamista. Pidä rerank-3 ja rerank-3-lite erillisinä valintoina: yhteiset rajat ja ohjeiden noudattaminen eivät tee niiden laatu- ja viiveprioriteeteista samoja.