<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>技术笔记 - 分类 - Shaoyang 的个人主页</title><link>https://xueshaoyang.cn/categories/%E6%8A%80%E6%9C%AF%E7%AC%94%E8%AE%B0/</link><description>技术笔记 - 分类 - Shaoyang 的个人主页</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Thu, 16 Jul 2026 12:00:00 +0800</lastBuildDate><atom:link href="https://xueshaoyang.cn/categories/%E6%8A%80%E6%9C%AF%E7%AC%94%E8%AE%B0/" rel="self" type="application/rss+xml"/><item><title>从指标知识库到对话式分析平台：一个 Agent WebUI 的设计与实践</title><link>https://xueshaoyang.cn/posts/agentic-data-analysis-webui/</link><pubDate>Thu, 16 Jul 2026 12:00:00 +0800</pubDate><author>XueShaoyang</author><guid>https://xueshaoyang.cn/posts/agentic-data-analysis-webui/</guid><description><![CDATA[<p>很多 AI 数据分析项目最先做出来的是一个聊天框：用户输入问题，模型返回一段 SQL，看起来已经完成了从自然语言到数据查询的跨越。</p>
<p>但真正把它交给分析师使用后，很快会遇到另一组问题：这段 SQL 参考了哪套口径？Agent 正在检索还是卡住了？刷新页面后任务还在不在？查询结果放在哪里？同一个问题下周能否接着分析？</p>
<p>这篇文章分享我在一个指标知识库项目中构建 WebUI 的过程。它不是给大模型套一层聊天界面，而是尝试把<strong>知识检索、Agent 执行、SQL 生成、查询结果、图表和分析报告</strong>组织成一条可追溯的工作流。</p>
<p>全文已对业务名称、指标、表名、编码和内部平台信息做泛化处理，重点讨论可复用的架构思路与工程取舍。</p>]]></description></item><item><title>text-to-SQL 的 RAG 实践：检索路由 + 权威源精读</title><link>https://xueshaoyang.cn/posts/local-text-to-sql-rag/</link><pubDate>Fri, 03 Jul 2026 12:00:00 +0800</pubDate><author>XueShaoyang</author><guid>https://xueshaoyang.cn/posts/local-text-to-sql-rag/</guid><description><![CDATA[<p>数分团队做 text-to-SQL，最常见的失败模式不是「SQL 语法写错」，而是<strong>看起来很像真的</strong>——表名对了一半、过滤条件漏了、业务编码用错了版本，跑出来的数字和口径完全对不上。</p>
<p>这篇文章分享一套我在实际项目中落地的方案：<strong>用本地混合检索做路由，用标准 SQL 全文做生成依据</strong>，而不是把文档 chunk 丢给 LLM 自由发挥。全文数据已脱敏，业务域、表名、编码 ID 均为虚构占位。</p>]]></description></item></channel></rss>