推荐算法笔记
Created|Updated|AI
|Word Count:198|Reading Time:1mins|Post Views:
分类的话:
用户画像算法
用户画像算法、聚类算法
分类算法:
gbtd、随机森林 识别完了看哪个变量更重要。要有可解释性。
价格相关数据:体现在什么方面?一定要跟收入密切相关的。要对数据和业务的理解很重要。
分类项目:部分已知,有一部分训练集,用未知的和已知的做一个比较。打标签。寻找标签里最重要的因素。
gbtd(底层是很多决策树)。svm。dnn。可能解释性那么强。
决策树。xgbox。
输出是:分类的概率。
聚类项目:完全未知,从数据本身来发现特征。k-means。层次聚类。
输出是:不同类别的特征。
要理解商业逻辑。
Author: magicliang
Link: https://magicliang.github.io/2018/02/20/%E6%8E%A8%E8%8D%90%E7%AE%97%E6%B3%95%E7%AC%94%E8%AE%B0/
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-05-17
递归语言模型 RLM 推理范式深读
一句话结论 Recursive Language Models(RLM)不是一种新的模型架构,而是一种推理时的脚手架(inference-time scaffold):它把长 prompt 当作 REPL 环境里的一个变量,让根 LLM 通过写 Python 代码去切片、检索、并递归地把片段交给子 LLM 处理,最终再把答案聚合回来。它和 Mixture-of-Recursions(MoR)等"递归 Transformer 架构"是两类完全不同的工作,常被混淆。 来源:Alex L. Zhang、Tim Kraska、Omar Khattab,MIT CSAIL,arXiv:2512.24601(v1 2025-12-31,v3 2026-05-11);同名博文 2025-10。 问题背景:为什么"长上下文"研究让人不满意 社区里有一个"context rot"的提法,Anthropic 给出的口径是:随着上下文 token 数增长,模型从上下文中准确召回信息的能力会下降。但 RLM 论文一开篇就指出,这个口径并不完全...

2026-04-02
Claude Code 源码深度解析:五层架构与核心设计模式
全景导图 %%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#e3f2fd','primaryTextColor':'#1565c0','primaryBorderColor':'#1976d2','lineColor':'#42a5f5','secondaryColor':'#fff3e0','tertiaryColor':'#f3e5f5','fontSize':'14px'}}}%% flowchart TD A[Entrypoints 入口层] --> B[Runtime 运行时层] ...
2026-03-18
智能体记忆全景综述:从短时长时之分到向量库回归文件系统(2022-2026)
22 年以前,“LLM 应用"基本等同于"调一次 ChatComplete”。从 22 年底 ChatGPT 出来到 26 年这三年里,行业发现真正决定智能体上限的不是模型本身,而是模型周围那一圈用来承载历史、外部知识与可更新偏好的记忆系统。这篇综述沿着一条主线展开:以"信息来源"为轴的四层记忆世界观,把过去三年的代表性工作放进这四层里,并且回答一个 26 年才浮出水面的反向问题——为什么大家又在把向量数据库塞回到一个 markdown 仓库或一份 SQLite 单文件里。 一、把整片版图压成三句话 如果把过去三年关于智能体记忆的所有论文、产品和工程实践压成三句话,大致是这样: 第一,Agent 的记忆按"信息源"切是一个稳定的四层结构:训练数据(L1)、对话内数据(L2)、会话间数据(L3)、外部世界但与本会话无关的数据(L4)。每一层的写入主体不同,分别是训练管线、当前交互、Agent 自己、世界本身。围绕"是不是要再切出第五层"在 25-26 年有一些讨论,本文的判断是:Titans / ...
2026-03-23
OpenSpec 实战指南:从工作流到落地
为什么需要 OpenSpec 在 AI 编程时代,真正的难点往往不是“AI 会不会写代码”,而是“AI 能不能稳定写出你真正想要的代码”。问题往往不在模型能力,而在于需求、边界、约束和验收标准没有被稳定地表达出来。当意图没有沉淀为可复用的工程事实,AI 就只能在模糊上下文里“猜”。 OpenSpec 解决的正是这个问题。它的核心思想可以概括成一句话:先对齐规范,再生成代码(align before code)。与其把 AI 当成一个只看提示词的即时执行器,不如把它放进一套可追溯、可迭代、可沉淀的规范工作流里。 OpenSpec 既不是重量级流程平台,也不是传统瀑布式文档系统。从实践上看,它更像一套轻量的仓库内协议: 用 specs/ 保存系统当前已经成立的事实; 用 changes/ 保存本次准备引入的未来变化; 用 proposal、spec、design、tasks 把“为什么改、改成什么、怎么实现”拆开表达; 用 sync 和 archive 把一次变更逐步沉淀为下一次变更的上下文。 它的设计哲学,基本可以概括为四点: Fluid not rigid:规范是活文档,不...
2026-02-09
当智能体变成一份 Markdown 文档
归档说明:原文是一篇 2,895 行的早期综合文,把 Markdown 载体、Agent Loop、Skill、Memory、Subagent 和 Harness 放在同一条叙事中。相关内容已在 2026-07-17 拆入带事实核验日期的专题文章;本页保留原 URL,作为迁移索引。 原文提出的核心问题仍然成立:一份 Markdown 可以向 Agent 提供指令、知识和工作流,但不能独立构成完整 Agent。文件需要由 Harness 发现和装配,动作需要工具、权限与 sandbox 执行,长会话还需要 compact、外部状态和恢复合同。 内容迁移表 原文主题 当前专题 Markdown、Rules、Skills、Tools、Memory 的组件边界 AI Coding Agent 的上下文栈:组件边界与装配顺序 Agent Loop、Hook、权限、工具结果与停止条件 一次 AI Coding Agent Turn 的上下文生命周期 Skill 的发现、目录、正文加载与 compact 恢复 AI Coding Agent 的 Skill 加载机制深...
2026-03-19
子 Agent 的本质:上下文隔离与专门化
"子 Agent"这个词在多 Agent 系统的讨论中频繁出现,却鲜有人把它说清楚。它是一个能力弱化的 Agent,类似一个 Agent 化的工具?还是一个拥有更小上下文的原始 Agent,像从主 Agent fork 出来的进程?还是一个在指挥体系里听从领导 Agent、但拥有更强资源和能力的 Agent? 这三种直觉都不完全准确。本文从 Anthropic、LangChain、Claude Code 等权威来源出发,厘清子 Agent 的真实本质,并探讨一个更深层的问题:"子 Agent"究竟是能力描述,还是关系描述? 三种直觉,三种误解 在深入定义之前,先把三种常见直觉逐一检验。 误解一:子 Agent 是能力弱化的 Agent 这种直觉来自于"子"字的字面含义——子集、子系统、子进程,往往意味着更小、更弱。但 LangChain 官方文档明确指出: “An interesting aspect of this approach is that sub-agents may have the exact sa...


