告別碎片化!兩大先進分塊技術如何提升RAG的語義連貫性?

研究動機

論文核心問題及研究背景分析

1. 研究領域及其重要性
  • 研究領域:檢索增強生成(Retrieval-Augmented Generation, RAG)系統,結合自然語言處理(NLP)與信息檢索技術。
  • 重要性
    • RAG通過動態整合外部知識,解決了傳統大語言模型(LLMs)依賴靜態預訓練數據的局限性。
    • 在開放域問答、實時信息生成等場景中,RAG能顯著提升生成內容的準確性和信息完整性。
    • 對知識密集型任務(如醫療問答、法律分析)至關重要,需高效管理大規模外部文檔。
2. 當前領域面臨的挑戰或痛點
挑戰具體表現影響
輸入長度限制LLMs的上下文窗口有限(通常數千token),難以處理長文檔需分塊處理,但分塊可能破壞語義連貫性
上下文碎片化固定分塊策略忽略語義邊界,導致信息割裂檢索不完整,生成結果缺乏連貫性
位置偏差LLMs對文檔開頭信息更敏感,中間/尾部信息易被忽略關鍵信息可能未被有效檢索或利用
效率與效果權衡傳統分塊效率高但犧牲語義;高級方法(如上下文增強)計算成本高實際應用中需平衡資源消耗與性能
3. 論文關注的具體問題及研究意義

具體問題

  1. 兩種分塊策略的對比

    • Late Chunking(延遲分塊):先對整個文檔嵌入,再分塊聚合,保留全局上下文。
    • Contextual Retrieval(上下文增強檢索):分塊后附加LLM生成的上下文,提升語義連貫性。
  2. 關鍵研究問題(RQs)

    • RQ#1:早期分塊 vs. 延遲分塊對檢索和生成性能的影響。
    • RQ#2:傳統分塊 vs. 上下文增強分塊的效果差異。

研究意義

  • 理論意義

    • 揭示兩種分塊策略在上下文保留與效率上的權衡關系。
    • 提出動態分塊模型(如Topic-Qwen)和混合排名策略(BM25 + 稠密嵌入),為優化RAG系統提供新思路。
  • 應用價值

    • 資源受限場景:優先選擇延遲分塊(效率高,但需適配長上下文嵌入模型)。
    • 高精度需求場景:采用上下文增強檢索(犧牲計算資源換取語義連貫性)。
    • 開源代碼與數據集(NFCorpus、MSMarco)支持實際部署與復現。

相關研究工作

以下是針對檢索增強生成(RAG)中分塊策略研究的歸納總結:

主要已有方法或技術路線

方法名稱核心思想技術特點
固定尺寸分塊將文檔均等分割為固定長度的文本塊簡單高效,但忽略語義邊界
語義分塊根據語義邊界(如段落、主題)動態分割文本基于語義模型檢測斷點,保留局部上下文
延遲分塊先對整個文檔進行詞元級嵌入,再分割為塊并聚合利用長上下文嵌入模型保留全局信息
上下文檢索分塊后通過LLM生成全局上下文并預置到每個塊中,再結合混合檢索(BM25+嵌入)增強局部塊的語義連貫性,但需額外生成上下文

方法對比與優缺點分析

方法優點缺點
固定尺寸分塊實現簡單、計算高效;兼容性強破壞上下文連貫性;可能導致關鍵信息分割
語義分塊保留局部語義結構;減少信息碎片化依賴語義模型;計算成本較高;動態分割不穩定
延遲分塊保留全局上下文;適配長文本嵌入模型嵌入模型性能影響顯著;長文檔處理效率低;部分模型(如BGE-M3)表現下降
上下文檢索語義連貫性最佳(NDCG@5提升5%);支持混合檢索提升召回率計算資源需求高(需LLM生成上下文);長文檔內存占用大

現有研究的不足與未解決問題

  1. 效率與效果的權衡

    • 延遲分塊和上下文檢索雖提升效果,但計算成本顯著增加(如上下文檢索需要20GB VRAM處理長文檔)。
    • 動態分塊模型(如Topic-Qwen)耗時是固定分塊的4倍,且生成結果不穩定。
  2. 長文檔處理瓶頸

    • 現有方法(尤其是上下文檢索)對長文檔的支持有限,GPU內存限制導致實驗僅使用20%數據集。
  3. 模型依賴性

    • 延遲分塊效果高度依賴嵌入模型(例如Jina-V3表現優于BGE-M3),缺乏普適性結論。
  4. 生成性能未顯著提升

    • 實驗顯示分塊策略對最終生成質量(問答任務)影響有限,需更深入的端到端優化。
  5. 統一評估框架缺失

    • 不同方法在數據集、評測指標上差異大(如NFCorpus與MSMarco),橫向對比困難。

