所有文章 - Shaoyang 的个人主页https://xueshaoyang.cn/posts/所有文章 | Shaoyang 的个人主页Hugo -- gohugo.iozh-cnThu, 16 Jul 2026 12:00:00 +0800从指标知识库到对话式分析平台：一个 Agent WebUI 的设计与实践https://xueshaoyang.cn/posts/agentic-data-analysis-webui/Thu, 16 Jul 2026 12:00:00 +0800XueShaoyanghttps://xueshaoyang.cn/posts/agentic-data-analysis-webui/很多 AI 数据分析项目最先做出来的是一个聊天框：用户输入问题，模型返回一段 SQL，看起来已经完成了从自然语言到数据查询的跨越。

但真正把它交给分析师使用后，很快会遇到另一组问题：这段 SQL 参考了哪套口径？Agent 正在检索还是卡住了？刷新页面后任务还在不在？查询结果放在哪里？同一个问题下周能否接着分析？

这篇文章分享我在一个指标知识库项目中构建 WebUI 的过程。它不是给大模型套一层聊天界面，而是尝试把知识检索、Agent 执行、SQL 生成、查询结果、图表和分析报告组织成一条可追溯的工作流。

全文已对业务名称、指标、表名、编码和内部平台信息做泛化处理，重点讨论可复用的架构思路与工程取舍。

]]>text-to-SQL 的 RAG 实践：检索路由 + 权威源精读https://xueshaoyang.cn/posts/local-text-to-sql-rag/Fri, 03 Jul 2026 12:00:00 +0800XueShaoyanghttps://xueshaoyang.cn/posts/local-text-to-sql-rag/数分团队做 text-to-SQL，最常见的失败模式不是「SQL 语法写错」，而是看起来很像真的——表名对了一半、过滤条件漏了、业务编码用错了版本，跑出来的数字和口径完全对不上。

这篇文章分享一套我在实际项目中落地的方案：用本地混合检索做路由，用标准 SQL 全文做生成依据，而不是把文档 chunk 丢给 LLM 自由发挥。全文数据已脱敏，业务域、表名、编码 ID 均为虚构占位。

]]>歪瓜裂枣https://xueshaoyang.cn/posts/waigua-liezao/Sun, 31 Aug 2025 18:00:00 +0800XueShaoyanghttps://xueshaoyang.cn/posts/waigua-liezao/

Climb Date: 2025/08/31 · Distance: 246m · Grade: 5.10c · Pitches: 9 · Type: Sports · Field: 白河

1. 基本信息

  • 线路名称：歪瓜裂枣

  • 岩场位置：北京密云白河峡谷

  • 攀登日期：2025-08-31

  • 队伍成员：

    • 一组：xsy, 柚子
    • 二组：799，思想

  • 天气状况：☀️晴, 气温 18~30℃，风力 南风2 级

  • 线路信息：5.10c 246m 9Pitches （以下信息来自北京多段线路指南20241021版PDF)

    🧗🏻

    线路分段信息

    Pitch1：24m / 5.7 / 4Bolts Pitch2：32m / 5.10b / 12Bolts Pitch3：28m / 5.10c / 11Bolts Pitch4：24m / 5.9 / 7Bolts Pitch5：32m / 5.10c / 12Bolts Pitch6：33m / 5.10a / 13Bolts Pitch7：24m / 5.9 / 8Bolts Pitch8：25m / 5.9 / 8Bolts Pitch9：25m / 5.10a / 10Bolts

]]>