推荐算法笔记
Created|Updated
|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-02-09
当智能体变成一份 Markdown 文档
当智能体变成一份 Markdown 文档 在传统的软件工程中,构建一个"智能体"(Agent)意味着编写大量代码:状态机、决策树、API 集成、错误处理、权限管理。而在 LLM(Large Language Model,大语言模型)时代,定义一个功能完备的 AI 智能体,可能只需要一份结构良好的 Markdown 文档。 这不是夸张。以 Claude Code 的配置体系为例,一个 .md 文件可以定义 Agent 的身份、行为约束、工具权限、专业知识、工作流程,甚至跨会话的持久记忆(Persistent Memory)。但要真正理解"为什么 Markdown 就够了",以及"如何写出高效的 Agent 定义",需要先回到第一性原理——理解 LLM 的本质、Agent 的运行机制,以及上下文窗口(Context Window)的物理约束。 本文将从底层原理出发,逐层构建对 Agentic Coding 的完整认知:先理解 LLM 是什么、Agent Loop 如何运转、上下文窗口为何是核心瓶颈;再拆解 Markdown ...

2026-04-01
Compound Engineering:当 AI 工程从"模型调优"走向"系统组合"
2024 年之前,AI 工程的核心问题是"怎么让模型更好"。2024 年之后,核心问题变成了"怎么让多个组件协作得更好"。这个转变的名字叫 Compound AI Systems,而围绕它的工程学科叫 Compound Engineering。本文从"为什么单体模型不够"出发,系统梳理复合 AI 系统的架构模式、工程实践和与其他 Engineering 概念的关系。 一个类比秒懂 Compound Engineering 在讲技术之前,先用一个类比。 想象你要建一座现代化医院: 单体模型思维就像雇一个全科天才医生,让他一个人看所有病人——内科、外科、眼科、牙科全包。他确实很聪明,但一个人的精力和专业深度终究有限。 Compound AI Systems 思维就像建一个多科室协作的医院系统:有分诊台(路由器)、各科室的专科医生(专用模型)、病历档案室(检索器)、化验室(外部工具)、会诊机制(多智能体协作)。每个组件做自己最擅长的事,通过协作协议连接在一起。 Compound Engineering 就是设计和运营这...

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-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
智能体外部记忆:文件标准现状与超越 Harness 的更广泛用途
当 AI 智能体需要跨越多个上下文窗口工作时,外部记忆是让任务可接力的核心机制。但外部记忆远不止于此——它有没有标准的文件格式?除了用在 Harness Engineering 里,还有哪些更广泛的用途?本文系统梳理外部记忆的文件标准现状、腐烂与治理挑战,以及超越 Harness 的更广泛应用场景。 外部记忆的文件标准:现状与混沌 先说结论:目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准,但已经出现了若干事实标准(de facto standards),并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难:不同的 AI 工具、不同的任务类型、不同的团队规模,对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系;一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则;一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 当前的事实标准 尽管如此,业界已经形成了几个被广泛认可的...

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 sam...