可以看出, 當前RAG分塊策略的研究聚焦于平衡上下文保留與計算效率。傳統方法(固定分塊、語義分塊)在簡單場景中仍具優勢,而延遲分塊和上下文檢索在復雜語義任務中表現更優但代價高昂。未來需探索輕量化上下文增強、長文檔優化技術,并建立統一評估標準以推動實際應用。

研究思路來源

作者的研究思路主要受到以下前人工作的啟發:

  • 經典RAG框架:基于Lewis等人(2020)提出的RAG基礎架構,結合檢索機制與生成模型,但在處理長文檔時面臨輸入限制和上下文碎片化問題。
  • 固定分塊與語義分塊:傳統方法如固定窗口分塊(如[7])和語義分塊(如Jina-Segmenter API),但無法解決全局上下文丟失問題。
  • 動態分塊技術:如監督分割模型(Koshorek et al., 2018)和端到端優化分塊(Moro & Ragazzi, 2023),但計算成本高且依賴標注數據。
  • 長上下文嵌入模型:如Ding等人(2024)提出的LongRoPE,但實際應用中仍存在位置偏差(Hsieh et al., 2024)。

作者提出新方法的動機源于以下核心觀察與假設:

  • 傳統分塊的局限性
    • 上下文割裂:固定分塊破壞文檔的語義連貫性,導致檢索不完整(例如,一個分塊可能缺少公司名稱或時間信息)。
    • 位置偏差:LLM對文檔開頭信息更敏感,而中間或尾部信息易被忽略(Lu et al., 2024)。
    • 效率與效果的權衡:動態分塊模型(如Topic-Qwen)雖提升效果,但生成不一致且計算成本高。
  • 假設
    • 延遲分塊保留全局上下文:在文檔級嵌入后再分塊(Late Chunking)可減少局部語義損失。
    • 上下文增強提升檢索質量:通過LLM生成附加上下文(Contextual Retrieval)可彌補分塊的語義不完整。
3. 主要創新點與差異化對比

論文的核心創新點及與現有工作的對比:

創新點技術細節與現有工作的差異化效果對比
Late Chunking(延遲分塊)先對整個文檔進行嵌入,再分塊并聚合向量。區別于傳統“先分塊后嵌入”,避免分塊前的上下文丟失。優勢
- 保留全局語義(如文檔主題一致性);
- 計算效率高(無需LLM生成額外內容)。
劣勢
- 對長文檔嵌入模型依賴性強(如BGE-M3效果差);
- 部分場景下相關性下降(表3中MsMarco數據集表現弱于早期分塊)。
Contextual Retrieval(上下文檢索)分塊后通過LLM生成上下文摘要(如Phi-3模型),并與BM25稀疏向量融合排序。結合語義(密集向量)與精確匹配(稀疏向量),優于單一檢索策略。優勢
- 提升檢索完整性(NDCG@5提高5.3%,表5);
- 緩解位置偏差(通過上下文補充關鍵信息)。
劣勢
- 計算成本高(GPU內存占用達20GB);
- 依賴LLM生成質量(小模型如Phi-3可能表現不穩定)。
動態分塊模型優化測試Simple-Qwen和Topic-Qwen分塊模型,結合主題邊界檢測。超越傳統固定或語義分塊,但需權衡生成穩定性與計算效率。優勢
- 自適應內容分塊(如按主題劃分);
- 提升下游任務性能(Jina-V3模型NDCG@5達0.384)。
劣勢
- 生成不一致性(分塊邊界波動);
- 處理時間增加(Topic-Qwen耗時4倍于固定分塊)。

解決方案細節

