1. 項(xiàng)目概述當(dāng)大模型學(xué)會“語法填空”最近在折騰大語言模型LLM應(yīng)用落地的朋友估計(jì)都遇到過同一個(gè)頭疼的問題模型生成的內(nèi)容格式五花八門完全不聽指揮。你讓它輸出一個(gè)JSON它可能給你一段帶注釋的偽代碼你讓它用特定模板回復(fù)它可能自由發(fā)揮把關(guān)鍵字段都漏了。這種“不聽話”直接導(dǎo)致了后續(xù)流程的崩潰讓自動化成了泡影。我最近深度實(shí)踐了一個(gè)方向感覺是解決這個(gè)問題的“銀彈”之一基于上下文無關(guān)文法Context-Free Grammars, CFG的語法約束解碼Grammar-Constrained Decoding。簡單說就是給模型的“嘴巴”上套一個(gè)“語法籠頭”讓它生成的所有文本都必須嚴(yán)格符合你預(yù)先定義好的一套語法規(guī)則。這不僅僅是格式控制更是將領(lǐng)域知識比如JSON結(jié)構(gòu)、SQL語法、API調(diào)用序列直接“編譯”進(jìn)生成過程實(shí)現(xiàn)可靠的結(jié)構(gòu)化輸出。而更讓我興奮的是我們正步入一個(gè)新時(shí)代聲明式智能體編程Declarative Agentic Programming。我們不再需要寫冗長、脆弱的提示詞Prompt去“哄著”模型或者設(shè)計(jì)復(fù)雜的后處理管道去清洗它的輸出。相反我們可以像寫配置文件一樣聲明式地定義我們期望的輸出結(jié)構(gòu)用CFG然后由系統(tǒng)保證Guarantees模型會遵守它。這就像從“面向過程的腳本編程”升級到了“面向聲明的契約編程”開發(fā)效率和系統(tǒng)可靠性得到了質(zhì)的飛躍。這個(gè)項(xiàng)目就是關(guān)于如何讓大模型“學(xué)會”這些CFG并利用聲明式編程范式構(gòu)建出有嚴(yán)格保證的智能體。它結(jié)合了形式語言理論、現(xiàn)代LLM推理優(yōu)化以及軟件工程的最佳實(shí)踐是當(dāng)前讓AI從“玩具”走向“工具”的關(guān)鍵技術(shù)路徑。2. 核心思路從“提示工程”到“語法契約”傳統(tǒng)的LLM應(yīng)用開發(fā)嚴(yán)重依賴提示工程。我們通過精心設(shè)計(jì)的提示詞試圖引導(dǎo)模型產(chǎn)生我們想要的輸出。這種方法有幾個(gè)根本性缺陷脆弱性提示詞的微小改動、模型版本的升級、甚至同樣的提示詞運(yùn)行兩次都可能導(dǎo)致輸出格式的漂移。不可靠性無法從機(jī)制上保證輸出100%符合特定語法總需要額外的驗(yàn)證和重試邏輯增加了系統(tǒng)復(fù)雜度。低效性為了控制格式我們常常在提示詞中嵌入大量例子Few-shot占用了寶貴的上下文窗口也增加了推理成本。語法約束解碼提供了一種根本性的解決方案。它的核心思想是在模型解碼即生成下一個(gè)詞的每一步都進(jìn)行過濾只允許那些能導(dǎo)向最終符合語法規(guī)則的序列的token被選中。這相當(dāng)于在模型的詞匯表上動態(tài)地施加了一個(gè)掩碼Mask。而聲明式智能體編程是這個(gè)方案的上層建筑。我們不再告訴智能體“第一步該做什么第二步該做什么”命令式而是告訴它“我最終要的是一個(gè)符合這個(gè)SQL語法的查詢你去和用戶對話并生成它”聲明式。智能體內(nèi)部如何利用LLM、工具、記憶去達(dá)成這個(gè)目標(biāo)是系統(tǒng)自動規(guī)劃和執(zhí)行的。CFG在這里扮演了“契約”或“接口規(guī)范”的角色它定義了智能體輸出必須滿足的形式從而將智能體的“意圖”與“實(shí)現(xiàn)”解耦。為什么是上下文無關(guān)文法CFGCFG是計(jì)算機(jī)科學(xué)中描述編程語言、標(biāo)記語言語法的標(biāo)準(zhǔn)工具。它足夠強(qiáng)大可以描述JSON、XML、SQL、算術(shù)表達(dá)式等復(fù)雜嵌套結(jié)構(gòu)同時(shí)又足夠簡單其解析和生成過程可以被高效地集成到LLM的解碼器中。相比于正則表達(dá)式CFG能處理遞歸和嵌套表達(dá)能力更強(qiáng)相比于全功能的解析器它又更輕量和專注。這個(gè)項(xiàng)目的核心目標(biāo)就是探索如何自動或半自動地從數(shù)據(jù)或需求中推導(dǎo)出高質(zhì)量的CFG即“Learning”的部分并構(gòu)建一個(gè)以聲明式CFG契約為核心、提供可靠性保證的智能體編程框架。3. 核心技術(shù)點(diǎn)拆解文法、解碼與智能體的三角關(guān)系3.1 上下文無關(guān)文法CFG的表示與學(xué)習(xí)CFG通常由一個(gè)四元組定義非終結(jié)符集合、終結(jié)符集合即詞匯表、產(chǎn)生式規(guī)則集合和開始符號。在LLM場景下我們需要一種既適合機(jī)器處理也便于人理解和定義的表示方式。常見表示法EBNF擴(kuò)展巴科斯范式最常用可讀性強(qiáng)。例如一個(gè)簡單算術(shù)表達(dá)式的文法expression :: term ( (‘’ | ‘-’) term )* term :: factor ( (‘*’ | ‘/’) factor )* factor :: NUMBER | ‘(’ expression ‘)’JSON Schema對于描述JSON結(jié)構(gòu)特別自然很多庫如pydantic可以直接從中推導(dǎo)出約束。自定義DSL領(lǐng)域特定語言針對特定領(lǐng)域如API調(diào)用鏈設(shè)計(jì)更簡潔的文法。“學(xué)習(xí)”CFG的幾種路徑這里的“學(xué)習(xí)”不是指讓模型像學(xué)習(xí)自然語言一樣學(xué)習(xí)文法而是指如何為我們特定的任務(wù)獲取或生成一個(gè)正確的CFG。從規(guī)范/標(biāo)準(zhǔn)中手動定義這是最直接、最可靠的方式。如果你要生成JSON那就用JSON Schema要生成SQL就用SQL的EBNF。這要求開發(fā)者有相應(yīng)的領(lǐng)域知識。從示例數(shù)據(jù)中誘導(dǎo)給定一組符合目標(biāo)格式的正確輸出示例使用文法歸納Grammar Induction算法來自動推斷出CFG。這對于沒有明確文檔但有很多實(shí)例的場景非常有用。例如從幾百個(gè)用戶的歷史查詢?nèi)罩局袣w納出用戶查詢的常見模式。混合方法規(guī)范示例精煉先根據(jù)規(guī)范定義一個(gè)基礎(chǔ)文法然后利用示例數(shù)據(jù)來發(fā)現(xiàn)規(guī)范中未覆蓋但實(shí)際常用的“方言”或快捷寫法對文法進(jìn)行擴(kuò)展和精煉。利用LLM自身生成文法這是一個(gè)新興且強(qiáng)大的思路。你可以用自然語言向一個(gè)強(qiáng)大的LLM如GPT-4描述你想要的輸出格式然后要求它為你生成對應(yīng)的EBNF或JSON Schema。經(jīng)過人工校驗(yàn)和修正后這個(gè)生成的文法就可以用于約束較小的模型如本地部署的7B模型實(shí)現(xiàn)“大模型教小模型守規(guī)矩”。實(shí)操心得從示例誘導(dǎo)文法聽起來很美好但在實(shí)踐中生成的文法可能過于具體過擬合或過于寬松。一個(gè)關(guān)鍵的技巧是引入負(fù)例。除了提供正確的輸出也提供一些常見的錯(cuò)誤輸出告訴歸納算法“這些是不被允許的”這能幫助學(xué)習(xí)到更精確、更健壯的文法邊界。3.2 語法約束解碼Grammar-Constrained Decoding的實(shí)現(xiàn)機(jī)制這是將CFG“注入”模型生成過程的核心技術(shù)。主流方法是在每個(gè)解碼步驟動態(tài)計(jì)算一個(gè)“允許的token集合”。核心算法解析狀態(tài)跟蹤維護(hù)一個(gè)解析棧或狀態(tài)機(jī)代表當(dāng)前已生成的部分序列在CFG中的解析進(jìn)度。前瞻Look-ahead與過濾基于當(dāng)前的解析狀態(tài)計(jì)算下一個(gè)或下幾個(gè)位置可能出現(xiàn)的所有合法終結(jié)符token。將模型預(yù)測的詞匯表概率分布與這個(gè)合法token集合取交集然后重新歸一化只從合法token中采樣。增量解析每生成一個(gè)新token就更新解析狀態(tài)。如果某個(gè)生成路徑導(dǎo)致語法錯(cuò)誤無合法后續(xù)token則回溯或賦予該路徑極低的概率。主流庫與集成Outlines / Guidance這類庫將CFG或正則表達(dá)式編譯成高效的有窮狀態(tài)機(jī)并與Transformers庫深度集成。它們通常提供一個(gè)generate函數(shù)你傳入模型、文法約束和提示詞它就能返回符合文法的結(jié)果。Transformers 庫原生集成Hugging Face的transformers庫從某個(gè)版本開始在GenerationMixin中引入了grammar參數(shù)支持通過一個(gè)GrammarConstraint對象來指導(dǎo)生成。其底層通常也是類似的自動機(jī)實(shí)現(xiàn)。自定義采樣器對于更極致的控制你可以實(shí)現(xiàn)自己的LogitsProcessor。在__call__方法中接收當(dāng)前所有候選token的logits然后根據(jù)你的解析狀態(tài)將非法token的logits設(shè)置為負(fù)無窮-inf。一個(gè)簡化示例概念層面假設(shè)文法規(guī)定下一個(gè)字符必須是數(shù)字。模型原始預(yù)測的下一個(gè)token概率分布是“1”: 0.4, “a”: 0.3, “,”: 0.3。經(jīng)過語法約束過濾后“a”和“,”被屏蔽概率分布被重新歸一化為“1”: 1.0。模型將必然生成“1”。注意事項(xiàng)文法約束的強(qiáng)度需要權(quán)衡。過于嚴(yán)格的文法可能會扼殺模型的創(chuàng)造力導(dǎo)致生成內(nèi)容雖然格式正確但語義空洞。一個(gè)技巧是使用“軟約束”例如不是將非法token的概率直接設(shè)為負(fù)無窮而是將其大幅降低例如除以一個(gè)很大的數(shù)這樣在極端情況下模型仍有可能“突破”文法但概率極低。這為生成提供了一點(diǎn)彈性。3.3 聲明式智能體編程框架的構(gòu)建這是將前述技術(shù)產(chǎn)品化的關(guān)鍵。一個(gè)聲明式智能體框架通常包含以下組件契約Contract定義層提供一套DSL或API讓開發(fā)者能夠方便地聲明智能體的目標(biāo)。最核心的聲明就是輸出格式的CFG。此外還可能包括輸入模式智能體接受什么樣的輸入如用戶問題必須包含“查詢”和“過濾條件”兩個(gè)部分。工具規(guī)范智能體可以調(diào)用哪些工具這些工具的輸入輸出格式是什么也可以用CFG描述。狀態(tài)模式智能體內(nèi)部記憶或?qū)υ挔顟B(tài)的結(jié)構(gòu)。規(guī)劃與執(zhí)行引擎接收聲明式契約和當(dāng)前用戶輸入自動規(guī)劃執(zhí)行步驟。例如它可能判斷需要先調(diào)用一個(gè)“查詢理解”工具再調(diào)用一個(gè)“數(shù)據(jù)庫模式查找”工具最后才生成SQL。這個(gè)規(guī)劃過程本身可能由一個(gè)LLM驅(qū)動但其每一步的輸出都受到相應(yīng)步驟契約CFG的約束。可靠性保證模塊這是“Guarantees”的體現(xiàn)。框架需要提供以下一種或多種保證語法正確性保證所有最終輸出100%符合聲明的CFG。這是通過約束解碼在技術(shù)層面強(qiáng)制實(shí)現(xiàn)的。類型安全保證如果CFG與類型系統(tǒng)綁定如從JSON Schema生成則輸出不僅是語法正確其值也符合聲明的類型如字符串、數(shù)字、布爾值。可達(dá)性保證框架能驗(yàn)證在給定的工具集和約束下是否存在一條路徑可以完成用戶請求。如果不存在則提前失敗并給出清晰原因而不是讓智能體陷入死循環(huán)或產(chǎn)生無意義輸出。調(diào)試與觀測當(dāng)智能體行為不符合預(yù)期時(shí)框架需要提供強(qiáng)大的調(diào)試信息例如在哪一步規(guī)劃失敗了是契約太嚴(yán)格導(dǎo)致無解還是模型在約束下選擇了次優(yōu)的token與“ReWOO”、“LangChain”等框架的異同 像LangChain這類框架是命令式、過程式的。你需要顯式地定義LLMChain、Tool、AgentExecutor的調(diào)用順序。而聲明式框架更接近react或vue的響應(yīng)式編程你定義好狀態(tài)用戶需求和視圖輸出格式契約框架自動計(jì)算出需要執(zhí)行的動作序列。ReWOOReasoning Without Observation等規(guī)劃式框架已經(jīng)帶有聲明式的色彩但通常缺乏對輸出結(jié)構(gòu)形式化、可驗(yàn)證的強(qiáng)保證。4. 實(shí)戰(zhàn)構(gòu)建一個(gè)語法可靠的SQL生成智能體讓我們通過一個(gè)具體例子將上述所有概念串聯(lián)起來。我們的目標(biāo)是構(gòu)建一個(gè)智能體它能理解用戶的自然語言查詢并生成語法絕對正確的SELECT語句。4.1 步驟一定義SQL子集的CFG契約我們首先需要聲明我們的智能體輸出必須遵守的“憲法”。這里我們定義一個(gè)簡化版的SELECT語句文法使用EBNF(* 簡化SQL SELECT文法 *) SQLQuery :: “SELECT” SelectList “FROM” TableName ( “WHERE” WhereClause )? (“;”)? SelectList :: ColumnName ( “,” ColumnName )* | “*” ColumnName :: Identifier TableName :: Identifier WhereClause :: Condition ( (“AND” | “OR”) Condition )* Condition :: ColumnName Operator Value Operator :: “” | “!” | “” | “” | “” | “” | “LIKE” Value :: StringLiteral | NumberLiteral | “NULL” Identifier :: [a-zA-Z_][a-zA-Z0-9_]* StringLiteral :: “‘“ ( [^’] | “’’” )* “‘“ NumberLiteral :: [0-9] ( “.” [0-9]* )?這個(gè)文法定義了合法的查詢結(jié)構(gòu)。注意這里的Identifier、StringLiteral等終結(jié)符需要映射到LLM詞匯表中的具體token序列。在實(shí)際庫中如Outlines你需要將這個(gè)EBNF編譯成它內(nèi)部的狀態(tài)機(jī)表示。4.2 步驟二集成約束解碼器接下來我們選擇一個(gè)支持約束解碼的庫并將上述文法集成進(jìn)去。以使用transformers庫和自定義GrammarLogitsProcessor為例概念代碼from transformers import AutoModelForCausalLM, AutoTokenizer, LogitsProcessor import some_grammar_library as gr # 假設(shè)有一個(gè)文法處理庫 class SQLGrammarLogitsProcessor(LogitsProcessor): def __init__(self, grammar_text, tokenizer): self.grammar gr.compile(grammar_text) # 編譯文法 self.tokenizer tokenizer self.parser_state None def __call__(self, input_ids, scores): # 1. 將當(dāng)前生成的token序列解碼成文本前綴 current_text self.tokenizer.decode(input_ids[0], skip_special_tokensTrue) # 2. 用文法解析當(dāng)前前綴獲取下一個(gè)合法字符集 allowed_next_chars self.grammar.get_allowed_chars(current_text) # 3. 將合法字符集轉(zhuǎn)換為token id掩碼 mask self._create_token_mask(allowed_next_chars) # 4. 應(yīng)用掩碼非法token得分為負(fù)無窮 scores scores.masked_fill(~mask, float(‘-inf’)) return scores def _create_token_mask(self, allowed_chars): # 這是一個(gè)簡化示例。實(shí)際需要處理tokenizer子詞與字符的映射更復(fù)雜。 # 真實(shí)庫如Outlines會高效地處理這一切。 vocab_size self.tokenizer.vocab_size mask torch.zeros(vocab_size, dtypetorch.bool) for token_id in range(vocab_size): token_str self.tokenizer.decode([token_id]) if token_str in allowed_chars: # 這里需要更精細(xì)的映射邏輯 mask[token_id] True return mask # 使用 tokenizer AutoTokenizer.from_pretrained(“meta-llama/Llama-3.2-3B-Instruct”) model AutoModelForCausalLM.from_pretrained(“meta-llama/Llama-3.2-3B-Instruct”) grammar_processor SQLGrammarLogitsProcessor(SQL_GRAMMAR_TEXT, tokenizer) input_prompt “””你是一個(gè)SQL專家。請根據(jù)用戶問題生成SQL查詢。 數(shù)據(jù)庫表 ‘users’ 包含列id, name, age, city。 用戶問題找出所有來自北京且年齡大于25歲的用戶姓名。””” input_ids tokenizer(input_prompt, return_tensors“pt”).input_ids output model.generate( input_ids, max_length200, logits_processor[grammar_processor], do_sampleTrue, temperature0.7 ) generated_sql tokenizer.decode(output[0], skip_special_tokensTrue) print(generated_sql) # 輸出將嚴(yán)格符合我們定義的文法例如SELECT name FROM users WHERE city ‘北京’ AND age 25;在實(shí)際中更推薦使用成熟的庫如outlines它封裝了所有復(fù)雜細(xì)節(jié)import outlines.models as models import outlines.text as text model models.transformers(“meta-llama/Llama-3.2-3B-Instruct”) grammar text.cfg.SQL_GRAMMAR_TEXT # 假設(shè)text.cfg支持直接定義 generator text.generate.cfg(model, grammar) generated_sql generator(input_prompt)4.3 步驟三構(gòu)建聲明式智能體現(xiàn)在我們將這個(gè)有保障的SQL生成器嵌入到一個(gè)更大的聲明式智能體框架中。這個(gè)智能體可能需要處理更復(fù)雜的任務(wù)比如先澄清模糊需求或查詢數(shù)據(jù)庫模式。我們定義智能體的契約最終輸出必須符合上述SQL文法。內(nèi)部工具clarify_question(question: str) - str: 一個(gè)LLM調(diào)用用于澄清模糊的用戶問題。其輸入輸出都是自然語言無需CFG約束或用一個(gè)簡單的“非空字符串”約束。get_schema(table_name: str) - JSON: 一個(gè)工具調(diào)用返回指定表的模式。其輸出必須符合一個(gè)預(yù)定義的JSON Schema。generate_sql(clarified_question: str, schema: JSON) - SQL: 即我們上面實(shí)現(xiàn)的約束解碼生成器。智能體框架的工作流可能是接收用戶輸入“找一下北京的老用戶”。框架自動規(guī)劃識別到輸入模糊“老用戶”決定調(diào)用clarify_question工具。調(diào)用該工具獲得澄清后的問題“找出年齡大于60歲且城市在北京的用戶”。框架自動規(guī)劃識別到生成SQL需要表結(jié)構(gòu)決定調(diào)用get_schema工具。假設(shè)用戶提到了“用戶”框架推斷表名為users調(diào)用工具獲得模式信息。框架自動規(guī)劃將澄清后的問題和模式信息傳遞給generate_sql工具。由于該工具的契約是輸出必須符合CFG框架可以100%信任其輸出的語法正確性。輸出最終SQL。整個(gè)過程中開發(fā)者沒有編寫一步步的調(diào)用邏輯只是聲明了可用的工具、每個(gè)工具的輸入輸出契約、以及最終目標(biāo)的契約一個(gè)合法的SQL。框架負(fù)責(zé)了規(guī)劃和執(zhí)行并保證了最終結(jié)果的語法正確性。5. 常見陷阱與進(jìn)階優(yōu)化在實(shí)際部署中你會遇到各種挑戰(zhàn)。以下是我踩過的一些坑和總結(jié)的優(yōu)化技巧。5.1 文法設(shè)計(jì)與模型能力的匹配問題你設(shè)計(jì)了一個(gè)極其復(fù)雜、嚴(yán)格的CFG但你的模型比如一個(gè)7B參數(shù)的小模型的詞匯表或訓(xùn)練數(shù)據(jù)可能無法在如此嚴(yán)格的約束下流暢地生成內(nèi)容導(dǎo)致生成速度慢、內(nèi)容生硬或失敗。解決方案從簡到繁開始時(shí)使用一個(gè)寬松的文法例如只約束最外層的結(jié)構(gòu)如必須包含SELECT和FROM關(guān)鍵字然后逐步收緊。分層約束對于復(fù)雜輸出可以分階段應(yīng)用約束。例如先讓模型在高層級選擇“查詢類型”SELECT, INSERT, UPDATE然后根據(jù)選擇動態(tài)加載對應(yīng)的子文法進(jìn)行下一步生成。使用更強(qiáng)大的“教師”模型用GPT-4等大模型在嚴(yán)格約束下生成高質(zhì)量的示例然后用這些示例來微調(diào)Fine-tune小模型。這樣小模型就學(xué)會了在約束下“應(yīng)該怎么說”而不僅僅是“可以怎么說”。5.2 處理詞匯表與子詞Subword的錯(cuò)位問題這是實(shí)現(xiàn)約束解碼時(shí)最棘手的技術(shù)細(xì)節(jié)之一。CFG工作在字符或單詞級別但現(xiàn)代LLM如基于BPE的使用子詞分詞。一個(gè)合法的字符如“可能只是某個(gè)token的一部分如‘“,’。簡單地按token過濾會破壞解碼。解決方案使用成熟的庫像Outlines、Guidance這樣的庫已經(jīng)妥善處理了這個(gè)問題。它們內(nèi)部使用“前綴匹配”或“字節(jié)級”的有限狀態(tài)機(jī)能與子詞分詞器很好地協(xié)作。如果你必須自己實(shí)現(xiàn)考慮在字節(jié)級別定義文法和進(jìn)行約束。因?yàn)槿魏蝨oken最終都可以解碼為字節(jié)序列。在字節(jié)流上應(yīng)用文法約束然后再編碼回token空間。這更復(fù)雜但更根本。5.3 性能開銷問題每一步解碼都需要進(jìn)行文法狀態(tài)計(jì)算和token過濾這會增加生成延遲。優(yōu)化技巧預(yù)編譯與緩存將CFG編譯成最優(yōu)化的確定性有限自動機(jī)DFA或類似結(jié)構(gòu)。對于給定的解析狀態(tài)下一個(gè)合法字符集是確定的可以快速查表。批量解碼如果硬件允許對多個(gè)序列進(jìn)行批量生成時(shí)約束解碼的開銷可以被均攤。投機(jī)解碼Speculative Decoding用一個(gè)快速的小模型或原始模型的前幾層來起草多個(gè)候選token序列然后用大模型和文法約束一起快速驗(yàn)證和接受其中合法的部分。這可以大幅減少對大模型的高成本調(diào)用次數(shù)。5.4 保證語義正確性問題文法約束只能保證語法正確不能保證語義正確。模型可能生成一句語法完美但毫無意義的SQL比如SELECT name FROM users WHERE age ‘a(chǎn)bc’。解決方案增強(qiáng)契約在CFG中嵌入更多語義信息。例如在Value的產(chǎn)生式中可以根據(jù)前面的ColumnName來約束Value的類型數(shù)字列對應(yīng)NumberLiteral字符串列對應(yīng)StringLiteral。這需要更復(fù)雜的“屬性文法”。后置驗(yàn)證與重試生成后使用一個(gè)輕量級的驗(yàn)證器如真正的SQL解析器、類型檢查器進(jìn)行檢查。如果語義錯(cuò)誤可以將錯(cuò)誤信息作為反饋重新進(jìn)行生成。這構(gòu)成了一個(gè)“生成-驗(yàn)證-修正”的循環(huán)。在提示詞中提供豐富上下文這是基礎(chǔ)但至關(guān)重要的。在提示詞中提供準(zhǔn)確的數(shù)據(jù)庫模式、示例值、外鍵關(guān)系等能極大提升模型生成語義正確內(nèi)容的能力。文法約束是“硬保險(xiǎn)”而好的上下文是“軟引導(dǎo)”。6. 未來展望從語法約束到語義約束當(dāng)前基于CFG的約束主要解決的是形式正確性問題。未來的方向是將約束提升到語義和邏輯層面。這可能會通過以下方式實(shí)現(xiàn)與形式驗(yàn)證結(jié)合對于生成的代碼或配置不僅檢查語法還通過符號執(zhí)行或模型檢查來驗(yàn)證其是否滿足某些安全屬性或功能規(guī)約。神經(jīng)符號系統(tǒng)將神經(jīng)網(wǎng)絡(luò)的LLM與符號推理引擎更緊密地結(jié)合。LLM負(fù)責(zé)創(chuàng)造性部分和自然語言理解符號系統(tǒng)負(fù)責(zé)確保邏輯、數(shù)學(xué)和領(lǐng)域規(guī)則的嚴(yán)格遵守。學(xué)習(xí)更豐富的約束從人類反饋如代碼評審意見、SQL查詢結(jié)果的對錯(cuò)中學(xué)習(xí)更復(fù)雜的約束這些約束可能無法用簡單的CFG表達(dá)但可以用更復(fù)雜的邏輯公式或神經(jīng)網(wǎng)絡(luò)分類器來表示。我個(gè)人在實(shí)際操作中的體會是聲明式文法約束是目前將LLM接入生產(chǎn)系統(tǒng)最實(shí)用的“安全帶”之一。它極大地降低了集成和運(yùn)維的認(rèn)知負(fù)荷。我不再需要像偵探一樣去解析模型千奇百怪的輸出也不再需要編寫復(fù)雜的正則表達(dá)式去修補(bǔ)漏洞。我只需要定義好“規(guī)則”然后就能獲得穩(wěn)定、可預(yù)期的輸出。這感覺就像從駕駛手動擋汽車換成了自動駕駛——你可以更專注于目的地業(yè)務(wù)邏輯而不是換擋和油離配合提示工程和輸出清洗。雖然現(xiàn)在的“自動駕駛”還只能在特定道路上定義好的文法內(nèi)運(yùn)行但這已經(jīng)是一個(gè)巨大的飛躍是構(gòu)建可靠AI應(yīng)用的堅(jiān)實(shí)基石。