偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

一文讀懂 RAG Fixed-Size Chunking 策略解析與優(yōu)秀實(shí)踐

人工智能
這篇文章將帶你深入解析固定切塊策略的核心邏輯、代碼實(shí)現(xiàn)與適用場(chǎng)景,讓你在構(gòu)建 RAG 應(yīng)用時(shí)少踩坑、多提效。

Hello folks,我是 Luga,今天我們來(lái)聊一下人工智能應(yīng)用場(chǎng)景 - 構(gòu)建高效、靈活的計(jì)算架構(gòu)的 RAG 架構(gòu)的切塊策略—Fixed-Size Chunking(固定切塊)。

眾所周知,在構(gòu)建 RAG(Retrieval-Augmented Generation,檢索增強(qiáng)生成)系統(tǒng)的過(guò)程中,文檔切塊策略往往決定了模型檢索質(zhì)量的上限。切得好,信息命中更精準(zhǔn),生成回答更有上下文邏輯;切得差,模型則容易“答非所問(wèn)”。

在眾多策略中,F(xiàn)ixed-Size Chunking(固定切塊)可謂最簡(jiǎn)單直接,卻也是最常被忽視的一種。看似粗暴,卻在實(shí)際工程中表現(xiàn)穩(wěn)定、適配廣泛,尤其適合對(duì)實(shí)時(shí)響應(yīng)和成本敏感的場(chǎng)景。

那么,F(xiàn)ixed-Size Chunking 到底該如何設(shè)置?有哪些常見(jiàn)誤區(qū)?它真的“簡(jiǎn)單有效”嗎?這篇文章將帶你深入解析固定切塊策略的核心邏輯、代碼實(shí)現(xiàn)與適用場(chǎng)景,讓你在構(gòu)建 RAG 應(yīng)用時(shí)少踩坑、多提效。

1. 如何理解 Fixed-Size Chunking ?

在檢索增強(qiáng)生成(RAG)系統(tǒng)中,文檔分塊(Chunking)是影響檢索效率和生成質(zhì)量的關(guān)鍵第一步,因此,在實(shí)際的業(yè)務(wù)場(chǎng)景中,理解并選擇合適的分塊策略便顯得至關(guān)重要。

然而,作為 9 大分塊策略中最為基礎(chǔ)且直觀(guān)的分塊方法,固定大小切分 (Fixed-Size Chunking) 擁有較為廣泛的應(yīng)用場(chǎng)景以及扮演著重要的角色。

固定大小切分(Fixed-Size Chunking) 策略的核心思想是將長(zhǎng)文本內(nèi)容按照預(yù)設(shè)的、統(tǒng)一的長(zhǎng)度單位進(jìn)行機(jī)械式分割。這種長(zhǎng)度單位可以是詞語(yǔ)數(shù)量 (word count)、字符數(shù)量 (character count),或者是模型輸入的 Token 數(shù)量 (token count)。

例如,我們可以將一篇冗長(zhǎng)的文檔,每隔 200 個(gè)詞語(yǔ)或 512 個(gè) Token 就切分成一個(gè)獨(dú)立的文本塊。這種方法完全依賴(lài)于直接且程式化的文本分割邏輯,不涉及復(fù)雜的語(yǔ)義分析或語(yǔ)言學(xué)判斷,尤其適用于當(dāng)下游模型或系統(tǒng)對(duì)輸入數(shù)據(jù)有嚴(yán)格固定尺寸要求的場(chǎng)景,例如需要批量處理或作為固定維度輸入到某些機(jī)器學(xué)習(xí)模型中。

2. Fixed-Size Chunking 策略有哪些優(yōu)劣勢(shì) ?

在實(shí)際的業(yè)務(wù)場(chǎng)景中,基于固定大小切分(Fixed-Size Chunking) 策略具有較高的優(yōu)勢(shì),具體體現(xiàn)在如下 2 點(diǎn):

(1) 實(shí)現(xiàn)簡(jiǎn)易性與處理高效性 (Simplicity and Speed)

固定大小切分策略的實(shí)現(xiàn)邏輯極為直觀(guān)和簡(jiǎn)單,無(wú)需復(fù)雜的語(yǔ)言學(xué)分析、深度學(xué)習(xí)模型支持或高級(jí)算法支持。這使得它在開(kāi)發(fā)和部署階段資源消耗極低,能夠以非常高的速度完成大規(guī)模文本的分塊任務(wù),是快速構(gòu)建 RAG 原型或處理海量非結(jié)構(gòu)化數(shù)據(jù)的首選策略。

