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