論文針對傳統RAG(檢索增強生成)系統中固定分塊(fixed-size chunking)導致的上下文碎片化問題,提出了兩種改進策略:

  1. 延遲分塊(Late Chunking)

    • 核心思想:推遲分塊過程,先對整個文檔進行嵌入(embedding),保留全局上下文,再分割為塊。
    • 原理:通過長上下文嵌入模型直接處理完整文檔,避免早期分塊造成的語義割裂。
  2. 上下文檢索(Contextual Retrieval)

    • 核心思想:在分塊后,通過大語言模型(LLM)為每個塊動態生成補充上下文。
    • 原理:利用LLM提取文檔的全局語義信息,附加到分塊中,增強單一塊的語義連貫性。

方法的主要組成模塊及功能

1. 延遲分塊(Late Chunking)流程
完整文檔 → Token級嵌入 → 分塊 → 池化 → 塊嵌入
  • 模塊功能

    • Token級嵌入:使用長上下文嵌入模型(如Stella-V5)對完整文檔生成細粒度嵌入。
    • 動態分塊:根據語義邊界或固定窗口分割嵌入結果。
    • 池化(Pooling):對每個塊的Token嵌入取均值,生成塊級嵌入。

Jina有篇文章,更詳細的解釋了Late Chunking,文章鏈接如下;

長文本表征模型中的后期分塊

https://jina.ai/news/late-chunking-in-long-context-embedding-models/

"Late Chunking"方法首先將嵌入模型的 transformer 層應用于整個文本或盡可能多的文本。這會為每個 token 生成一個包含整個文本信息的向量表示序列。隨后,對這個 token 向量序列的每個塊應用平均池化,生成考慮了整個文本上下文的每個塊的嵌入。與生成獨立同分布(i.i.d.)塊嵌入的樸素編碼方法不同,Late Chunking 創建了一組塊嵌入,其中每個嵌入都"以"前面的嵌入為條件,從而為每個塊編碼更多的上下文信息。

傳統分塊策略(左)和 Late Chunking 策略(右)的示意圖。

2. 上下文增強切塊(Contextual Retrieval)流程
分塊 → LLM生成上下文 → 塊+上下文嵌入 → 混合檢索(BM25+密集檢索) → 重排序
  • 模塊功能

    • 上下文生成:用LLM為每個塊生成補充信息(如所屬章節、主題)。
    • 混合檢索:結合BM25的精確匹配和密集嵌入的語義匹配(權重4:1)。
    • 重排序:使用交叉編碼器(cross-encoder)對檢索結果重新評分。

關鍵技術細節

1. 延遲分塊的關鍵改進
  • 長上下文嵌入模型:支持處理超長文檔(如Stella-V5支持131k Token)。

  • 動態分塊策略

    • Simple-Qwen:基于文檔結構(如標題、段落)分塊。
    • Topic-Qwen:基于主題邊界分塊(通過LLM識別主題切換點)。
2. 上下文檢索的關鍵技術
  • 上下文生成提示模板

    "基于以下文檔,為當前塊生成上下文摘要:[文檔內容] [當前塊]"
    
  • 混合檢索的權重分配

    嵌入類型權重
    密集嵌入1.0
    BM25稀疏嵌入0.25
  • 重排序模型:Jina Reranker V2(交叉編碼器架構,計算查詢與塊的相關性得分)。

3. 動態分塊模型的權衡
分塊策略優點缺點
固定窗口分塊計算效率高忽略語義邊界
語義分塊(Jina)保留語義連貫性依賴外部API,速度較慢
動態分塊(Qwen)自適應文檔結構/主題生成不穩定,計算成本高

實驗與性能對比

1. 檢索性能(NFCorpus數據集)
方法NDCG@5MAP@5F1@5
傳統分塊(Early)0.3030.1370.193
延遲分塊(Late)0.3800.1030.185
上下文檢索(RFR)0.3170.1460.206
2. 計算資源消耗
方法VRAM占用處理時間(NFCorpus)
傳統分塊5-10GB30分鐘
延遲分塊10-15GB60分鐘
上下文檢索20GB+120分鐘+
  • 延遲分塊:適合資源受限場景,但可能犧牲相關性。
  • 上下文檢索:適合對語義連貫性要求高的任務,但需高算力支持。
  • 實際應用:短文檔優先選擇上下文檢索,長文檔可嘗試延遲分塊與動態分塊結合。

論文通過系統實驗驗證了兩種方法的互補性,為RAG系統的分塊策略選擇提供了明確指導。

實驗設計與結果分析