(2) 高可預(yù)測(cè)性與數(shù)據(jù)統(tǒng)一性 (Predictability and Uniformity)

此外,該策略能夠產(chǎn)生尺寸統(tǒng)一、格式一致的文本塊。這種高度的可預(yù)測(cè)性極大地簡(jiǎn)化了數(shù)據(jù)在后續(xù) RAG 流程中的存儲(chǔ)、索引和檢索過(guò)程。例如,在向量數(shù)據(jù)庫(kù)中,所有文本塊的維度和存儲(chǔ)空間都是可預(yù)期的,這有利于數(shù)據(jù)庫(kù)性能優(yōu)化、資源管理和系統(tǒng)調(diào)試。

雖然,基于固定大小切分(Fixed-Size Chunking) 策略是在實(shí)際的場(chǎng)景中具有較為廣泛的應(yīng)用場(chǎng)景,但隨著業(yè)務(wù)的復(fù)雜性,其面臨著如下問(wèn)題:

1 個(gè)是上下文碎片化 (Context Fragmentation),即 由于切分是機(jī)械性的,它常常會(huì)在句子中間、段落連接處,甚至是重要的邏輯單元(如列表項(xiàng)、關(guān)鍵定義)內(nèi)部進(jìn)行強(qiáng)制分割。這種語(yǔ)義割裂會(huì)嚴(yán)重破壞文本的自然語(yǔ)義流和上下文連貫性。

檢索時(shí),大模型可能因此獲得不完整或斷裂的語(yǔ)境信息,從而導(dǎo)致理解偏差,影響回答的準(zhǔn)確性,甚至產(chǎn)生“幻覺(jué)”。這也是固定大小切分最顯著的缺點(diǎn)。

第 2 個(gè)問(wèn)題便是缺乏適應(yīng)性與僵硬性 (Rigidity and Lack of Adaptability)。由于此方法無(wú)法根據(jù)文本本身的邏輯結(jié)構(gòu)、語(yǔ)義邊界、主題變化或文檔的復(fù)雜程度進(jìn)行自適應(yīng)調(diào)整。

重要的相關(guān)概念或信息可能會(huì)被不必要地分割到不同的塊中,或者不相關(guān)的上下文被強(qiáng)制捆綁在一起。這種僵硬性使得它在處理結(jié)構(gòu)復(fù)雜、語(yǔ)義關(guān)聯(lián)緊密或包含多主題的文檔時(shí),檢索和生成效果往往差強(qiáng)人意。

3. Fixed-Size Chunking 策略簡(jiǎn)單實(shí)現(xiàn)示例解析

接下來(lái),我們來(lái)看一個(gè)簡(jiǎn)單的示例,基于 Python 代碼實(shí)現(xiàn)如何將文本按固定詞數(shù)進(jìn)行切分。具體如下所示:

def fixed_size_chunk(text: str, chunk_size: int = 50) -> list[str]:
    """
    將文本按固定詞數(shù)進(jìn)行切分。
    Args:
        text (str): 待切分的原始文本字符串。
        chunk_size (int): 每個(gè)文本塊所包含的詞語(yǔ)數(shù)量。
                          默認(rèn)為 50 個(gè)詞。
    Returns:
        list[str]: 包含切分后文本塊的字符串列表。
    """
    words = text.split() 
    chunks = [" ".join(words[i:i+chunk_size]) for i in range(0, len(words), chunk_size)]
    return chunks
