VoyageAI by MongoDB: rerank-3-lite

Voyage rerank-3-lite on Voyagen Rerank 3 -sarjan viiveeseen keskittyvä versio. Se vastaanottaa tekstikyselyn ja ehdolla olevat asiakirjat, arvioi kunkin kysely–asiakirja-parin yhdessä ja palauttaa relevanssipisteet järjestettyinä. Se palvelee haun toista vaihetta: upotus- tai avainsanahaku löytää ehdokkaat, minkä jälkeen Lite tarkentaa niiden järjestystä. Tuloksena on järjestys käytettäväksi haussa tai hakua hyödyntävän generoinnin työnkulussa.

Mitä Rerank 3 Litessä muuttuu Valmistaja korostaa parempaa hakua pitkistä asiakirjoista ja koodista verrattuna rerank-2.5-liteen. Molemmat Rerank 3 -versiot säilyttävät ohjeiden noudattamisen ja saman 32K:n kontekstiluokan, kun taas Lite on suunniteltu viiveherkkiin sovelluksiin. Siksi se on käytännöllinen ehdokas interaktiiviseen tietopankkihakuun, tukiasiakirjojen hakuun ja koodihakuun, kun käyttäjät tarvitsevat olennaiset tulokset nopeasti. Valitse se todellisen kokoelman laatu- ja vasteaikavaatimusten mukaan sen sijaan, että olettaisit pienemmän version tarkoittavan pienempää konteksti-ikkunaa.

Ohjaa relevanssia kyselyllä Kyselyn mukana voi antaa luonnollisen kielen ohjeita siitä, mikä lasketaan olennaiseksi. Pidä kysymys ja relevanssitoive tiiviinä ja keskenään johdonmukaisina. Ohjelmistotuen haussa voit käyttää ohjetta: ”Etsi laitteen nollausmenettely; painota ilmoitetun laiteversion ohjeita.” Lisää monitulkintaiseen tuotenimeen tuoteluokka, jotta asiaan liittymättömät merkitykset eivät hallitse tuloksia. Kyselyn toive ohjaa semanttista pisteytystä; valitse oikea tuote, asiakirjaversio tai käyttöoikeusrajaus kokoelman selkeiden metatietojen avulla ennen ehdokasluettelon rakentamista.

Valmistele tekstiehdokkaiden rajattu luettelo Syöteasiakirjat ovat merkkijonoja. Poimi lähdeaineistosta luettava teksti ja säilytä hyödylliset otsikot, väliotsikot, tunnisteet ja ympäröivä konteksti. Säilytä pysyvä yhteys jokaisen syötepaikan ja alkuperäisen tietueen välillä. Liitä vianmääritysartikkelista oire ja olennainen menettely pelkän irrallisen lauseen sijaan. Liitä lähdekoodihaussa funktio ja sen läheltä tarvittavat tiedot, jotka erottavat sen samannimisistä funktioista. Poista toistuva navigointi tai vakioteksti, kun se syrjäyttää hyödyllisen tekstikohdan.

Uudelleenjärjestäjä voi järjestää vain saamansa asiakirjat. Jos ensimmäinen haku ei koskaan löydä olennaista artikkelia, tämä vaihe ei voi palauttaa puuttuvaa ehdokasta. Tarkista sekä ehdokasluettelo että lopullinen järjestys, kun tulos näyttää väärältä. Kun pitkä asiakirja kattaa monta aihetta, erota yhtenäiset osiot ja säilytä niiden viitteet pääasiakirjaan, jotta olennainen osio voidaan valita menettämättä lähdettä.

Konteksti- ja pyyntörajat Valmistajan nykyinen opas määrittää kyselyn enimmäiskooksi 8 000 tokenia ja kyselyn sekä kunkin yksittäisen asiakirjan yhteiseksi enimmäiskooksi 32 000 tokenia. Se sallii enintään 1 000 ehdokasasiakirjaa ja 600 000 tokenin kokonaisbudjetin pyynnölle. Budjetti lasketaan kertomalla kyselytokenit asiakirjojen määrällä ja lisäämällä kaikki asiakirjatokenit. Pitkä kysely kuluttaa siten tilaa jokaisessa parissa ja kasvattaa kokonaisbudjettia toistuvasti. Laske lähetetyn tekstin tokenit asianmukaisella mallitokenisoijalla sen sijaan, että pitäisit merkkejä, sanoja ja tokeneita keskenään vaihdettavina.

Esimerkiksi 500 tokenin kysely ja 100 asiakirjaa, joista jokainen sisältää 4 000 tokenia, muodostavat tämän kaavan mukaan 450 000 syötetokenia. Tämä havainnollistaa budjetointia eikä suositeltua ehdokasluettelon kokoa tai mitattua nopeustulosta. Dokumentoitu katkaisuvaihtoehto on oletusarvoisesti käytössä; liian pitkää tekstiä voidaan lyhentää ennen pisteytystä. Valmistele tärkeät osiot tarkoituksella, jotta katkaisu ei poista juuri sitä tekstikohtaa, jonka tulee vastata kyselyyn.

Lue ja käytä tulos Tulokset järjestetään suurimmasta relevanssipisteestä alaspäin. Kukin tulos yksilöi asiakirjan alkuperäisen syötepaikan, jolloin sovellus voi liittää siihen oman otsikkonsa, tietuetunnisteensa ja lähteensä. top_k-asetus määrää palautettavien järjestettyjen ehdokkaiden määrän; ilman sitä palautetaan kaikki ehdokkaat. Valmistajan REST-rajapinta voi palauttaa myös asiakirjatekstin. Säilytä alkuperäiset tunnisteet valittujen tulosten rinnalla, kun näytät hakusivun tai välität näyttöä vastausta generoivaan vaiheeseen.

Relevanssipiste ilmaisee, kuinka hyvin ehdokas vastaa kyselyä; se ei osoita ehdokkaan väitteiden olevan oikeita. Vertaa korkeimmalle sijoitettuja kohteita käyttäjän todelliseen kysymykseen, mukaan lukien poissulut ja asiakirjaversioiden erot. Jos jokainen ehdokas on epäolennainen, korkeimmalle sijoitettu kohde on silti olemassa. Päätä kokoelman edustavien kyselyjen avulla, miten sovelluksesi käsittelee tämän tilanteen.

Päivittäminen ja version valitseminen Valmistaja kuvaa rerank-3-liten rerank-2.5-liten päivitykseksi, jonka API-semantiikka on ennallaan ja pisteet on kalibroitu vastaavan edeltäjän jakaumaan. Säilytä nykyinen tietueiden kohdistus ja hakuvaihe ja vertaa sitten syntyvää järjestystä merkityksellisillä kyselyillä ennen vakiintuneeseen pisterajaan luottamista. Käytä Liteä hakukokemukseen, jossa vasteaika on tärkeä; käytä laatupainotteista rerank-3-versiota vertailukohtana, kun vaikeiden ehdokkaiden relevanssi on tärkeämpi prioriteetti.