1. 實驗目的與驗證假設
  • 目的:比較兩種高級分塊策略(Late Chunking 和 Contextual Retrieval)在 RAG 系統中的效果,驗證它們在 檢索準確性生成連貫性計算效率 上的優劣。

  • 核心假設

    1. Late Chunking 通過延遲分塊保留全局上下文,可能提升檢索效果。
    2. Contextual Retrieval 通過 LLM 生成上下文增強分塊語義,可能改善生成質量,但需更高計算資源。
2. 數據集與任務設置
數據集任務特點
NFCorpus檢索性能評估長文檔(平均長度長),需處理上下文碎片化問題;子集實驗(20%數據)用于降低計算開銷。
MSMarco問答生成評估短文本段落,缺乏完整文檔上下文,用于測試生成任務中信息整合能力。

任務設置

  • 檢索任務:從文檔庫中檢索與查詢相關的文檔/段落。
  • 生成任務:基于檢索結果生成答案,評估語義連貫性和準確性。
3. 評估指標
指標含義
NDCG@k歸一化折損累積增益,衡量前 k 個結果的排序質量,重視高相關性結果的排名。
MAP@k平均精度均值,衡量所有查詢的檢索精度均值,關注相關結果的位置分布。
F1@k精確率與召回率的調和平均,平衡檢索結果中相關性與完整性的權衡。
4. 基線方法與對比實驗設置
方法類型方法細節特點
傳統 RAG早期分塊(固定窗口或語義分塊) + 嵌入模型(如 Jina-V3、BGE-M3)。分塊后嵌入,可能丟失全局上下文。
Late Chunking先嵌入完整文檔,再分塊并池化(mean pooling)生成分塊嵌入。保留全局上下文,計算效率較高。
Contextual Retrieval分塊后通過 LLM 生成上下文(如 Phi-3.5-mini),結合 Rank Fusion(BM25 + 密集嵌入)增強語義連貫性,但需額外生成步驟和 GPU 資源。

對比實驗設置

實驗組分塊策略嵌入模型數據集關鍵參數
RQ#1Early vs LateStella-V5, Jina-V3NFCorpus, MSMarco分塊大小 512 字符,動態分塊模型
RQ#2Contextual vs 傳統Jina-V3, BGE-M3NFCorpus 子集Rank Fusion 權重(4:1)
5. 實驗環境
組件配置/參數
硬件NVIDIA RTX 4090(24GB VRAM),受限于顯存,部分實驗使用數據子集。
生成模型Phi-3.5-mini-instruct(4-bit 量化),用于生成上下文和問答任務。
嵌入模型Jina-V3(MTEB 排名 53)、Stella-V5(排名 5)、BGE-M3(排名 211)等。
分塊工具Jina-Segmenter(語義分塊)、Simple-Qwen(動態分塊)、Topic-Qwen(主題分塊)。
檢索庫與工具Milvus 向量數據庫(支持 BM25 與密集嵌入混合檢索),Jina Reranker V2(重排序)。

驗證嚴謹性體現

  1. 控制變量:統一使用相同嵌入模型(如 Jina-V3)對比不同分塊策略。
  2. 數據集適配:針對文檔長度調整實驗規模(如 NFCorpus 子集解決顯存限制)。
  3. 多指標評估:結合檢索(NDCG、MAP)和生成(F1)指標,全面衡量性能。
  4. 計算效率分析:記錄處理時間與顯存占用(如 Contextual Retrieval 顯存達 20GB)。
  5. 統計顯著性:多次實驗取均值,結果表格中標注最優值(Bold 顯示)。

論文通過系統化的實驗設計,驗證了兩種分塊策略在不同場景下的權衡:Late Chunking 效率更優,Contextual Retrieval 語義更佳,為實際 RAG 系統優化提供了重要參考。

6. 關鍵實驗結果
評估指標上下文檢索 (ContextualRankFusion)延遲分塊 (Late Chunking)早期分塊 (Early Chunking)
NDCG@50.3170.3090.312 (最佳嵌入模型)
MAP@50.1460.1430.144 (最佳嵌入模型)
F1@50.2060.2020.204 (最佳嵌入模型)
計算資源消耗高(需LLM生成上下文 + 重排序)
適用場景長文檔、高語義連貫性需求資源受限、效率優先固定長度、簡單任務
  • 嵌入模型對比
    • Jina-V3 在上下文檢索中表現最佳(NDCG@5=0.317)。
    • BGE-M3 在早期分塊中優于延遲分塊(NDCG@5=0.246 vs. 0.070)。
    • 動態分塊模型(如Topic-Qwen)在語義分割中提升效果,但計算耗時增加4倍。

