即刻App年轻人的同好社区
下载
App内打开
咕噜呵呵
457关注156被关注1夸夸
人是一支会思考的芦苇
AI加速中
公众号同名
Have fun👻
咕噜呵呵
2月前
咕噜呵呵
3月前
对语文题的诉求还是领先于数学题

junyu: 划一下个人关注重点： - 2025年6月，超过 70% 的 ChatGPT 对话和工作无关，而在一年前这一比例是 50% 左右。两者均增长迅速，但前者增长更快，且变化主要源于已有用户行为改变，而非引入了新的用户群体。 - 只有 4% 的对话和编程有关，相对于 Claude 而言明显偏少。当然，这里分析的是 ChatGPT 的消息，不包含其他客户端和 API 的使用。 - 和媒体报道、一般印象中对 AI 容易产生情感依赖不同，只有 2% 左右的对话是情感需求和角色扮演。 - 所有对话中，前三大对话话题（写作、实用指导、信息查询）占比超过 80%，分别为 29%、24% 和24%；在与工作有关的消息中，写作则超过 40%，其次是实用指导（24%）和信息查询（14%）。 - 实用指导中最大的子话题是「教学」，占总对话量的 10%。 - 写作中，三分之二的需求都是处理已有文本（翻译、编辑优化、总结），而非从头创作。 - 大部分对话都可以被简单归类为「问」和「做」，分别占比 52% 和 35%。 - 另外一个按任务性质的分类维度下，45% 的对话中，ChatGPT 的任务可以归为获取信息（19%）、解读信息（13%）、处理和记录信息（13%） - 从后续消息推断，14% 的对话质量不佳，56% 好评，大约为 4:1。「问」的评价较高。 - 通过名字推断，目前男女用户大约 1:1。 - 上述研究中，大部分的归类都是用 LLM 做的

00
咕噜呵呵
3月前
一直在搞这个方向，分享一些感悟
dsl 更稳定
ontology 其实 是 PLTR 的概念 更广泛的概念其实是语义层的控制和逻辑
准确率的评估偏差很大 业务人员要的是数据结果不是 sql 单纯评 sql 转得对不对
最大的问题还是预期和实现的不匹配

Roxane: 最近工作上接触了很多客户都在尝试企业内落地AI的时候，选择了数据查询作为试点场景，有些叫“Text2SQL”，有些“chatBI”，但是实际能生产落地、达到预期效果的其实不太多。 很多人对于这个看似简单的技术在实际项目中复杂度和挑战估计不足。 结合公开资料和我自己的一些经验和教训，简单整理了一下关于Text2SQL需要了解的基本知识，欢迎拍砖和交流： # 什么是Text2SQL？ Text-to-SQL的核心目标是让用户能够像与人对话一样，用自然语言提问，系统则自动将其转化为可执行的SQL查询。 # 1. 技术发展历程与主流架构 在LLM时代之前，Text-to-SQL主要依赖于规则匹配、语义解析器和深度学习模型微调等方法。随着LLM的崛起，Text-to-SQL的架构演进出以下三种主要方法： - **模型微调（Model Fine-tuning）**：通过在特定数据库Schema和SQL生成模式上训练LLM，使其适应企业内部数据。这种方法在特定场景下能达到高准确率，但资源密集，且随着Schema演变需要频繁再训练，维护成本高昂。 - **检索增强生成（Retrieval-Augmented Generation, RAG）**：在查询时动态检索相关的Schema信息和SQL示例来增强LLM的提示。RAG避免了持续模型再训练，但检索的准确性和延迟是其主要挑战，且难以保证一致性。 - **本体驱动（Structured Ontology）**：通过构建正式的语义层（Managed Semantic Objects, MSOs），形成全面的知识图谱，明确定义业务对象层次结构、关系、字段特性、计算规则和领域术语。这种方法通过显式约束和规则提供确定性行为，有效防止LLM产生不正确或无意义的SQL查询，从而缓解“幻觉”问题。 # 2. LLM带来的新挑战 尽管LLM极大地提升了Text-to-SQL的能力，但其固有的特性也带来了新的挑战： - **幻觉（Hallucinations）**：LLM可能自信地生成语法正确但语义错误或与数据不符的SQL查询，导致误导性结果。 - **大规模Schema处理**：企业数据库Schema通常庞大且复杂，包含数百甚至数千张表和列。将所有Schema信息纳入LLM的上下文窗口既不经济也不高效，容易超出Token限制。 - **用户意图理解**：用户的自然语言查询往往多样、模糊，甚至包含错别字或领域特定术语。准确理解用户意图并映射到正确的数据库实体是关键。 - **非确定性（Non-determinism）**：LLM的生成过程具有一定的随机性，即使输入相同，也可能产生不同的SQL查询，这与企业对确定性、稳定性的要求有所冲突。 - **高准确率期望**：企业对SQL查询的准确率要求极高，错误的查询可能导致错误的决策或系统中断，因此Text-to-SQL的输出必须“即插即用”。 # 二、落地中的常见“坑” 在企业实际落地Text-to-SQL项目时，除了上述技术挑战，还会遇到以下具体问题： 1. **数据质量与元数据缺失**：如果数据库中的表名、列名不规范，缺乏清晰的描述和注释，LLM将难以理解其业务含义，导致生成的SQL错误。 2. **复杂业务逻辑与领域知识**：企业内部存在大量复杂的业务规则、计算逻辑和特定术语。如果这些知识未被有效编码到系统中，LLM难以生成符合业务需求的SQL。 3. **性能与成本瓶颈**：每次调用LLM生成SQL都会产生计算资源和API调用成本。对于高并发、低延迟要求的场景，如何优化性能和控制成本是重要考量。 4. **安全与权限管理**：Text-to-SQL系统需要访问数据库Schema甚至数据。如何确保生成的SQL只执行“只读”操作，防止潜在的SQL注入风险，并与现有的权限管理系统集成，是安全性的关键。 5. **缺乏持续评估与迭代机制**：LLM并非一劳永逸的解决方案。如果缺乏有效的评估流程来捕捉错误模式、收集用户反馈并持续优化模型，系统的准确率会逐渐下降。 6. **用户接受度与信任问题**：如果系统频繁生成错误或低质量的SQL，用户将失去信任，从而放弃使用，导致项目失败。 # 三、解决方案 目前有几种比较流行且有效的改善措施，包括： 1. 加强对数据与Schema管理，比如动态发现schema、构建数据目录等。 2. 本体（Ontology）增强（指将数据库Schema转化为业务对象，并丰富其元数据，包括目的、描述、与其他对象的显式关系、字段级特性（时间、空间、分类、数值）、计算规则、派生指标和领域特定术语等）。 3. Prompt增强与多智能体的协作。 4. 微调或强化学习。 具体这里不展开，实际落地时还要综合技术的复杂度、和成本投入进行考量。 # 四、如何评估？ 最重要的、与业务目标对齐的指标是 **执行准确率（Execution Accuracy, EX）**，即模型生成的SQL在实际数据库中执行后，其查询结果与参考SQL返回结果完全相同的比例。 此外，还有一些其他可关注的指标供参考： - **精确匹配率（Exact Match, EM）**：模型生成的SQL与参考SQL在文本层面完全一致的比例。这是一个较为严格的指标，考察语法和结构。 - **表重叠率（Table Overlap）**：模型识别并使用的表与回答问题所需的正确表集合的重叠程度（0到1之间的分数）。用于评估模型选择相关Schema的能力。 - **成功运行率（Successful Run）**：生成的SQL能否成功执行，不报错。 - **有输出率（Run Has Output）**：成功运行的SQL是否返回了大于0条记录，以排除因幻觉过滤条件导致的空结果。 - **定性查询相似度（Qualitative Query Similarity）**：使用LLM评估生成的SQL与参考SQL的相似度（0到1），即使语法不同但意图相似也能被识别。 - **延迟（Latency）**：从用户输入到生成SQL的响应时间。 - **成本（Cost）**：每次查询的计算资源和API调用成本。 # 五、预期管理和思维转变 - 接受随机性，构建评估闭环：将LLM视为概率分布而非确定性函数，通过建立评估、反馈和学习的闭环，实现持续优化、提高输出一致性。 - 你的场景**真的**必须达到100%准确吗？如果答案是“yes”，必须考虑这可能并不是目前单一技术可解决的问题，思考结合实际业务场景，引入更多工程侧的设计优化。 最后，text2SQL其实也并不是数据查询和分析领域的唯一解，其他值得关注的技术之后有机会再整理。

