Google開源框架LangExtract初體驗
從AI技術(shù)維度分類，大約可以將LangExtract歸為RAG框架，但從細處分辨，二者實有比較明顯的區(qū)別。RAG的關(guān)注重點是檢索，LangExtract的重點則如其名，是對數(shù)據(jù)的提取，且主要針對非結(jié)構(gòu)化文本數(shù)據(jù)進行結(jié)構(gòu)化提取。
LangExtract官網(wǎng)對它的介紹為：“一個使用大語言模型從非結(jié)構(gòu)化文本中提取結(jié)構(gòu)化信息的 Python 庫，具備精確的源定位和交互式可視化功能。”提取結(jié)構(gòu)化信息是其核心功能，而其亮點則是能夠提供精確的源定位，并完成交互式的可視化呈現(xiàn)。
之所以能提供精確的源定位，在于LangChain并沒有使用embedding的機制通過向量進行相似度計算和檢索，而是采用了一套精巧的確定性文本對齊算法：“首先通過指令讓LLM返回原文片段，然后利用WordAligner進行多層次匹配——從精確字符串匹配到模糊相似度計算，但始終避免了基于向量embedding的模糊對齊。”
例如，運行官方提供的醫(yī)療文本的提取代碼，可得到如下結(jié)果：
Extracted entities:
? Dosage: 400 mg (pos: 13-19)
? Route: PO (pos: 20-22)
? Medication: Ibuprofen (pos: 23-32)
? Frequency: q4h (pos: 33-36)
? Duration: for two days (pos: 37-49)結(jié)果清晰給出了提取的實體在文本所處的位置。在生成的jsonl文件中，以Dosage為例，輸出的結(jié)構(gòu)化數(shù)據(jù)為：
{"extraction_class":"dosage","extraction_text":"400 mg","char_interval":{"start_pos":13,"end_pos":19},"alignment_status":"match_exact","extraction_index":1,"group_index":0,"description":null,"attributes":{}}其中的char_interval屬性值就是提取結(jié)果在原文中的位置，很好地體現(xiàn)了它的溯源能力。
完成提取后，LangExtract會自動生成一個HTML文件，打開網(wǎng)頁能夠看到提取結(jié)構(gòu)的一種交互式可視化呈現(xiàn)：
圖片
雖說LangExtract官網(wǎng)將其定位為“Gemini 驅(qū)動的信息提取庫”，這大概是為了配合Google大模型的宣傳手段，但它顯然不會愚蠢得僅支持Gemini模型。事實上，它可以支持任何LLM，即便官方?jīng)]有提供支持，也可以自定義模型的Provider。事實上，前面輸出的結(jié)果使用的模型是我通過Ollama在本地部署的lamma3:7b模型：
result = lx.extract(
text_or_documents=input_text,
prompt_description=prompt_description,
examples=examples,
model_id="llama3:latest",# Automatically selects Ollama provider
model_url="http://localhost:11434",
fence_output=False,
use_schema_constraints=False)為了確保提取的結(jié)構(gòu)化結(jié)果更加可靠，LangExtract用到了需要大模型支持的“受控生成（Controlled Generation）”技術(shù)，這確實是Gemini的一大優(yōu)勢。除了受控生成技術(shù)，LangExtract還通過運用“少樣本”示例盡可能確保結(jié)果的穩(wěn)定性：
examples = [
lx.data.ExampleData(
text="Patient was given 250 mg IV Cefazolin TID for one week.",
extractinotallow=[
lx.data.Extraction(extraction_class="dosage", extraction_text="250 mg"),
lx.data.Extraction(extraction_class="route", extraction_text="IV"),
lx.data.Extraction(extraction_class="medication", extraction_text="Cefazolin"),
lx.data.Extraction(extraction_class="frequency", extraction_text="TID"), # TID = three times a day
lx.data.Extraction(extraction_class="duration", extraction_text="for one week")
]
)
]我看現(xiàn)在很多AI框架都在API上做文章，于不知不覺中引入提示詞工程，從而提升LLM生成結(jié)果的準確性。例如使用CrewAI創(chuàng)建Agent時，就要求給定Agent的Role、Goal和Backstory。LangExtract通過
ExampleData雖然LangExtract完全可以精確提取超長文本的高價值信息，卻是以消耗極高的token數(shù)量為代價，因此在生產(chǎn)使用時，必須考慮時間成本、基礎(chǔ)設(shè)置的資源成本以及算力成本。就以官方使用的《羅密歐與朱麗葉》為例，整個提取操作會消耗約44000 tokens。而這個所謂的長文本，其實還不到3萬個單詞。
我在本機嘗試使用lamma:7b的LLM對《羅密歐與朱麗葉》的文本進行提取，運行沒有多久，CPU就開始瘋狂運轉(zhuǎn)，不斷散發(fā)熱量，風(fēng)扇開始賣力的工作，結(jié)果沒等執(zhí)行完畢，就拋出了ResolverParsingError錯誤。我將LLM切換為更匹配LangExtract的gemma2:9b大模型，仍然出現(xiàn)同樣錯誤。顯然，真要讓LangChain為大量非結(jié)構(gòu)性文本提供精確的提取服務(wù)，背后需要更好的LLM和更強大的算力支持。
另一個不足之處在于LangExtract目前僅支持文本字符串作為文本源，一些常見的文本文檔文件，如PDF、DOCX，暫時都不支持。當(dāng)然，社區(qū)已經(jīng)看到了這一問題，目前作為Proposal的Issue提交到了LangExtract的Issue列表中。
無論如何，LangExtract為我們處理非結(jié)構(gòu)化文本提供一個不錯的選擇。