論文結論

核心結論
  1. 無單一最優策略

    • 上下文檢索在語義連貫性上占優(NDCG@5提升2.5%),但資源消耗高;延遲分塊效率優先,犧牲局部相關性。
  2. 關鍵權衡維度

    • 任務需求:長文檔、高準確性場景傾向上下文檢索;實時性任務傾向延遲分塊。
    • 嵌入模型適配:模型特性(如長上下文支持)顯著影響分塊策略效果。
科學意義
  • 實踐指導:為RAG系統設計提供量化權衡框架(如資源-效果平衡表),助力開發者按場景優化。
  • 理論創新:驗證了全局上下文保留(延遲分塊)與局部語義增強(上下文檢索)的互補性,為后續混合策略(如動態切換)提供基礎。
  • 開源價值:釋放代碼與數據集(MIT協議),推動社區在真實場景中復現與擴展(如優化LLM上下文生成效率)。
對應研究目標
  • RQ#1(分塊時機):延遲分塊驗證了全局嵌入的高效性,但需結合模型特性(如BGE-M3不適用)。
  • RQ#2(上下文增強):上下文檢索通過LLM生成與重排序提升語義質量,但需硬件支持。
  • 核心目標達成:系統性對比兩種策略,揭示了其在RAG系統中的互補性與場景適配邊界。

代碼實現

延遲切塊

class BgeEmbedder():def __init__(self):self.model_id = 'BAAI/bge-m3'self.model = AutoModel.from_pretrained(self.model_id, trust_remote_code=True).cuda();self.tokenizer = AutoTokenizer.from_pretrained(self.model_id);self.model.eval()def get_model(self):return self.modeldef encode(self, chunks, task, max_length=512):if type( chunks) == str:chunks = [chunks]chunks_embeddings = []for chunk in chunks:tokens = self.tokenizer(chunk, return_tensors='pt')['input_ids'].to("cuda")with torch.no_grad():token_embeddings = self.model(input_ids=tokens)[0]pooled_embeddings = token_embeddings.sum(dim=1) / len(token_embeddings)pooled_embeddings = F.normalize(pooled_embeddings, p=2, dim=1).squeeze(0)chunks_embeddings.append(pooled_embeddings.to(dtype=torch.float32).detach().cpu().numpy())if task == 'retrieval.query':return chunks_embeddingselse:return [chunks_embeddings]# def encode(self, chunks, task, max_length=512):#   if type( chunks) == str:#     chunks = [chunks]#   chunks_embeddings = []#   for chunk in chunks:#     tokens = self.tokenizer(chunk, return_tensors='pt')['input_ids'].to("cuda")#     with torch.no_grad():#       token_embeddings = self.model(input_ids=tokens)[0]#       div = token_embeddings.size(1)#       pooled_embeddings = token_embeddings.sum(dim=1) / div#       pooled_embeddings = F.normalize(pooled_embeddings, p=2, dim=1).squeeze(0)#     chunks_embeddings.append(pooled_embeddings.to(dtype=torch.float32).detach().cpu().numpy())#   if task == 'retrieval.query':#     return chunks_embeddings#   else:#     return [chunks_embeddings]def encodeLateChunking(self, text_token, span_annotation, task, max_length = None ):with torch.no_grad():token_embeddings = self.model(input_ids=text_token)[0]outputs = []for embeddings, annotations in zip(token_embeddings, span_annotation):if (max_length is not None):  # remove annotations which go bejond the max-length of the modelannotations   = [(start, min(end, max_length - 1))for (start, end) in annotationsif start < (max_length - 1)]pooled_embeddings = [embeddings[start:end].sum(dim=0) / (end - start)for (start, end) in annotationsif (end - start) >= 1]pooled_embeddings = [F.normalize(pooled_embedding.unsqueeze(-1), p=2, dim=0).squeeze(-1)for  pooled_embedding in pooled_embeddings]pooled_embeddings = [embedding.to(dtype=torch.float32).detach().cpu().numpy()for embedding in pooled_embeddings]outputs.append(pooled_embeddings)return outputs