# --- 示例用法 ---
# 假設(shè) pdf_text_example 是從 PDF 文檔中提取出的一個(gè)長(zhǎng)文本內(nèi)容
# 為了演示,我將使用一個(gè)足夠長(zhǎng)的示例文本,但您可以替換為您的實(shí)際文本
pdf_text_example = """
在人工智能領(lǐng)域,檢索增強(qiáng)生成(RAG)技術(shù)已經(jīng)成為構(gòu)建實(shí)用、知識(shí)驅(qū)動(dòng)的大型語(yǔ)言模型(LLM)應(yīng)用的核心范式。它有效地彌合了模型靜態(tài)知識(shí)與動(dòng)態(tài)外部信息之間的鴻溝,讓 LLM 能夠引用實(shí)時(shí)或領(lǐng)域特定的數(shù)據(jù),極大地提高了回復(fù)的準(zhǔn)確性和可靠性。然而,當(dāng)我們邁向更復(fù)雜的 AI 應(yīng)用時(shí),僅僅依賴(lài)向量相似性搜索,在處理那些相互關(guān)聯(lián)、關(guān)系至關(guān)重要的數(shù)據(jù)時(shí)常常顯得力不從心。構(gòu)建真正智能的代理或提供高度準(zhǔn)確、理解上下文深度的回答,需要理解信息之間的‘聯(lián)系’,而不僅僅是‘相似’。這正是對(duì)下一代 RAG 應(yīng)用的需求所在。支撐這些高級(jí)能力的數(shù)據(jù)庫(kù),必須能夠同時(shí)處理向量相似性和復(fù)雜的結(jié)構(gòu)化關(guān)系。HelixDB 應(yīng)運(yùn)而生,正是為了應(yīng)對(duì)這一挑戰(zhàn)。它打破了傳統(tǒng)數(shù)據(jù)庫(kù)的界限,是一個(gè)革命性的開(kāi)源圖向量數(shù)據(jù)庫(kù),巧妙融合了圖數(shù)據(jù)庫(kù)強(qiáng)大的關(guān)系表達(dá)能力與向量數(shù)據(jù)庫(kù)高效的相似性搜索能力。HelixDB 旨在為下一代 RAG 應(yīng)用提供一個(gè)更智能、更靈活的數(shù)據(jù)存儲(chǔ)基礎(chǔ),讓你能夠基于內(nèi)容相似性和結(jié)構(gòu)化關(guān)系進(jìn)行更豐富的上下文檢索。如果你正在探索 RAG 的未來(lái),并尋求能夠同時(shí)處理向量和復(fù)雜關(guān)系的強(qiáng)大開(kāi)源數(shù)據(jù)解決方案,那么理解 HelixDB 至關(guān)重要。通過(guò)本文,你將一文讀懂這款為下一代 RAG 應(yīng)用量身打造的開(kāi)源圖向量數(shù)據(jù)庫(kù)的核心理念、架構(gòu)優(yōu)勢(shì)以及它如何助力你的智能化創(chuàng)新。讓我們一起深入了解 HelixDB 的獨(dú)特之處吧!這是一個(gè)額外的句子,確保文本足夠長(zhǎng),可以被切分成多個(gè)塊,以演示第二個(gè)塊的打印。
"""
# 將文本按每50個(gè)詞語(yǔ)切分成塊
chunks_result = fixed_size_chunk(pdf_text_example, chunk_size=10)
print(f"原始文本被切分成了 {len(chunks_result)} 個(gè)塊。")
# --- 解決方案在這里:添加安全檢查 ---
# 嘗試打印第一個(gè)塊
if len(chunks_result) > 0:
    print("\n--- 第一個(gè)塊內(nèi)容示例 ---")
    print(chunks_result[0])
else:
    print("\n--- 列表為空,無(wú)法打印第一個(gè)塊 ---")
# 嘗試打印第二個(gè)塊,先檢查列表長(zhǎng)度是否至少有2個(gè)元素
if len(chunks_result) > 1:
    print("\n--- 第二個(gè)塊內(nèi)容示例 ---")
    print(chunks_result[1])
else:
    print("\n--- 無(wú)法打印第二個(gè)塊,因?yàn)榱斜黹L(zhǎng)度不足(少于2個(gè)塊) ---")
# 如果您想打印所有生成的塊,可以使用循環(huán):
# print("\n--- 所有生成的文本塊 ---")
# for i, chunk in enumerate(chunks_result):
#     print(f"塊 {i}:")
#     print(chunk)
#     print("-" * 20)

上述這段代碼實(shí)現(xiàn)了一個(gè)固定大小分塊(Fixed-Size Chunking)的功能,用于將長(zhǎng)文本按指定詞數(shù)分割成多個(gè)塊,適用于 RAG(Retrieval-Augmented Generation)系統(tǒng)中文檔預(yù)處理。

執(zhí)行運(yùn)行:

[(base) lugalee@labs rag ]% /opt/homebrew/bin/python3 /Volumes/home/rag/fixedsiz.py
原始文本被切分成了 2 個(gè)塊。


