SQL做成可上線的查詢系統(tǒng))
Vanna AI 完全指南如何把自然語言轉(zhuǎn)SQL做成可上線的查詢系統(tǒng)【免費下載鏈接】vanna Chat with your SQL database . Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval .項目地址: https://gitcode.com/GitHub_Trending/va/vannaVanna AI 是一個開源的 Python 框架核心工作只有一句話把自然語言問題轉(zhuǎn)成可執(zhí)行的 SQL 并返回答案。它適合兩類人——想讓業(yè)務(wù)同事用大白話直接查數(shù)據(jù)庫的開發(fā)者以及需要給現(xiàn)有產(chǎn)品加一個對話式取數(shù)入口、又不想自己從零搭聊天界面和權(quán)限體系的小團隊。 先跑通一條命令裝好五分鐘問出第一條數(shù)據(jù)大多數(shù) Text-to-SQL 方案卡在演示能看、上線難搞這一步。Vanna 的思路是先把最小閉環(huán)做短裝包、接數(shù)據(jù)庫、注冊工具、掛上服務(wù)四件事做完就能問答。安裝只需一條命令pip install vanna跑通的最小路徑在 notebooks/quickstart.ipynb 里以 SQLite 為例用SqliteRunner接上庫文件把RunSqlTool注冊進ToolRegistry再交給Agent然后調(diào)用VannaFastAPIServer起服務(wù)。如果暫時沒有 LLM 的 API Key倉庫還提供了離線樣例 src/vanna/examples/mock_quickstart.py用 Mock LLM 驗證整個鏈路通不通不花一分錢。一個容易被忽略的起點建議先拿一個你自己很熟的庫比如演示用的 Chinook做第一批問題把問法 → 正確 SQL的對照記下來。這批樣本后面會直接決定生成質(zhì)量下文會解釋為什么。 原理決定準(zhǔn)確率的不是模型是喂給模型什么上下文Vanna 的官方測試論文papers/ai-sql-accuracy-2023-08-17.md做過一組對照實驗3 個 LLM × 3 種上下文策略 × 20 個問題共 180 次生成。結(jié)論比較反直覺——只給表結(jié)構(gòu)schema總準(zhǔn)確率約 3%。模型光靠字段名猜不出你的業(yè)務(wù)口徑給少量固定 SQL 示例明顯提升但各模型之間差距拉大弱模型依然不穩(wěn)按問題檢索最相關(guān)的歷史 SQL 示例準(zhǔn)確率跳到 80% 左右在復(fù)雜上下文場景下可到 88% 以上。這就是Agentic Retrieval在 Vanna 里的具體含義用戶提問時系統(tǒng)先做相關(guān)性檢索把歷史上被驗證過正確的相似查詢撈出來拼進 prompt再交給 LLM 生成。它帶來的實際影響是——模型選型是次要決策樣本積累是主要決策。團隊里業(yè)務(wù)問得越多、存下的正確 SQL 越多系統(tǒng)就越準(zhǔn)這是個正反饋循環(huán)。架構(gòu)上2.0 版本把整條鏈路重寫成 Agent 形態(tài)請求進來后UserResolver 先從請求里解出用戶身份Cookie、JWT、OAuth 均可接你自己的認(rèn)證系統(tǒng)身份隨后進系統(tǒng)提示詞、工具執(zhí)行和 SQL 過濾的每一個環(huán)節(jié)結(jié)果以流式組件表格、圖表、摘要推給前端。 拿到手的不是文本是流式結(jié)果一次問答在vanna-chat組件里依次返回五樣?xùn)|西實時進度、SQL 代碼塊默認(rèn)只對 admin 組可見、可交互的數(shù)據(jù)表、Plotly 圖表以及一段自然語言摘要。全部走 SSE 流式推送不用等整條 SQL 跑完才出內(nèi)容。前端集成成本是它比較突出的一個賣點頁面里引入一個vanna-chat標(biāo)簽并指向你的 SSE 端點即可兼容 React、Vue 和純 HTML自帶深淺兩套主題和移動端適配。組件源碼在 frontends/webcomponent/想改交互可以自己編譯。換句話說取數(shù)界面這塊通常要外包或養(yǎng)前端的活它給你預(yù)置了。 權(quán)限、審計與配額多用戶場景的三個默認(rèn)能力給業(yè)務(wù)人員開放數(shù)據(jù)庫查詢繞不開三個問題誰能看到哪些行、每次查詢有沒有記錄、資源消耗能不能控。Vanna 2.0 對這三點都是內(nèi)置機制而非可選插件行級安全工具層根據(jù)用戶所屬權(quán)限組自動過濾查詢結(jié)果同一張表不同人看到的行不同審計日志每個用戶的每次查詢都有獨立記錄面向合規(guī)場景按用戶配額通過生命周期鉤子在請求的關(guān)鍵節(jié)點掛檢查邏輯限流、日志、內(nèi)容過濾都走同一套擴展點。自定義能力也走明確的基類繼承Tool基類就能加新工具比如發(fā)郵件、查外部接口access_groups屬性聲明該工具的權(quán)限組框架負責(zé)校驗。LLM 調(diào)用外面還有一層 middleware 位置緩存、成本統(tǒng)計這類需求不用動 Agent 主邏輯。 覆蓋范圍模型與數(shù)據(jù)庫都是任選其一維度內(nèi)置支持LLMOpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、Mistral、Ollama、vLLM 等數(shù)據(jù)庫PostgreSQL、MySQL、SQLite、Snowflake、BigQuery、Redshift、Oracle、SQL Server、DuckDB、ClickHouse、Hive、Presto 等向量存儲Agent 記憶ChromaDB、FAISS、Milvus、Qdrant、Pinecone、Weaviate、OpenSearch、Marqo、本地內(nèi)存等服務(wù)端FastAPI、Flask 兩套路由SSE 流式端點集成代碼都在 src/vanna/integrations/ 下按廠商分目錄選型時基本不需要膠水代碼。用 Ollama 或 vLLM 跑本地模型也能接適合對數(shù)據(jù)出域敏感的場景——代價是本地小模型的 SQL 準(zhǔn)確率會明顯低于云端旗艦?zāi)Ｐ蜕厦婺墙M準(zhǔn)確率數(shù)據(jù)里弱模型的表現(xiàn)可以當(dāng)參照。?? 收尾判斷什么情況下值得引入 Vanna適合團隊需要一個能對外提供、帶權(quán)限和審計的取數(shù)入口且愿意持續(xù)沉淀問題—SQL樣本或者已有認(rèn)證體系只差一個把自然語言接進去的后端。需要先想清楚的代價準(zhǔn)確率有下限依賴——上下文檢索的樣本庫是冷啟動階段最弱的一環(huán)前期問得少時準(zhǔn)確率會貼近只給 schema那檔建議上線前用業(yè)務(wù)真實問題建一個小評測集倉庫的 src/core/evaluation/ 提供了數(shù)據(jù)集、評估器和報告的完整骨架0.x 用戶是重寫而非升級——API 從VannaBase方法變成了 Agent 工具注冊舊代碼可用LegacyVannaAdapter包一層先接上新 UI再逐步遷移具體步驟見 MIGRATION_GUIDE.md?？傇uVanna 把自然語言轉(zhuǎn) SQL從 demo 做到生產(chǎn)之間最麻煩的三段——權(quán)限過濾、流式前端、樣本閉環(huán)——都給了默認(rèn)實現(xiàn)。它不替你解決業(yè)務(wù)口徑模糊的問題但把剩下的工程部分壓縮到了幾條配置和一次樣本積累的周期?！久赓M下載鏈接】vanna Chat with your SQL database . Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval .項目地址: https://gitcode.com/GitHub_Trending/va/vanna創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Vanna AI 完全指南：如何把自然語言轉(zhuǎn)SQL做成可上線的查詢系統(tǒng)
Vanna AI 完全指南如何把自然語言轉(zhuǎn)SQL做成可上線的查詢系統(tǒng)【免費下載鏈接】vanna Chat with your SQL database . Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval .項目地址: https://gitcode.com/GitHub_Trending/va/vannaVanna AI 是一個開源的 Python 框架核心工作只有一句話把自然語言問題轉(zhuǎn)成可執(zhí)行的 SQL 并返回答案。它適合兩類人——想讓業(yè)務(wù)同事用大白話直接查數(shù)據(jù)庫的開發(fā)者以及需要給現(xiàn)有產(chǎn)品加一個對話式取數(shù)入口、又不想自己從零搭聊天界面和權(quán)限體系的小團隊。 先跑通一條命令裝好五分鐘問出第一條數(shù)據(jù)大多數(shù) Text-to-SQL 方案卡在演示能看、上線難搞這一步。Vanna 的思路是先把最小閉環(huán)做短裝包、接數(shù)據(jù)庫、注冊工具、掛上服務(wù)四件事做完就能問答。安裝只需一條命令pip install vanna跑通的最小路徑在 notebooks/quickstart.ipynb 里以 SQLite 為例用SqliteRunner接上庫文件把RunSqlTool注冊進ToolRegistry再交給Agent然后調(diào)用VannaFastAPIServer起服務(wù)。如果暫時沒有 LLM 的 API Key倉庫還提供了離線樣例 src/vanna/examples/mock_quickstart.py用 Mock LLM 驗證整個鏈路通不通不花一分錢。一個容易被忽略的起點建議先拿一個你自己很熟的庫比如演示用的 Chinook做第一批問題把問法 → 正確 SQL的對照記下來。這批樣本后面會直接決定生成質(zhì)量下文會解釋為什么。 原理決定準(zhǔn)確率的不是模型是喂給模型什么上下文Vanna 的官方測試論文papers/ai-sql-accuracy-2023-08-17.md做過一組對照實驗3 個 LLM × 3 種上下文策略 × 20 個問題共 180 次生成。結(jié)論比較反直覺——只給表結(jié)構(gòu)schema總準(zhǔn)確率約 3%。模型光靠字段名猜不出你的業(yè)務(wù)口徑給少量固定 SQL 示例明顯提升但各模型之間差距拉大弱模型依然不穩(wěn)按問題檢索最相關(guān)的歷史 SQL 示例準(zhǔn)確率跳到 80% 左右在復(fù)雜上下文場景下可到 88% 以上。這就是Agentic Retrieval在 Vanna 里的具體含義用戶提問時系統(tǒng)先做相關(guān)性檢索把歷史上被驗證過正確的相似查詢撈出來拼進 prompt再交給 LLM 生成。它帶來的實際影響是——模型選型是次要決策樣本積累是主要決策。團隊里業(yè)務(wù)問得越多、存下的正確 SQL 越多系統(tǒng)就越準(zhǔn)這是個正反饋循環(huán)。架構(gòu)上2.0 版本把整條鏈路重寫成 Agent 形態(tài)請求進來后UserResolver 先從請求里解出用戶身份Cookie、JWT、OAuth 均可接你自己的認(rèn)證系統(tǒng)身份隨后進系統(tǒng)提示詞、工具執(zhí)行和 SQL 過濾的每一個環(huán)節(jié)結(jié)果以流式組件表格、圖表、摘要推給前端。 拿到手的不是文本是流式結(jié)果一次問答在vanna-chat組件里依次返回五樣?xùn)|西實時進度、SQL 代碼塊默認(rèn)只對 admin 組可見、可交互的數(shù)據(jù)表、Plotly 圖表以及一段自然語言摘要。全部走 SSE 流式推送不用等整條 SQL 跑完才出內(nèi)容。前端集成成本是它比較突出的一個賣點頁面里引入一個vanna-chat標(biāo)簽并指向你的 SSE 端點即可兼容 React、Vue 和純 HTML自帶深淺兩套主題和移動端適配。組件源碼在 frontends/webcomponent/想改交互可以自己編譯。換句話說取數(shù)界面這塊通常要外包或養(yǎng)前端的活它給你預(yù)置了。 權(quán)限、審計與配額多用戶場景的三個默認(rèn)能力給業(yè)務(wù)人員開放數(shù)據(jù)庫查詢繞不開三個問題誰能看到哪些行、每次查詢有沒有記錄、資源消耗能不能控。Vanna 2.0 對這三點都是內(nèi)置機制而非可選插件行級安全工具層根據(jù)用戶所屬權(quán)限組自動過濾查詢結(jié)果同一張表不同人看到的行不同審計日志每個用戶的每次查詢都有獨立記錄面向合規(guī)場景按用戶配額通過生命周期鉤子在請求的關(guān)鍵節(jié)點掛檢查邏輯限流、日志、內(nèi)容過濾都走同一套擴展點。自定義能力也走明確的基類繼承Tool基類就能加新工具比如發(fā)郵件、查外部接口access_groups屬性聲明該工具的權(quán)限組框架負責(zé)校驗。LLM 調(diào)用外面還有一層 middleware 位置緩存、成本統(tǒng)計這類需求不用動 Agent 主邏輯。 覆蓋范圍模型與數(shù)據(jù)庫都是任選其一維度內(nèi)置支持LLMOpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、Mistral、Ollama、vLLM 等數(shù)據(jù)庫PostgreSQL、MySQL、SQLite、Snowflake、BigQuery、Redshift、Oracle、SQL Server、DuckDB、ClickHouse、Hive、Presto 等向量存儲Agent 記憶ChromaDB、FAISS、Milvus、Qdrant、Pinecone、Weaviate、OpenSearch、Marqo、本地內(nèi)存等服務(wù)端FastAPI、Flask 兩套路由SSE 流式端點集成代碼都在 src/vanna/integrations/ 下按廠商分目錄選型時基本不需要膠水代碼。用 Ollama 或 vLLM 跑本地模型也能接適合對數(shù)據(jù)出域敏感的場景——代價是本地小模型的 SQL 準(zhǔn)確率會明顯低于云端旗艦?zāi)Ｐ蜕厦婺墙M準(zhǔn)確率數(shù)據(jù)里弱模型的表現(xiàn)可以當(dāng)參照。?? 收尾判斷什么情況下值得引入 Vanna適合團隊需要一個能對外提供、帶權(quán)限和審計的取數(shù)入口且愿意持續(xù)沉淀問題—SQL樣本或者已有認(rèn)證體系只差一個把自然語言接進去的后端。需要先想清楚的代價準(zhǔn)確率有下限依賴——上下文檢索的樣本庫是冷啟動階段最弱的一環(huán)前期問得少時準(zhǔn)確率會貼近只給 schema那檔建議上線前用業(yè)務(wù)真實問題建一個小評測集倉庫的 src/core/evaluation/ 提供了數(shù)據(jù)集、評估器和報告的完整骨架0.x 用戶是重寫而非升級——API 從VannaBase方法變成了 Agent 工具注冊舊代碼可用LegacyVannaAdapter包一層先接上新 UI再逐步遷移具體步驟見 MIGRATION_GUIDE.md?？傇uVanna 把自然語言轉(zhuǎn) SQL從 demo 做到生產(chǎn)之間最麻煩的三段——權(quán)限過濾、流式前端、樣本閉環(huán)——都給了默認(rèn)實現(xiàn)。它不替你解決業(yè)務(wù)口徑模糊的問題但把剩下的工程部分壓縮到了幾條配置和一次樣本積累的周期?！久赓M下載鏈接】vanna Chat with your SQL database . Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval .項目地址: https://gitcode.com/GitHub_Trending/va/vanna創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考