上下文增強切塊

class ChunkContextualizer():"""This class is used to contextualize the chunks of text.It gives to the model the document and the chunk of text to generate the context to be added to the chunk.The model is a language model that generates the context."""def __init__(self, corpus, prompt, examples, llm_id, segmenter,load_in_4bit = True): #model_templateself.corpus = corpusself.prompt = promptself.examples = examplesself.segmenter = segmenter#self.model_template = model_template#self.chat_template = (model_template,"<|end|>")self.llm_id = llm_idself.load_in_4bit = load_in_4bitdtype = Noneself.llm_model, self.llm_tokenizer = FastLanguageModel.from_pretrained(model_name = model_id,dtype = dtype,load_in_4bit = load_in_4bit,)self.llm_tokenizer = get_chat_template(self.llm_tokenizer,chat_template = 'phi-3.5',#self.chat_template,            # apply phi-3.5 chat templatemapping = {"role" : "from", "content" : "value", "user" : "human", "assistant" : "gpt"},)FastLanguageModel.for_inference(self.llm_model);self.generation_config =  GenerationConfig(eos_token_id=self.llm_tokenizer.convert_tokens_to_ids("<|end|>"))def get_llm(self):return self.llm_modeldef get_formatted_prompt(self,doc,chunk):ex = '\n'.join([f'CHUNK: {chunk}\nCONTEXT: {context}' for (chunk, context) in self.examples]) # format examples with chunk and contextreturn self.prompt.format(doc_content=doc, chunk_content=chunk, examples=ex)                  # format prompt with chunk, document and examplesdef extract_llm_responses(self, conversation: str):                                             # extract assistant responses from the conversation# Regex to match assistant output between <|assistant|> and <|end|>assistant_responses = re.findall(r"<\|assistant\|>(.*?)<\|end\|>", conversation, re.DOTALL)return assistant_responsesdef contextualize(self, chunking_size):ids,texts = zip(*[ (key, value['text']) for (key,value) in self.corpus.items() ])ids,texts = list(ids), list(texts)chunks_ids,contextualized_chunks=[],[]pbar = tqdm(total=len(texts), desc="Contextualizing Chunks", mininterval=60.0)for i in range(len(texts)):chunks = self.segmenter.segment(input_text=texts[i],max_chunk_length=chunking_size)         # segment text into chunks with passed segmenterfor j in range(len(chunks)):chunk = chunks[j]doc = texts[i]                                                        # getting document for all the chunksprompt = self.get_formatted_prompt(doc,chunk)                         # formatting prompt with current document and current chunkmessages=[{"from": "human", "value": prompt}]inputs = self.llm_tokenizer.apply_chat_template(                      # apply chat template to the prompt to get the inputmessages,tokenize=True,return_tensors="pt",padding=True,).to("cuda")output_ids = self.llm_model.generate(input_ids=inputs,do_sample=False,max_new_tokens=2000,generation_config=self.generation_config,)output = self.llm_tokenizer.batch_decode(output_ids)                  # decode the output to textgenerated_context = self.extract_llm_responses(output[0])             # extract context from output stringif generated_context:                                                 # only add non-empty entriescontextualized_chunks.append(chunk + '\n' + generated_context[0]) # append generated context to current chunkchunks_ids.append(f'{ids[i]}:{j}')pbar.update(1)return contextualized_chunks, chunks_ids

其中提示語為:

contextual_retrieval_prompt = """
DOCUMENT:
{doc_content}Here is the chunk we want to situate within the whole document
CHUNK:
{chunk_content}Provide a concise context for the following chunk, focusing on its relevance within the overall document for the purposes of improving search retrieval of the chunk.
Answer only with the generated context and nothing else.
Output your answer after the phrase "The document provides an overview".
Think step by step.Here there is an example you can look at.
EXAMPLE:
{examples}"""

這個提示語(prompt)是一個用于 上下文檢索(contextual retrieval) 的模板,目的是幫助大語言模型(LLM)為給定的文本片段(chunk)生成一個簡潔的上下文描述,從而提升檢索效果。以下是它的詳細解析:

參考資料

  • https://arxiv.org/pdf/2504.19754
  • https://github.com/disi-unibo-nlp/rag-when-how-chunk

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/bicheng/78923.shtml
繁體地址,請注明出處:http://hk.pswp.cn/bicheng/78923.shtml
英文地址,請注明出處:http://en.pswp.cn/bicheng/78923.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