--- 第一個(gè)塊內(nèi)容示例 ---
在人工智能領(lǐng)域,檢索增強(qiáng)生成(RAG)技術(shù)已經(jīng)成為構(gòu)建實(shí)用、知識(shí)驅(qū)動(dòng)的大型語(yǔ)言模型(LLM)應(yīng)用的核心范式。它有效地彌合了模型靜態(tài)知識(shí)與動(dòng)態(tài)外部信息之間的鴻溝,讓 LLM 能夠引用實(shí)時(shí)或領(lǐng)域特定的數(shù)據(jù),極大地提高了回復(fù)的準(zhǔn)確性和可靠性。然而,當(dāng)我們邁向更復(fù)雜的 AI 應(yīng)用時(shí),僅僅依賴(lài)向量相似性搜索,在處理那些相互關(guān)聯(lián)、關(guān)系至關(guān)重要的數(shù)據(jù)時(shí)常常顯得力不從心。構(gòu)建真正智能的代理或提供高度準(zhǔn)確、理解上下文深度的回答,需要理解信息之間的‘聯(lián)系’,而不僅僅是‘相似’。這正是對(duì)下一代 RAG 應(yīng)用的需求所在。支撐這些高級(jí)能力的數(shù)據(jù)庫(kù),必須能夠同時(shí)處理向量相似性和復(fù)雜的結(jié)構(gòu)化關(guān)系。HelixDB 應(yīng)運(yùn)而生,正是為了應(yīng)對(duì)這一挑戰(zhàn)。它打破了傳統(tǒng)數(shù)據(jù)庫(kù)的界限,是一個(gè)革命性的開(kāi)源圖向量數(shù)據(jù)庫(kù),巧妙融合了圖數(shù)據(jù)庫(kù)強(qiáng)大的關(guān)系表達(dá)能力與向量數(shù)據(jù)庫(kù)高效的相似性搜索能力。HelixDB 旨在為下一代 RAG


--- 第二個(gè)塊內(nèi)容示例 ---
應(yīng)用提供一個(gè)更智能、更靈活的數(shù)據(jù)存儲(chǔ)基礎(chǔ),讓你能夠基于內(nèi)容相似性和結(jié)構(gòu)化關(guān)系進(jìn)行更豐富的上下文檢索。如果你正在探索 RAG 的未來(lái),并尋求能夠同時(shí)處理向量和復(fù)雜關(guān)系的強(qiáng)大開(kāi)源數(shù)據(jù)解決方案,那么理解 HelixDB 至關(guān)重要。通過(guò)本文,你將一文讀懂這款為下一代 RAG 應(yīng)用量身打造的開(kāi)源圖向量數(shù)據(jù)庫(kù)的核心理念、架構(gòu)優(yōu)勢(shì)以及它如何助力你的智能化創(chuàng)新。讓我們一起深入了解 HelixDB 的獨(dú)特之處吧!

Happy Coding ~

Reference :[1] https://www.koyeb.com/blog/what-is-rag-retrieval-augmented-generation-for-ai

Adiós !

責(zé)任編輯:趙寧寧 來(lái)源: 架構(gòu)驛站
相關(guān)推薦

2025-05-27 08:35:00

2025-06-11 08:40:00

LangChainRAG人工智能

2025-05-20 11:55:22

人工智能Vision RAGLLM

2024-06-24 14:32:33

2025-04-10 00:12:00

2024-01-03 08:54:17

Kubernetes策略工具

2024-05-28 11:32:01

2023-11-21 09:41:00

緩存策略存儲(chǔ)

2024-07-08 12:44:11

2024-06-24 08:05:00

人工智能AI

2025-03-04 09:10:00

RAG大模型AI

2022-05-12 08:01:18

KubernetesDocker容器

2025-03-14 10:22:26

2022-03-21 17:30:04

JetpackGoogle開(kāi)發(fā)者

2023-12-22 19:59:15

2021-08-04 16:06:45

DataOps智領(lǐng)云

2022-09-22 09:00:46

CSS單位

2025-04-03 10:56:47

2018-09-28 14:06:25

前端緩存后端

2022-11-06 21:14:02

數(shù)據(jù)驅(qū)動(dòng)架構(gòu)數(shù)據(jù)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)