00
咕噜呵呵
5月前
咕噜呵呵
6月前

-大雨-: 今天和客户在办公室，聊AI编程的落地。 技术上没问题，模型能生成代码，插件能帮你写测试，Deepseek。cursor已经能代替很多程序员完成很多日常工作。 但客户一句话就把我们拉回现实： “现在还不太行。” 不是AI不行，是企业组织结构还在“手工时代”。 企业不是缺AI，而是缺“可被管理的AI” 客户提了两个核心诉求： 1. 统计AI使用率：谁在用？用了多少？用得比别的团队多吗？ 2. 分析代码采纳率：AI写了多少行？最终团队采纳了多少？有没有提效，能不能写进OKR？ 这背后的逻辑非常清晰： AI，不是用来提效的，是用来汇报“我们也在用AI”的。 这不是个笑话，这是企业治理现实。 AI提效 ≠ AI落地 企业落地AI的第一性原理，从来不是“技术能力”，而是“可控性”。 你部门可以不提效，但必须可统计、可分析、可审计、可打分。 如果AI的使用没有被纳入管理体系——那它就像个“自由职业者”，看着很强，但不能进年终绩效表。 而一旦纳入体系，它就成了“工具”，需要数据闭环、责任归属、横向对比、纵向趋势——否则无法监管。 所以本质上，AI落地不是科技问题，是生产关系的改造成本问题。 这就是生产力与生产关系的典型错位： • AI技术（生产力）快速演进，工具层出不穷 • 企业制度（生产关系）仍在用旧有框架打分考核 技术飞跃的不是人，而是工具。 人还被框在原有的绩效体系里，必须用KPI证明AI“有用”，才能真正“落地”。 AI真正的门槛，不在模型、不在工具，而在组织： 一个组织是否准备好接受“非人的能力”？ 是否准备好打破原有的绩效与责任链条？ 这才是今天客户来找我们的真正原因—— 不是为了用得更聪明的AI， 而是为了让AI“更好地被管起来”。 ⸻ 对此，你咋看，欢迎留言表达你的看法

00
咕噜呵呵
7月前
Mark Mermaid 的格式还是能解很多的，excalidraw 的文字转图表也可以期待下

计算机低手: 告别手动绘图！基于AI的Smart Mermaid自动可视化图表工具搭建与使用指南 https://blog.luler.top/d/47

00
咕噜呵呵
7月前
确实好用 感觉背后的 FeedAgent 好像更 6

瓦恁:

00
咕噜呵呵
8月前
咕噜呵呵
8月前
咕噜呵呵
8月前