leetcode day37 474

474 一和零 給你一個二進制字符串數組 strs 和兩個整數 m 和 n 。 請你找出并返回 strs 的最大子集的長度&#xff0c;該子集中 最多 有 m 個 0 和 n 個 1 。 如果 x 的所有元素也是 y 的元素&#xff0c;集合 x 是集合 y 的 子集 。 示例 1&#xff1a; 輸入&#xff1a;s…

二、信息時代社會結構的轉變

到了信息時代,以及在核武器的前提下,上述的社會結構的邏輯,就有了一個根 本性的轉變,就是暴力的成本和收益,都在下降。 暴力的成本在降低。比如說槍支,它的制造和分發都變得非常容易。現在我們都 知道有 3D 打印,它就好像工業時代的印刷機,印刷圣經或者書籍,使知識更加 普及和容…

Elasticsearch 堆內存使用情況和 JVM 垃圾回收

作者&#xff1a;來自 Elastic Kofi Bartlett 探索 Elasticsearch 堆內存使用情況和 JVM 垃圾回收&#xff0c;包括最佳實踐以及在堆內存使用過高或 JVM 性能不佳時的解決方法。 堆內存大小是分配給 Elasticsearch 節點中 Java 虛擬機的 RAM 數量。 從 7.11 版本開始&#xff…

C++之類和對象:構造函數,析構函數,拷貝構造,賦值運算符重載

前提&#xff1a;如果一個類是空類&#xff0c;C中空類中真的什么都沒有嗎&#xff0c;不是的&#xff0c;編譯器會自動生成6個默認成員函數。默認成員函數&#xff1a;用戶沒有顯式實現&#xff0c;編譯器會生成的成員函數稱為默認成員函數。 默認成員函數&#xff1a;構造函…

【專題五】位運算(1):常見位運算操作總結

&#x1f4dd;前言說明&#xff1a; 本專欄主要記錄本人的基礎算法學習以及LeetCode刷題記錄&#xff0c;按專題劃分每題主要記錄&#xff1a;&#xff08;1&#xff09;本人解法 本人屎山代碼&#xff1b;&#xff08;2&#xff09;優質解法 優質代碼&#xff1b;&#xff…

小草GrassRouter多卡聚合路由器聚合衛星、MESH網絡應用解決方案

一、多網融合解決方案 衛星網絡融合? 支持接入衛星通信模塊&#xff0c;在無地面網絡覆蓋的極端場景&#xff08;如偏遠山區、海洋救援&#xff09;下&#xff0c;形成“5G衛星”雙鏈路冗余傳輸&#xff0c;衛星鏈路可作為核心通信備份&#xff0c;確保關鍵指令和視頻數據實…

【Mybatis】Mybatis基礎

文章目錄 前言一、搭建MyBatis1.1 創建maven工程1.2 加入log4j日志功能1.3 MyBatis的增刪改查1.4 核心配置文件詳解 二、MyBatis獲取參數值的兩種方式2.1 單個字面量類型的參數2.2 多個字面量類型的參數2.3 map集合類型的參數2.4 實體類類型的參數2.5 使用Param標識參數 三、 M…

AI四大邊界

大模型訓練的邊界并非由單一因素決定&#xff0c;而是技術、倫理、法律及實際應用需求共同作用的結果。以下從四個維度解析其邊界來源&#xff1a; 一、技術邊界&#xff1a;資源與能力的雙重限制 計算資源瓶頸 成本與算力&#xff1a;大模型訓練依賴海量GPU/TPU資源&#xff…

Twitter 工作原理|架構解析|社交APP邏輯

這是對Twitter 工作原理&#xff5c;架構解析&#xff5c;社交APP邏輯_嗶哩嗶哩_bilibili的學習&#xff0c;感謝up小凡生一 在兩年半前&#xff0c;埃隆馬斯克收購了Twitter&#xff0c;并且進行了一系列重大改革。今天我們來解析一下這個全球知名社交平臺的架構。首先&#x…

Java基礎學習內容大綱

