最近几年，有两件事情让做技术的人价值呈现几何倍的增长：移动互联网时代崛起。那个时候人人似乎都想做APP开发，因为来钱快，也迎来了个人开发者的一个黄金期。大数据的崛起。如果说移动互联网让开发者可能成为Hero,一个人就能搞定并且赚到钱，那么大数据则是集团军，需要强劲的后勤和协同作战，才能深入数据腹地，获得价值输出。因为是集团军，所以对人才的要求极大，也...

本分析突出了数据连接、查询生成、数据访问和报告编辑能力的局限性。随着查询复杂性的增加（例如，需要生成数百或数千行的 SQL 查询），MCP 生成的 SQL 语法和逻辑的错误率可能会急剧上升。产品演示，包括伴随的演示文稿，似乎主要集中在报告的自动创建上，对生成后微调和定制这些报告的能力关注甚少。InfiniSynapse 作为更加专业的AI辅助数据分析工具，没有前面说到的各种限制，对于普通给用户上手

InfiniSynapse 可以把藏匿在文档中的小二维表格和实际的业务结构化数据做联合分析，实现了一种真正意义的“数据挖掘”，极大的扩大了数据的提取质量。InfiniSynapse 可以把藏匿在文档中的小二维表格和实际的业务结构化数据做联合分析，实现了一种真正意义的“数据挖掘”，极大的扩大了数据的提取质量。注意，这里我们的是通过SQL做计算的，而不是AI自己做的计算，所以准确度有保障，绕过AI不太

InfiniSynapse 通过表单和自然语言的自然转化，能够让用户很好的复用自己的prompt, 同时也能更加直观清晰的使用填写表单的方式来完成输入。分析师可以写非常辅助的prompt,然后作为表单分享给运营，实现InfiniSynapse 小数据App 的雏形。而表单只关注核心输入，可以有效的规范输入和减少输入信息，并且有更好的提示能力。表单是传统交互方式中输入最重要的一种模式（表格则是输出高

比如用户的很多问题是需要一定推理的，比如A和B谁大，你直接做去问RAG，RAG可能无法回答。现在可以直接在cherry studio里问问题了，我询问了一个auto-coder自身，该项目已经开发了一年多，具备一定的复杂度，且RAG只是里面部分比较小功能，我们看是否能够大海捞针，准确的回答用户。LLM-Native 的最大特点就是抛弃 embedding/rerank 体系，只依赖大模型完成召回，

4. 就最简单的生成SQL做法也是针对不同数据源生成不同类型的SQL，而大模型往往会错乱，比如把msyql的function当成hive的function去使用，而SQL自身的复杂度也导致计算大模型能准确的理解需求，能准确的找到合适的表，但是生成复杂SQL的成功率也极低。但是现在，随着AI辅助编程技术的发展，数据分析也终于可以落地了。和RAG知识库一样，之前的人的都做的稀烂，因为他们还是把AI的东

这个话题是我最近一直在思考的，不一定成熟，这篇文章权做笔记前言大数据部门的常见能力如下：报表统计算力/存储输出推荐/搜索/精准营销等传统产品形态通常，大数据部门会花费很大的力气构建数据平台，而这个数据平台除了能让研发，算法，分析师等角色爽一些，从宏观角度很大的节省部门人力成本，提高效率以外，似乎对公司/其他业务部门并无一个直接的输出。这...

后续RAG公司没有从根本上去解决这个问题，而是不断的在其上打补丁比如，加入实体图搜索，在数据预处理上进行大量场景定制，在召回策略上也要进行场景定制。这代其实RAG受限于当时的技术条件而诞生的一个技术，那个时候大模型窗口普遍4-8k，并发少，速度慢，模型效果也一般，所以只能采用传统技术来做召回，并且采用小模型(rerank)来做排序。随着大模型技术的发展，我们推出了第二代 RAG , 该RAG核心是

而 Agents 则是根据当前项目状态，选择合适的agent 完成工作，然后只做review ，比如如果需要修改文件，他会调用 /coding 工具，并且用文字，二次阐述要做什么，/coding Agent 会根据他的描述，实现具体的需求。可以看到，基本调用一次工具，就是发起一次新的请求，再流式解析和调用，这样相当于把当前的现状（修改结果），大模型重新进行了获取，从而能够指导接下来如何做决策。我们

今天一大早就看到了一篇文章，叫【大数据对于运维的意义】。该文章基本上是从三个层面阐述的：工程数据，譬如工单数量，SLA可用性，基础资源，故障率，报警统计业务数据，譬如业务DashBoard,Trace调用链，业务拓扑切换，业务指标，业务基准数据，业务日志挖掘数据可视化当然，这篇文章谈的是运维都有哪些数据，哪些指标，以及数据呈现。并没有谈及如何和...