Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Note
Azure AI Keresés a Azure portálon, REST API-kon és Azure SDK-k keresztül érhető el. Emellett a Foundry IQ-t is támogatja, amely a vállalati tartalmakat újrafelhasználható, engedélytudatos tudásbázisokká alakítja át az Microsoft Foundry portálon található ügynökök számára.
A nagyméretű dokumentumok kisebb blokkokra való particionálása segíthet Önnek a chat-interakciók befejezésére és a beágyazási modellek maximális token-beviteli korlátjainak betartásában. Az Azure OpenAI szövegbeágyazási-3-kicsi modell bemeneti szövegének maximális hossza például 8191 token. Mivel minden token körülbelül négy karakterből áll a közös OpenAI-modellek esetében, ez a maximális korlát körülbelül 6000 szó szövegnek felel meg. Ha ezeket a modelleket használja beágyazások létrehozásához, kritikus fontosságú, hogy a bemeneti szöveg a korlát alatt maradjon.
A csevegő modellek ugyanazokat a bemeneti token korlátozásokat használják, ezért a darabolás hasznos lehet a visszakereséssel kiegészített generáció (RAG) vagy az ügynöki visszakereséshez is. A tartalom adattömbökre való particionálása segít megfelelni a bemeneti jogkivonat követelményeinek, és megakadályozza a csonkolás miatti adatvesztést.
Az Azure AI Keresés beépített megoldásokkal rendelkezik a tartalom darabolására, valamint az adattömbbe ágyazott tartalom vektorizálására is, ha vektorkeresést használ. A beépített megközelítés függőséget alkalmaz a beépített indexelők és képességkészletek között, amelyek lehetővé teszik a szövegfelosztást és a beágyazást. Ha nem tud integrált vektorizálást használni, ez a cikk néhány alternatív módszert ismertet a tartalom darabolásához.
Jótanács
Ha a tartalmat ágensalapú visszakereséshez darabolja fel, több tudásforrásból is létrehozható egy teljes indexelő folyamat, amely feldarabolja, és opcionálisan vektorizálja a tartalmat. Az indexelő, az adatforrás-definíció, a képességkészlet és az index a tudásbázis-definícióban szereplő információk alapján jön létre. Az ilyen képességgel rendelkező tudásbázisok közé tartozik a Azure Blob Storage vagy Azure Data Lake Storage Gen2 és OneLake.
Gyakori darabolási technikák
Az adattömbösítésre csak akkor van szükség, ha a forrásdokumentumok túl nagyok a modellek által előírt maximális bemeneti mérethez, de az is előnyös, ha a tartalom nem megfelelően jelenik meg egyetlen vektorként. Tekintsünk egy wikilapot, amely számos különböző altémakört fed le. Előfordulhat, hogy a teljes oldal elég kicsi ahhoz, hogy megfeleljen a modell bemeneti követelményeinek, de jobb eredményeket érhet el, ha kisebb egységekre bontja.
Íme néhány gyakori adattömbelési technika, amelyek beépített funkciókkal vannak társítva, ha indexelőket és készségeket használ.
| Megközelítés | Használat | Beépített funkciók |
|---|---|---|
| Rögzített méretű adattömbök | Definiáljon egy rögzített méretet, amely elegendő a szemantikailag értelmezhető bekezdésekhez (például 200 szó vagy 600 karakter), és lehetővé teszi bizonyos átfedéseket (például a tartalom 10–15%) jó adattömböket hozhat létre a vektorgenerátorok beágyazásához. | Szövegfelosztási képesség, oldalak szerinti felosztás (karakterhossz szerint definiálva) |
| Változó méretű adattömbök tartalomjellemzők alapján | Adatát tagolhatja mondatvégi írásjelek, sorvégi jelölők alapján, vagy a természetes nyelvi feldolgozási (NLP) könyvtárak azon funkcióinak felhasználásával, amelyek észlelik a dokumentumstruktúrát. A beágyazott korrektúra , például a HTML vagy a Markdown címsorszintaxissal rendelkezik, amely szakaszonkénti adattömbhöz használható. | Azure Content Understanding skill vagy Text Split skill (mondatok szerinti felosztás). |
| Szemantikai adattömbök | A tartalmat olyan értelmes egységekre bontja, amelyek megőrzik a mondatok és bekezdések kontextusát és szemantikai kapcsolatait. Ez a megközelítés olyan adattömböket hoz létre, amelyek jobban fenntartják a szemantikai koherenciát, és átfoghatják az oldalhatárokat. | Azure Content Understanding skill (szemantikai adattömbölés Markdown-kimenettel) |
| Egyéni kombinációk | Használjon rögzített és változó méretű adattömb-készítés kombinációját, vagy terjesszen ki egy megközelítést. Nagy méretű dokumentumok kezelésekor például használhat változó méretű adattömböket, de a dokumentum címét is hozzáfűzheti a dokumentum közepéről származó adattömbökhöz a környezet elvesztésének elkerülése érdekében. | Egyik sem |
| Dokumentum elemzése | Az indexelők feldolgozhatják a nagyobb forrásdokumentumokat kisebb keresési dokumentumokká az indexelés céljából. Szigorúan véve ez a megközelítés nem csoportosítás, de néha ugyanazt a célt érheti el. | Index Markdown-blobok és fájlok, egy-a-többhöz indexelés vagy Index JSON-blobok és -fájlok |
Tartalomfedés szempontjai
Ha az adatokat rögzített méretű darabokra bontja, az segíthet megőrizni a folytonosságot és a kontextust, ha a darabok között egy kis szöveg átfedésben marad. Javasoljuk, hogy kezdje az 512 token (körülbelül 2000 karakter) adattömbmérettel és 25%kezdeti átfedéssel, amely 128 tokennek felel meg. Ez az átfedés zökkenőmentesebb átmenetet biztosít az adattömbök között a túlzott duplikációk nélkül.
Az optimális átfedés a tartalomtípustól és a használati esettől függően változhat. A nagymértékben strukturált adatok például kisebb átfedést igényelhetnek, míg a társalgási vagy a kísérőszövegek több előnyt is élvezhetnek.
Az adatosztályozás tényezői
Az adattömbök használatakor gondolja át az alábbi tényezőket:
A dokumentumok alakja és sűrűsége. Ha ép szövegre vagy szakaszokra van szüksége, a nagyobb adattömbök és a mondatszerkezetet megőrző változó adattömbök jobb eredményeket hozhatnak.
Felhasználói lekérdezések: A nagyobb adattömbök és az egymást átfedő stratégiák segítenek megőrizni az adott információkat megcélozó lekérdezések kontextusát és szemantikai gazdagságát.
A nagyméretű nyelvi modellek (LLM) teljesítményre vonatkozó irányelvekkel rendelkeznek az adattömb méretére vonatkozóan. Keresse meg az összes használt modellhez legjobban megfelelő adattömbméretet. Ha például modelleket használ összegzéshez és beágyazáshoz, válasszon egy optimális adattömbméretet, amely mindkettőhöz használható.
Hogyan illeszkedik a darabolás a munkafolyamatba?
Ha nagy dokumentumokkal rendelkezik, illesszen be egy darabolási lépést az indexelési és lekérdezési munkafolyamatokba, amely nagy szövegrészeket bont fel. Az integrált vektorizálás használatakor gyakori az alapértelmezett adattömbelési stratégia a Szöveg felosztása képesség használatával. Egyéni darabolási stratégiát is alkalmazhat egyéni készséggel. Ez a kódhivatkozás egy szemantikai darabolási példát mutat be egy egyéni funkció használatával. Az adattömböket biztosító külső kódtárak közé tartoznak a következők:
A legtöbb kódtár gyakori adattömb-technikákat biztosít a rögzített mérethez, változómérethez vagy kombinációhoz. Olyan átfedést is megadhat, amely kis mennyiségű tartalmat duplikál az egyes adattömbökben a környezet megőrzése érdekében.
Példák adattömbökre
Az alábbi példák bemutatják, hogyan alkalmazzák az adattömb-stratégiákat a NASA Earth at Night e-book PDF-fájljára:
Példa szövegfelosztási képességre
Általánosan elérhető a Szövegfelosztási képességen keresztüli integrált adatbeosztás.
Ez a szakasz a készségalapú megközelítéssel és a szövegfelosztási képességparaméterekkel végzett beépített adattömböket ismerteti.
Ehhez a példához egy mintajegyzetfüzet található az azure-search-vector-samples adattárban.
Állítsa be textSplitMode , hogy kisebb adattömbökre bontsa a tartalmat:
-
pages(alapértelmezett). Az adattömbök több mondatból állnak. -
sentences. Az adattömbök egyetlen mondatból állnak. Ami "mondatot" jelent, az nyelvfüggő. Angol nyelven szabványos mondatvégződést használ, például.vagy!használ. A nyelvet adefaultLanguageCodeparaméter vezérli.
A pages paraméter további paramétereket ad hozzá:
-
maximumPageLengthegyes szegmensekben legfeljebb 1 karaktert vagy 2 jogkivonatot határoz meg. A szövegelosztó elkerüli a mondatok felosztását, így a tényleges karakterszám a tartalomtól függ. -
pageOverlapLengthMeghatározza, hogy az előző oldal végétől hány karakter szerepel a következő oldal elején. Ha be van állítva, ennek a maximális oldalhossznak kevesebbnek kell lennie, mint a fele. -
maximumPagesToTakemeghatározza, hogy hány oldalt/adattömbet kell egy dokumentumból átvenni. Az alapértelmezett érték 0, ami azt jelenti, hogy az összes lapot vagy adattömbet ki kell venni a dokumentumból.
1 A karakterek nem illeszkednek a token definíciójához. Az LLM által mért tokenek száma eltérhet a rögzített karakterméretű Szöveg felosztó képesség által mért karakterszámtól.
2 A tokenekre bontás a Skillsets - Create or Update (REST API) legújabb előzetes verziójában érhető el, és további paramétereket tartalmaz egy tokenizáló, valamint a darabolás során nem szétbontandó tokenek megadásához.
Az alábbi táblázat bemutatja, hogy a paraméterek kiválasztása hogyan befolyásolja a teljes adattömbök számát a Föld éjjel e-könyvében.
textSplitMode |
maximumPageLength |
pageOverlapLength |
Teljes adattömbszám |
|---|---|---|---|
pages |
1000 | 0 | 172 |
pages |
1000 | 200 | 216 |
pages |
2000. | 0 | 85 |
pages |
2000. | ötszáz | 113 |
pages |
5 000 | 0 | 34 |
pages |
5 000 | ötszáz | 38 |
sentences |
Nem alkalmazható | Nem alkalmazható | 13361 |
textSplitMode
pages használata a legtöbb adattömb esetében azt eredményezi, hogy a teljes karakterszám közel van maximumPageLength. A karakterek száma az adott szegmensben attól függ, hogy a mondathatárok hol helyezkednek el az adott szegmensben. A darab/kód hossza változik az adattömb tartalmának különféle eltérései miatt.
A paraméterek optimális kiválasztása az adattömbök használatától függ. A legtöbb alkalmazás esetében ajánlott a következő alapértelmezett paraméterekkel kezdeni a karakterek számának használatakor:
textSplitMode |
maximumPageLength |
pageOverlapLength |
|---|---|---|
pages |
2000. | ötszáz |
LangChain-adatdarabolási példa
A LangChain dokumentumbetöltőket és szövegosztókat biztosít. Ez a példa bemutatja, hogyan tölthet be PDF-fájlokat, hogyan kérhet le jogkivonatokat, és hogyan állíthat be szövegelosztót. A tokenek számának lekérésével megalapozott döntést hozhat a darabok méretezéséről.
Ehhez a példához egy mintajegyzetfüzet található az azure-search-vector-samples adattárban.
from langchain_community.document_loaders import PyPDFLoader
loader = PyPDFLoader("./data/earth_at_night_508.pdf")
pages = loader.load()
print(len(pages))
A kimenet 200 dokumentumot vagy lapot jelöl a PDF-fájlban.
A lapok becsült tokenszámának lekéréséhez használja a TikTokent.
import tiktoken
tokenizer = tiktoken.get_encoding('cl100k_base')
def tiktoken_len(text):
tokens = tokenizer.encode(
text,
disallowed_special=()
)
return len(tokens)
tiktoken.encoding_for_model('gpt-4.1-mini')
# create the length function
token_counts = []
for page in pages:
token_counts.append(tiktoken_len(page.page_content))
min_token_count = min(token_counts)
avg_token_count = int(sum(token_counts) / len(token_counts))
max_token_count = max(token_counts)
# print token counts
print(f"Min: {min_token_count}")
print(f"Avg: {avg_token_count}")
print(f"Max: {max_token_count}")
A kimenet azt jelzi, hogy egyetlen oldal sem rendelkezik nulla tokennel, az átlagos tokenszám oldalanként 189 token, és bármely oldal maximális tokenszáma 1583.
Az átlagos és maximális tokenméret ismeretében betekintést nyerhet az adattömb méretének beállításába. Bár a szabványos 2000 karakteres javaslatot használhatja 500 karakteres átfedéssel, ebben az esetben érdemes alacsonyabbra csökkenteni a tokenek száma alapján a mintadokumentumban. A túl nagy átfedési érték beállítása valójában azt eredményezheti, hogy egyáltalán nem jelenik meg átfedés.
from langchain.text_splitter import RecursiveCharacterTextSplitter
# split documents into text and embeddings
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
length_function=len,
is_separator_regex=False
)
chunks = text_splitter.split_documents(pages)
print(chunks[20])
print(chunks[21])
Két egymást követő adattömb kimenete az első adattömb szövegét jeleníti meg, amely átfedésben van a második adattömbtel. A kimenet könnyen szerkeszthető az olvashatóság érdekében.
'x Earth at NightForeword\nNASA's Earth at Night explores the brilliance of our planet when it is in darkness. \n It is a compilation of stories depicting the interactions between science and \nwonder, and I am pleased to share this visually stunning and captivating exploration of \nour home planet.\nFrom space, our Earth looks tranquil. The blue ethereal vastness of the oceans \nharmoniously shares the space with verdant green land-an undercurrent of gentle-ness and solitude. But spending time gazing at the images presented in this book, our home planet at night instantly reveals a different reality. Beautiful, filled with glow-ing communities, natural wonders, and striking illumination, our world is bustling with activity and life.**\nDarkness is not void of illumination. It is the contrast, the area between light and'** metadata={'source': './data/earth_at_night_508.pdf', 'page': 9}
'**Darkness is not void of illumination. It is the contrast, the area between light and **\ndark, that is often the most illustrative. Darkness reminds me of where I came from and where I am now-from a small town in the mountains, to the unique vantage point of the Nation's capital. Darkness is where dreamers and learners of all ages peer into the universe and think of questions about themselves and their space in the cosmos. Light is where they work, where they gather, and take time together.\nNASA's spacefaring satellites have compiled an unprecedented record of our \nEarth, and its luminescence in darkness, to captivate and spark curiosity. These missions see the contrast between dark and light through the lenses of scientific instruments. Our home planet is full of complex and dynamic cycles and processes. These soaring observers show us new ways to discern the nuances of light created by natural and human-made sources, such as auroras, wildfires, cities, phytoplankton, and volcanoes.' metadata={'source': './data/earth_at_night_508.pdf', 'page': 9}