Java基礎學習內容大綱 第一階段:建立編程思想 ? Java概述:如何快速學習Java技術、Java歷史、Java特點、Sublime、Java運行機制、JDK、轉義字符、Java開發規范、Java API ? 變量:數據類型、變量基本使用、數據類型轉換 ? 運算符:運算符介紹、算數運算符、關系運算符、…

如何對多維樣本進行KS檢驗

對于形狀為 ( 10000 , 1 , 304 ) (10000, 1, 304) (10000,1,304)的三維數據&#xff0c;若需使用scipy.stats.ks_2samp進行KS檢驗&#xff0c;可按以下步驟處理&#xff1a; 數據降維 KS檢驗要求輸入為一維數組&#xff0c;需將三維數據展平或按特定維度聚合&#xff1a; ? 方…

在 VMware 虛擬機中安裝 Windows7

文章目錄 前言1.安裝VMware 虛擬機1. VMware虛擬機軟件安裝2. 虛擬機創建配置&#xff08;超詳細步驟&#xff09;3. Windows7系統安裝 3、安裝 VMware tools4. VMware Tools安裝與優化5. 總結與常見問題 前言 最近有不少朋友在問如何在電腦上同時使用多個操作系統&#xff0c…

直播預告|TinyVue 組件庫高級用法:定制你的企業級UI體系

TinyVue 是一個跨端跨框架的企業級 UI 組件庫&#xff0c;基于 renderless 無渲染組件設計架構&#xff0c;實現了一套代碼同時支持 Vue2 和 Vue3&#xff0c;支持 PC 和移動端&#xff0c;包含 100 多個功能豐富的精美組件&#xff0c;可幫助開發者高效開發 Web 應用。 4 月 …

分治而不割裂—分治協同式敏捷工作模式

分治而不割裂&#xff1a;解密敏捷協同工作模式如何驅動大企業持續領跑 在數字化浪潮中&#xff0c;亞馬遜僅用11天完成Prime Day全球技術架構升級&#xff0c;華為5G基站項目組創造過單周迭代47個功能模塊的紀錄&#xff0c;這些商業奇跡的背后&#xff0c;都隱藏著一個共性秘…

Python列表全面解析:從基礎到高階操作

一、為什么需要列表&#xff1f; 在Python中&#xff0c;列表是可變有序序列&#xff0c;用于存儲多個元素的容器。相較于單一變量存儲獨立值&#xff0c;列表能更高效地管理批量數據&#xff0c;其特點包括&#xff1a; ?引用存儲&#xff1a;列表元素存儲的是對象的引用?…

Spring知識點梳理

一、Spring&#xff08;Spring Framework&#xff09; 1、IOC&#xff08;控制反轉&#xff09; 1&#xff09;什么是IOC控制反轉&#xff1f; 為了解藕&#xff0c;有反轉就有“正轉”&#xff0c;“正轉”就是程序員手動 new對象&#xff1b;“反轉”就是將對象的創建、對…

SpringBoot啟動后自動執行方法的各種方式-筆記

1. SpringBoot啟動后自動執行方法的各種方式 1.1 PostConstruct 注解 作用&#xff1a;在依賴注入完成后執行初始化方法。 適用場景&#xff1a;需要在Bean初始化時執行某些操作&#xff08;如配置、預加載數據&#xff09;。 注意&#xff1a;該方法在Bean初始化階段執行&…

基礎知識-java流steam

Java Stream 流詳解 一、Stream 概述 #mermaid-svg-ZXmu5UZgAcGGq8EN {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-ZXmu5UZgAcGGq8EN .error-icon{fill:#552222;}#mermaid-svg-ZXmu5UZgAcGGq8EN .error-text{fil…

8.Android(通過Manifest配置文件傳遞數據(meta-data))

配置文件 <?xml version"1.0" encoding"utf-8"?> <manifest xmlns:android"http://schemas.android.com/apk/res/android"xmlns:tools"http://schemas.android.com/tools"><applicationandroid:allowBackup"tr…

java 解析入參里的cron表達式,修改周時間

文章目錄 前言一、java 解析入參里的cron表達式,修改周時間二、使用步驟1.示例 總結 前言 一、java 解析入參里的cron表達式,修改周時間 示例&#xff1a; 第一種: 0 0 0,16 ? * 0,1 第2種 0 0 0,16 ? * 1-7 第3種 0 0 0,16 ? * ? 第4種 0 0 0,16 ? * * 二、使用步驟 1…