yukai08008的博客

所以，将原来的修饰器改一改，将节点的依赖关系在启动修饰器的时候解释。函数可以在修饰器下临时定义，也可以引用已经编辑好的。现在已经具备了使用形式化参数(如。

提到规则，还是需要看一眼RETE算法：Rete算法是一种用于高效处理基于规则的系统中的问题的算法，广泛应用于和。它的设计目的是在大量规则和数据的组合中快速找到满足特定规则条件的模式。

首先假设数据由多个正态分布叠加而成，这个场景应该也是比较有普遍意义的。

pymc算是多年的老朋友了，中间失联了好几年。

从分布开始，分布又要从正态开始假设有一批数据，只有通过在线的方式增量获得。

实体识别的数据标注方式和传统的机器学习0/1标注的方法差别比较大，一般采用标注工具,如LabelStudio来对原始数据进行打标，然后转换为标准的可训练模式；模型训练后，对数据进行预测，结果仍然需要重新转为LabelStudio的格式，方便检查。LS在过程中起到的作用非常大，有许多高级功能值得探索和学习。以下是我快速看了一遍之后的总结理解label studio1 general5 webhooks回到本篇的内容：解决pydantic与实体识别模型之间的关联。

如果说微服务化(API接口、Web页面、Docker镜像)是架构方面的基准，那么数据模型就是逻辑处理方面的基准。

所有的基于时间处理和运行的程序将以同样的节奏同步和执行TT(TimeTraveller)是一个新的设计，它最初会服务与量化过程的大量任务管理：分散开发、协同运行。但是很显然，TT的功能将远不止于此，它将服务大量的，基于时间游走特性的各种任务。

梳理一下tf-idf的全过程，然后用于实际的需求中。

说明简单就是美说起来这个项目很早之前做过，最近用到，再梳理一次。（完成后并按PM方式梳理）内容1 TF-IDF来自百度的解释：TF-IDF是一种统计方法，用以评估一字词对于一个文件集或一个语料库中的其中一份文件的重要程度。字词的重要性随着它在文件中出现的次数成正比增加，但同时会随着它在语料库中出现的频率成反比下降。概念：1 语料 corpus： 或者说文件集2 文档 document： 或者说一篇文章3 词频 TF(Term Frequency):TF表示词条在文档d中出现的频率

AI其实是一个很有意思的名词，在很多介绍人工智能的书里都有提到，这也是大众最能接受的一种说法。所以这里不过多的去纠结严格的学术定义，而是以一种稍微工程化的语言来明确这里提到AI的定义，也是我最接受的一种说法。AI就是脑力劳动自动化AI = 人工智能 = 先人工，再智能要研究自动化，显然是按照人工的方法一步步分解，然后再把他们抽象成一个个步骤，最后串起来。其实看看transformers,最后变的很好用的一瞬间也就是pipeline(流水线）的应用。

清晰化这部分的好处是体现在代码之前的。能够设定目标问题的状态及其变化，首先就需要思考及明确其中的关键因素，而这些可能是在开始时没有想好的。例如，有哪些状态是基本的，有哪些是对业务有帮助的。在整个运行过程中，可能会有哪些变化(事件)，这些事件又会如何转变当前实例的状态。以及，有哪些不合法的事件：在状态A下不可能发生某些事件。在代码的运行过程中，每次的执行，总是能够被简单且清晰的记录下来。即便在事后，也可以很容易的通过这些状态记录，对问题进行快速的分析。结构化在定义了状态之后，很显然就会对方法进行区分。

通常在建模和生产应用环节会存在脱节问题，这意味着：建模通常是通过一次性获得数据，计算后形成模型文件使用，后续即使生产上产生了较为重要的更新，但模型却不太会做更新。这类问题应该还是比较普遍的，所以过去我通常会选择一些相对稳定的模型方法，减少因为数据脱节导致的性能下降/不足等问题。有一些算法天生是会根据数据的跟新进行迭代的，例如强化学习类算法，但是这部分目前的比例还不大；还有就是贝叶斯方法，因为贝叶斯公式的原因，这些算法也会，甚至很容易随着数据的增加而更新。

推荐是很重要的一块内容，丢下有点久了。计划先快速恢复一部分基础内容，然后再和产品改进结合，丰富这块的内容。

很久没有写了，总是写一半就没空往下写。这次正好有个单独的主题，可以写一下。

首先重复这么一个过程是正确的，因为中间的过程环节点太多了。我甚至发现了一块丢失的代码，最后也没法补回。然后从头到尾，进行实现的同时记录日志，在下一次重复的时候可以做的很快。过程中我发现第一次的确做的非常粗糙，一如既往。所以接下来需要继续重复，提炼。发现的问题反而是业务层面的，我发现新标的的袋外表现明显弱了，不知道是什么问题。既有可能是数据问题（规模过小），也可能是模型问题（但是我做了结构退化，也没改善），当然也有可能是标的本身的问题。1 迅速再横向的扩大标的实验范围，规模大优先。

简单归纳一下最近的学习型对象封装，做一个基类，之后可以基于这个基类继续迭代。

我将之前的实体模型做了对象化转换，整体流程都是沿用之前的，不过在应用上做了封装，正好最近也需要使用，感觉的确是很方便。原始数据这样通过Data对象将数据转为模型可接受的模式然后是模型的训练使用起来也是超方便的总体上，模型经过封装后无论是训练还是应用都变得非常简单。大部分transformers的模型也是这样的。不过最近调研下来，当初BERT和GPT的路子大家都选错了，我这种随大流的（之前深度学习和神经网络并不是我的重点）也错了。对于时间和资源极其有限又希望能直接产出角度来看，应该选GPT的。

鲁迅说：我家门前门前有两棵树，一棵是枣树，另一棵也是枣树。从编程语言的角度，可以分为两大类（面向过程或面向对象），可以参考文章的内容其实不多，我贴一下：对于两者的比较，文章这么说：我觉得首先从形态上看，最早的语言都是流程式的，例如PASCAL这些。后来，无论是C++, Java还是Python这些主流语言都走向了对象的方式。之所以写这篇文章，是因为我发现我总是喜欢流程化的方式（用Python也一样可以流程化），所以我想稍微剖析一下原因，给一个结论，以及未来的调整方法。

一个项目结束了，趁这两三天在休息，把本次的收获和教训都盘点一下，然后再开始一个更刺激的项目。

整体上，我觉得强化学习很好玩，和打游戏简直一毛一样。这次是一个快速探索的实验，到这里就结束了，原理性验证通过，还是挺满意的。

开卷还是有益的，要坚持多读书。刚刚在飞机上刷完一本书，略有感。

总的说起来，很多正确的废话。然后又有不少胡话，真的是“入门与实践”，这点没乱说。我是觉得有些基础观念可以说的更多一些，例子更专注一些，把道理讲透。说了几十个例子，不如把一个例子好好说。另外读者自己倒也要有所甄别，有些技术你硬要用不是不可以，但肯定是很傻的。批判的眼光可能过于严厉了一些，开卷还是有益的，只要有对比，不管是好坏都对于更深刻的理解一些道理，确保事情做对做好是有正向帮助的。

这应该是进一步的完善ADBS的工作模式。之所以做A系列的架构工具，就是为了可以实现大型的数据处理、存储。从应用上说，是为了提高效率，并达到超高的效果。为了达到这个目的，就必须从数据架构上、任务调度上、逻辑架构上作出好的设计，并将之实现。逻辑架构主要对应的就是Core的设计，目前初步的实现了ETL，模型的还没有去实现，但有了Core和ETL的经验，那么模型只是另一种形态和时间问题。但无论如何，数据架构一定是所有应用的基础，所以第一步也就是实现了数据架构。

时长：两小时1 人工智能的本质：自动化，更高层次的自动化。识别图：产线质检的自动化对话：客服工作的自动化内容创作：文字、音乐、图片、（影视）虚拟员工、虚拟艺人2 强弱人工智能之分：Chat算强人工智能吗？3 感知与推理智能4 算法、算力及存储、数据的发展5 国家政策与民间趋势6 AI在各行业中的价值7 AI的分支与技术8 AI在银行的应用场景9 Plus: 人工智能相关的架构浅析 ~ 大数据量、大运算量、复杂系统的构建分布式分布式是什么。

这次事情的触发是因为之前做的一个服务出了故障，然后我进行修复时产生了一些感想。写这篇文章的目的是回顾对比，从而不断的改进设计。

本篇粗略的讨论了为什么要进行变量衍生、变量衍生的目标，变量衍生的作用与局限，下一篇继续讨论变量衍生的具体执行方法。

上一次已经快速探查了数据，为数据做了数据字典以及基础的转换，并将数据分为了训练和测试。现在就假定我们只有训练，然后开始进行更深入的建模步骤。

基于样例数据，构建一个建模的粗略过程。以下假定是对于表格数据的建模。

开发项目最终就是要完成一系列的功能，这些功能是由底层通用的服务、函数包来提供的。没有数据就没有办法很好的开展后续的工作，而在现实项目中，的确不是那么容易就拿到数据的。以下讨论如何在没有数据的情况下，构建完整的项目代码。目的是搭建可以持续分析，且容易复用的函数包，这样以后只需要拿到数据就可以立即完成。

本次粗略的计划了一下本次建模的概览信息，把一些要点罗列出来。1 w1、w2周完成一次基础宽表的处理 | 同步按照标准化方法构建数据2 w3 完成基础模型的构建3 w4 完成文档、分析和标准化改造 | 同步完成自动化文档4 w5 强化模型开发 | 同步完成特征构造方法5 w6 组合模型 | 同步开始遗传算法开发6 w7 整体打包封装 | 同步完成遗传算法开发7 w8 开始使用新的模式重新构建所有模型8 w9~w12 将相关程序改造为 2.0。

春节这段时间就完全没干活，偶尔空下来会想一想要做的事。过去的想法和实验都比较分散，现在正是要慢慢的聚拢，归类，各司其职。

为了维护大的任务，或者长效的任务，必须考虑任务模式。从整个体系的设计上，与是分开的。目前任务的执行已经做的还行，无论是Kettle还是APIFunc，都运行的很稳。一条记录对应着一个处理批次，一般来说批次的数据条数是1千或1万，通常来说从效率和可执行性上来看，都是比较合适的。

结论1：从实验上看，设想是成立的，可以将若干个矩阵并在一起同时计算结论2：下一步应该进行仿真的大批量测试，才能证明这种并行的方式的确在量级上由于逐个计算。

最近越发觉得不需要埋头干，白天比较适合做形而下的事，晚上就思考一些形而上的东西。节奏和结构更重要。

今天正好是元旦，所以对过去一年的事做一个总结，然后展望一下2023。

1 通过链调用链的方式，可以实现分步的开发和复用2 后续通过Web进行开始时，还有一些关于组装的问题(如何生成需要的链的py文件，并在新的链py文件中进行导入）3 前一个链，要注意传入的变量()有哪些，新的链要声明现有的gs_id和需要的导出的规则()4 在列函数中，大部分都是在做映射，所以这是一类特殊的列函数（可以认为是基于模板的列函数)

围绕APIFunc继续推进工具化的研究在存储框架方面目前已经有了一些进展，至少流程上是完整的。观念：只要把APIFunc搞好，足够达到这一个阶段的目标习惯：将相关设计、工程文档打印出来，反复阅读，修改。此外暂时冻结体系类的创新项目，并将主要精力投入在APIFunc的完整生态实现上。有零散时间可以做短平快的创新，这相当于是做一些埋点，或者是准备，因为APIFunc最终(半年内?)会成型 ，而创新是永恒的主题，也很有趣。

有多快呢？我觉得如果是ETL的话，那么速度有可能达到5倍。

要解决复杂的问题，应当基于简单的结构。真理应该是可以瞬间被理解的，我们可以从其他领域进行迁移学习。目前我计划使用前端编辑器替代本地编辑器，其中很重要的一部分就是调试。当开发者在前端觉得新的编辑完成时会提交后台进行测试，有时候会成功，但更多时候会失败/出错。如果做一个比喻，一个个的函数相当于是一颗颗「沙子」，我们在调试的时候不知道是不是做好了，所以调试一次就会“扔”一次，而FuncDict就是这个扔的载体。从一个机器的角度看，FuncDict总是Load New Bullet, 然后试着发射 Fire， 然后