- 博客(825)
- 资源 (16)
- 收藏
- 关注
RSS订阅
原创 Andy系列文章序
说明博文写的面比较杂，这里做一个汇总梳理1 Python实现决策树更确切的说是「Python实现树族算法系列」。使用Python实现CART决策树，并基于此实现GBDT,Random Forest , XGBoost等模型开始页面：Python实现决策树（系列文章1）–从最简单的算法开始2 Python 函数字典系列这里指的是一种自定义的函数方法。将函数都作为某个字典可以引用的键值，然后可以使用参数化的方法调用链条比较长的函数。未来这部分会打包，以包装其他普通函数的方式来充实里面的函数。
2020-06-07 22:39:33
974
2
原创 【最后203篇系列】035 数据表同步简单方案
有一个常见的任务：将数据从事务表搬到分析表。整个过程比较长，所以是可能中断的，那就会比较麻烦：不知道在哪里断了，怎么衔接。在034里，我试着用sqlite进行简单的任务持久化，每次根据持久化结果执行任务。原理没问题，逻辑没问题。但实际执行还是出了幺蛾子：我发现有些重服务的任务执行。一方面是terminal中断导致的问题，另一方面sqlite的读写怎么会有影响？？？照理说，每次处理完我都commit状态更新，最坏的情况应该也是差一个区块。
2025-08-23 13:29:29
44
原创 【最后203篇系列】034 使用SQLite构建简单的任务管理
每次启动时，读出未处理的任务。任务里有tuple参数，根据tuple的起止区间获取数据后进行处理，如果成功就根据任务名将状态更新为2，异常则更新为3。这样每次重复执行这个就可以了，因为数据持久化在文件中，所以即使和服务器断开连接也没关系。有时候需要将一个表的数据复制到另一个表，循环是常用的方式。我希望可以比较简单的跑数，所以做一个简单的任务系统。SQLitre是嵌入式数据库，这样脚本可以不必考虑太多依赖，又可以用到数据库的持久化功能。同步任务，可以按照id分为若干区间，每个区间任务额可以称为lot。
2025-08-20 21:28:18
348
原创 【最后203篇系列】033 Mongo副本集修复过程
今天又经历了一次修复Mongo副本集的过程，我觉得得写下来。大约在3年前搭建了Mongo集群(Mongo5)，然后我使用ip代理的方式让集群的机器可以公网访问。ip代理机器一般只能租3年，所以到期就会更换，此时就会出现问题：集群的机器不能通信，访问失败首先，肯定是要登录到终端。在查询大概会是这样的:此时整个集群已经属于不可用状态, node1, node2和node3都已经失联了。
2025-08-18 23:58:55
415
1
原创 【最后203篇系列】032 OpenAI格式调用多模型实验
OpenAI比较早推出，也就基本定了大模型的一些事实标准。另外就是现在大模型，特别是国产大模型发展的比较快，可能同时要使用多个。我是希望进行比较选优的，所以能统一一个函数进行调用比较好。openai的版本用Tornado来包装一个通用对象str大模型的调用按使用上可以分为：普通-流式、字符串-json、独立调用-缓存调用。这里先锁定普通非缓存的方式，只是区分字符串和json两种输出。我分别调用了豆包、智谱和deepseek，我发现几种模型的指令遵循还是略有不同的。
2025-08-16 21:28:28
298
原创 【最后203篇系列】031 构建MCP尝试
到这里，复现先告一段落。主要还是时间原因，后面up主展开了日志追踪来分析MCP交互的过程，里面有一些方法是高于这个实验本身的，比如做一个代理的OpenAI Compatible服务。然后我又和大模型确认了一下MCP的定位，在视频中，up主也是提到目前大部分mcp都是走stdio方式通信的。应该是没有必要吧，mcp服务如果等同于脚本，起到的是和大模型交互的作用，完成工具注册和调用等功能。而重负载服务可以通过http服务进行，mcp server只要通过异步方式调用就可以了。
2025-08-10 22:59:01
603
原创 【最后203篇系列】029 基于Machinations构造回测系统
做完了之后我反思了一下，这和我之前写的程序有什么不同。仅仅是一种口味的变化，还是层次的上升？原来的代码，有一个即时手搓的，是这样的,逻辑是都在里面了，逻辑都在里面了，但是比较难看，也比较难改。这里没有什么组件设计，只是把需要的逻辑堆叠在一起。有点像直接翻过一堵矮墙，姿势比较难看，也没有什么复用性。这次做的多少有点设计感，各功能部件还是高度抽象的，这意味着调试更简单，而且不只可以用在量化，还可以用在普通的程序设计中，复用性很好。else:# 计算结果。
2025-04-20 11:18:58
894
2
原创 【最后203篇系列】028 FastAPI的后台任务处理
一个比较笨(现在有在用)的方法是在处理时将数据采样发送到kafka，然后担心kafka服务出问题，又做了try…当然，在接口中logging和redis这样的操作倒是没关系，因为时间足够短。某种程度上来说，logging+ logstash可能是更好的方案，redis都还有可能挂。CeleryWorker已经搭好了，但是我一直想在用户请求时进行额外的处理会比较影响处理时间，用这个正好可以搭配上。这样既不会影响请求时间，又可以把需要做的操作，例如在内存中记录，修改状态；实验成功，感觉还挺好的。
2025-04-19 00:08:56
386
原创 【最后203篇系列】027 基于消息队列的处理架构
这个项目下周就要交付了，挺有意思的。一方面，这是对于设计理念的实证。就一个要求很高的既要又要还要需求，我们是否可以通过良好的设计来保证实现。有些场景我已经进行了初步验证，接下来就要进行大规模检验了。另一方面，这次实现的范式应该是一种更优解，应该可以使未来的同类工作大幅简化。所有的任务都可以规约到这样的统一输入，而且入口可以是同一服务（微批次），这样就不必为每个新的任务单独开辟新的微服务。
2025-04-13 17:28:00
1036
原创 【最后203篇系列】026 FastAPI+Celery(续)
使用相同的配置文件，是因为在服务向celery_app传递信息时，需要使用一致的消息队列（redis)。最后，还应当给到一个ORM(就叫FastCelery)，使得任务的操作非常简便。,大致把我对celery的研究历史梳理了一遍，然后按照最新的方法重新包了一次，明确了其定位，使用方法。想了一下，我觉得最重要的还是不要烂尾，所以先进行使用封装，定时任务搞了好几遍了，先不花时间。当然，因为webhook是我胡编的，后台应该有一个webhook失败的日志，但可以不理会。测试之前的微服务调用任务，也是没有问题的。
2025-04-01 23:09:48
794
1
原创 【最后203篇系列】025 FastAPI+Celery
我记得后来我有看了一些工具，airflow, prefect，发现这些工具似乎背后还是celery，那我问题就不在celery，而是我的认知可能有偏差。SSE看起来是Stream的方式，这个和大模型实时返回有点像，websocket主要是用了新的协议，是可以在连接中双向交互的，适合实时对话的场景。当服务开500并发，然后就出错了，正好单个任务的时间超过了之前设定的30s，重新改60s，问题解决。callback 和 webhook，我的理解是一样的东西，实现的机制不同。看来是线程之间切换的问题。
2025-03-30 00:02:04
961
1
原创 【最后203篇系列】023 MacMini的ollama服务
以deepseek-r1-14b为例，执行效率上，m4入门级芯片的算力大约为4060ti一半，比我预想的要差一些。mac 毕竟是一台完整的电脑 ，还能执行多种功能，能耗低，无需额外散热，没噪音，体积小。对大模型来说，关键是UMA，16G相对还是便宜的，再高就要贵很多。我问了豆包，最初它的回答正确了99%，可惜大小写搞错了。我估计它的资料是更早一些的，后来的ollama变了。在mac上用ollama跑大模型也是最方便的，安装一下软件，pull一下就好了。反正之后又摸索了好一会，大约半小时到一小时，整明白了。
2025-03-23 11:50:42
312
原创 【最后203篇系列】022 用Deepseek14b提取新闻事件
这算是之前一直想做的一件事，趁周末赶快做了。业务意义：现实中有大量的舆情，这对我们的决策会有比较重要的作用。
2025-03-22 23:42:03
1044
原创 【最后203篇系列】021 Q201再计划
在找基准策略的过程也是挺戏剧的，只能说，对的东西往往都出奇的简单。基准策略的盈亏比已经显著超过了2，这是一个很有意义的数字，而且这是在一个相对比较大的统计数字下得到的，很可靠。说起来，我周末的记得开始处理一部分新闻数据了，至少先提取处罚类的数据，这两天发现还是挺有预测性的。未来的变化，是交给算法去做的，我只是定了一个基础框架而已。实际上，一个code的探索，应该有非常庞大的计算量，例如在任何时间开始回测，采取多种策略的pk。纵的部分是为了能够无差别处理大量的逻辑计算，横的部分是为了确保这些纵都是有意义的。
2025-03-21 23:33:15
503
原创 【最后203篇系列】020 rocksdb agent
我还真没想到一个专职的前端，加测试，以及其他一堆人，竟然不知道后端返回的markdown,在前端渲染成html展示后，如果字体太大，应该去改css这件事。最好的选择当然是redis，目前也是这么干的，还能直接设置一个ttl，很方便。然后我就像装一个环境来着，之前我以为rocksdb是像mysql那样，要专门起个服，后来发现是嵌入式的，类似sqlite的方式，只要pip就好了。总体上的效果还是让人满意的，每条大约是2ms-6ms的读写，有相当一部分会损耗在json序列化和反序列化上，但这也是必须的。
2025-03-21 00:00:06
573
原创 【最后203篇系列】016 Q201架构思考
Q200已经达到了我既定的目标，在最近的3个月，我需要进一步完善，达到可以试产的程度。在这个过程当中，许多知识和体会一直在变。qtv200到目前，虽然通过习惯(每晚运行离线策略和比对)方式维持了注意力的集中，但是仍然有一种睡一觉就容易忘掉的感觉。而今天在思考队列作用时，突然意识到，etl的流应该通过kafka来执行，只有通用的核心能力才需要做微服务。类似这样的灵感，然我觉得有必要在下一步实施之前重新约定整体的架构。在谈架构之前先看看业务上的要求和设计。
2025-03-15 23:40:12
1088
原创 【最后203篇系列】015 几种消息队列的思考
队列还是非常重要的中间件，可以帮助我们：提高处理效率、完成更复杂的处理流程最初，我觉得只要掌握一种消息队列就够了，现在想想挺好笑的。
2025-03-15 20:47:13
717
原创 【最后203篇系列】014 AI机器人-1
终于开张了，我觉得AI机器人是一件真正正确，具有商业价值的事。把AI机器人当成一笔生意，我如何做好这笔生意？一端是业务价值，另一端是技术支撑。如何构造高质量的内容和服务，如何确保技术的广度和深度？正好在做这件事，所以我想不太多谈技术，把核心的理念和故事串一串。为技术而技术是没有价值的，为商业价值而产品又是没有生命力的，怎么让商业背后自然衔接到技术，而技术又如何自然衍生出商业价值，这是最为关键的。
2025-03-12 22:13:07
406
原创 【最后203篇系列】011 Mongo异步代理开发回顾
出于我自身的使用特性，我较早就确定了以Mongo为主库，然后其他业务形态根据实际场景进行细分的框架。最初的时候做了一版同步版的Mongo Agent，用于代理数据库操作，后来发现在大量使用的时候数据库会承受很大压力，浪费CPU。这大概是与我最初是做数据分析、建模有关系的，在这种场景下的确是批量操作大量数据；而在应用的场景下，往往是大批量的小数据操作-- 这会占据太多数据库连接不释放，网络情况越糟，这种情况越严重。也就是说在分布式的场景下，Mongo Agent不适用，这是由于同步和异步的基本特性产生的。
2025-03-09 17:43:34
770
原创 【最后203篇系列】010 关于矩阵的一点思考
今天拿起一本矩阵的书又翻了翻，毕竟AI搞到最后还得是数学。我是感觉自己高数始终有点学的迷迷糊糊的，就打算这一年慢慢把矩阵部分扫一遍，毕竟这快肯定是实打实有用的。其他高级部分就等我发财之后再说了，哈哈。
2025-03-01 22:31:15
905
原创 【最后203篇系列】006 -使用ollama运行deepseek-r1前后端搭建
这块已经不算新内容了，年前搭完了后端（ollama)，本来想早点分享的，但是当时的openwebui有点不给力，有些地方不适配，然后配置项找不到。所以前端没搭好，也就不完整：只能通过命令行或者接口调用，可用性、体验感不强。今天看到别的文章推荐了chatbox，试了一下还是挺方便的，所以就顺带补完。
2025-02-03 20:56:35
458
原创 【最后203篇系列】004 -Smarklink
是一个非常有挑战性但也非常灵活的选择。通过 Tornado 的异步特性和强大的编程能力，你可以实现非常精细的控制，满足特定的业务需求。
2025-02-02 10:48:18
952
原创 【最后203篇系列】007 使用APS搭建本地定时任务
本次使用APS搭建本地定时任务的目的是为了简化实验性质的定时任务，通过在git项目下进行编辑任务脚本和执行任务清单，而运行容器本身会周期性的自动拉取代码，然后按照任务清单执行。执行过程采用多线程方式，任务的负载通常都不高。整体设计上，复杂和繁重的任务会包在微服务中，定时任务主要是向这些微服务发起触发动作。通常，微服务收到触发元信息后进行自动的任务/数据拉取处理，处理完毕后通过webhook将结果持久化，或进一步发起其他的触发动作。
2025-01-29 19:59:37
388
原创 【最后203篇系列】005 -QTV200 Online
借着春节休假，把这部分完工，然后2025年将正式的把量化研究的成果进行产品化输出。首先，我会将策略的执行从脚本挪到服务。做法是将策略的逻辑放在微服务里，作为一个接口，而由sniffer来触发策略执行。我想这样策略不会因为任务太多而搞丢或者搞乱。之前QTV100的代码，我已经不知道放在哪了，在运行，但是我都无法去维护。而无数个微服务，哪怕是老版的，我也可以很容易找出来。也就是从"拉"式转为"推"式。其次，使用数据库来支持策略的断点保存。
2025-01-29 16:31:24
1060
原创 【最后203篇系列】003 - 填坑DogPile
可以在set_value时指定超时时间，也可以在之后设置expire时间。然后还可以进行增量计数，这些都是redis最常用的功能。再也不用dogpile了，实在很坑。我已经懒得再去找为什么了，反正用的是set和get，我不知道为什么这样。找了很久，发现是Dogpile的问题：数据还在，但是结构变了。问题现象：一个程序获取拎一个服务的缓存时，数据格式报错。也不知道咋回事，怎么坑这么多。其实这样的工具我早就自己做了…只要再加一个命名工具就好。,再次获取缓存时结果是。
2024-12-25 22:48:32
312
原创 【最后203篇系列】001 - 2024回顾
所以在这个过程中，我的文章基本上完全是原创，也非常强调落地与工程化。在不断写作的过程中，我也得到了许多好处，教学相长的感觉。不过，万事都有个尽头，我给自己一个小目标：1000篇博客。在接下来的1~2年内，我会完成这个目标。内容，还是以我自己的体会、实践为主，如果有人觉得有用固然好，自己写写也挺享受的。
2024-12-23 22:28:16
828
原创 Python Tips6 基于数据库和钉钉机器人的通知
起因是我第一版quant程序的短信通知失效了。最初认为短信是比较即时且比较醒目的通知方式，现在看来完全不行。结论：不再采用短信方式，而是使用机器、邮件的方式通知。
2024-10-02 19:19:35
841
原创 Python 图算法系列29-大规模图关系建立-step1导入数据
将数据保存为csv形式，大致的格式如下。对于节点来说， ID和LABEL是必须的。ID可以简单理解为数据的主键，LABEL则是数据的表(Table)或集合(Collection)。对于边来说， STARD_ID、END_ID、TYPE构成了一条边，STARD_ID和END_ID是起点和终点，需要注意的是，
2024-09-23 18:33:15
808
原创 建模杂谈系列256 规则函数化改造
所以，将原来的修饰器改一改，将节点的依赖关系在启动修饰器的时候解释。函数可以在修饰器下临时定义，也可以引用已经编辑好的。现在已经具备了使用形式化参数(如。
2024-09-16 17:56:53
915
原创 Python 全栈系列271 微服务踩坑记
Tornado：更适合专注于长连接和实时通信的场景，原生支持这些特性。FastAPI：更适合快速构建高性能API，也可以支持长连接，但需要依赖底层的异步框架。
2024-09-14 00:29:53
1405
原创 Python 全栈系列269 使用ORM转移数据
继续实践ORM的使用现在看起来，选择ORM的确是更好的，它让代码看起来更清晰了，效率上也基本能够保持。
2024-09-13 00:05:18
611
原创 Python 全栈系列268 数据库浅析
数据是数据库的内容，数据库负责存储、管理和组织这些数据。数据库为数据的存储提供了结构化的环境，并使数据的访问、管理和处理变得更加高效和安全。通过数据库系统，用户可以有效地管理大量的数据，并从中提取有价值的信息，从而支持各种应用和决策过程。人与数据库的交互方式多种多样，主要通过图形化工具、SQL 查询、编程语言、REST API 和自动化脚本等方式进行。选择哪种方式取决于用户的需求、技能水平和使用的场景。SQL类数据库的好处是普及率高，使用较为简单。在处理结构化数据时效率比较高，使用起来也比较简单。
2024-09-09 18:02:52
2440
原创 Python 算法交易实验88 QTV200日常推进-关于继续前进的思考
自顶向下，自底向上过去的很多行为是自底向上的，现在则是自顶向下。过去的经验告诉我，final solution 会在这个过程中产生。两种方向的探索，会在中间的某一个部分融合，达到一个兼顾、平衡的体系。Go!Go!Go!
2024-09-08 00:03:04
1512
2
原创 Python 全栈系列267 telegraf、influxdb和grafana
Telegraf 是一个灵活且功能强大的数据收集代理，通过其丰富的插件系统，可以从各种数据源收集数据并发送到多种目标系统。它的轻量级和高性能使其成为监控、日志管理、物联网数据收集等场景中的理想选择。尤其是与 InfluxDB 结合使用时，它可以组成一个强大的时序数据收集和分析系统。Prometheus更适合实时监控和报警，尤其在云原生和微服务架构下的监控非常流行。InfluxDB则是一个通用的时序数据库，适合需要持久化、复杂分析、事件和日志处理的场景。
2024-09-05 23:40:10
2062
1
原创 建模杂谈系列252 规则的串行改并行
提到规则，还是需要看一眼RETE算法：Rete算法是一种用于高效处理基于规则的系统中的问题的算法，广泛应用于和。它的设计目的是在大量规则和数据的组合中快速找到满足特定规则条件的模式。
2024-09-05 17:22:11
422
netflix_titles.csv
2020-05-29
1 python的三种类方法
2021-01-10
DataManipulation-0.1.12.1-py3-none-any.whl
2020-07-11
DataManipulation-0.1.6-py3-none-any.whl
2020-05-24
DataManipulation-0.1.7-py3-none-any.whl
2020-05-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人