推荐算法笔记
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-05-19
Agent 全景指南:从必要性、范式演化到高可用落地
导语 Agent 在过去三年从概念走向生产,但围绕它的讨论一直分散在三个不同的层面:什么是 Agent、Agent 形态如何演化、以及如何把 Agent 真正构建成可用产品。这三个问题彼此独立又互相支撑——不理解定义就难以分辨技术争议,不理解演化就把握不到当前最佳实践,不理解落地就停留在 Demo 阶段。 本文把这三层一次梳理清楚:第 1-2 章解决"是什么、为什么",第 3-4 章解决"演化到了哪里、每个模块发生了什么变化",第 5-6 章解决"实际怎么构建一个高可用 Agent"。 第 1 章 Agent 概念与争议 1.1 Agent 的本义:代理 vs 智能体 Agent 这个词在英文语境下的原义是"代理人",但也带有"代理"的含义。国内学术界、工业界很多翻译为"智能体",强调其"智能化"和"自主决策"能力;另一派则倾向译为"代理",更贴合英文中"代理人做某件事情"的本意。 ...
2026-05-17
用 Skill 和 Agent 攻克老旧历史项目的学习与分析难题
接手一个有年头的项目,最令人头疼的从来不是代码本身,而是代码背后那些无处可查的决策脉络。文档年久失修甚至不存在,当年的设计者早已离职,模块之间的耦合关系像一团纠缠的毛线——拉一根就牵动一片。Infosys 的研究数据显示,开发者 35% 的工作时间花在理解已有系统上,而非编写新功能。ThoughtWorks 技术雷达也明确推荐用 GenAI 理解那些"低自描述性、低凝聚力"的遗留代码库。 2025-2026 年间,AI 编码工具从补全助手演变为自主 Agent,Skill 机制又让这些 Agent 的行为变得可编排、可复用、可版本控制。这两者的结合,正在从根本上改变"读懂老项目"这件事的效率天花板。 老项目学习的四重困境 Martin Fowler 团队在一篇关于 AI 辅助入职的文章中,把遗留代码库的学习困境归纳得相当准确。结合多个来源的观察,核心痛点可以归结为四类。 文档与代码的脱节。入职文档、wiki 页面、README 里描述的往往是项目建立之初的架构,经过数年迭代后与实际代码面目全非。新人按照文档理解出来的心智模型,在实际调试时...
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-03-16
QMD:本地智能文档搜索引擎完全指南
QMD:本地智能文档搜索引擎完全指南 引言:你的知识库需要一把钥匙 作为程序员、写作者或知识工作者,我们每天都在产生大量的 Markdown 文档——技术笔记、会议记录、项目文档、博客草稿……这些文档散落在不同的文件夹中,随着时间推移,它们变成了"数字废墟":你知道某篇笔记一定存在,却怎么也找不到。 传统的文件搜索工具(如 Spotlight、grep)只能基于文件名或关键词匹配,无法理解语义。而云端笔记工具(如 Notion、Obsidian)虽然提供了搜索功能,却存在数据隐私和访问限制的问题。 QMD(Query Markup Documents) 正是为了解决这个痛点而生的——一个完全本地运行的智能文档搜索引擎,它结合了 BM25 全文检索、向量语义搜索和 LLM 重排序,让你能够用自然语言快速找到任何文档中的任何内容。 一、QMD 是什么 QMD 是一个开源的 CLI 工具 + 库,由 @tobi 开发,专为 Markdown 文档设计。它的核心特性包括: 特性 说明 完全本地 所有数据和模型都在本地运行,无需联网 混合搜索 BM2...
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:规范是活文档,不...
Announcement
人生只是,守株待兔


