构建 AI Matching Engine，无需大科技资源
Source: Dev.to
为什么匹配比看起来更难
匹配从外部看似乎很简单，但生产级别的匹配是一个 以结果为导向的系统。
LinkedIn – 一个数据丰富的案例
LinkedIn 的匹配之所以有效，是因为它从以下方面学习：
| 信号 | 描述 |
|---|---|
| 应聘 | 谁申请了哪些职位 |
| 接受率 | 哪些 offer 被接受 |
| 招聘者行为 | 招聘者如何与候选人互动 |
| 网络重叠 | 共享的联系人 |
| 互动信号 | 点击、消息等 |
| 留存数据 | 雇员的长期成功情况 |
换句话说，LinkedIn 并不是“猜测相关性”。它 从结果中学习相关性。
种子阶段的现实
Pairfect 起步时的情况是：
- 没有标注数据
- 没有行为数据
- 没有交互记录
- 没有点击率信号
- 没有嵌入图谱
- 没有 GPU
- PostgreSQL 是唯一被接受的基础设施
这是一个完全不同的世界。然而，许多早期团队试图在没有数据的情况下复制大厂的架构——这根本行不通。
真正的开始：约束，而非模型
大多数团队在开始匹配时会先问：
“我们应该使用哪种 ML 模型？”
我们则先问了另一个问题：
“哪些 约束 使得某些架构不可能实现？”
下面是我们 约束表（架构本身）的简化版。
| 约束 | 影响 |
|---|---|
| Self‑funded | 没有 GPU，也没有分布式系统 |
| Must run on Postgres | 匹配逻辑必须是 SQL‑native |
| No labels | 没有 LTR，也没有 two‑tower 训练 |
| CPU‑only | 仅轻量级 embeddings |
| MVP in 3 months | Simple > complex |
| Need explainability | 没有 black‑box ranking |
| Sparse metadata | 必须从文本中提取 |
| Minimal DevOps | 没有 vector‑DB clusters |
在我们写下任何代码之前，就已经知道自己 不能 构建什么。讽刺的是，这拯救了 Pairfect，这家自筹资金的初创公司。
定义“良好匹配”的含义（关键且常被忽视）
在你定义域中良好匹配意味着什么之前，无法进行匹配架构设计。
- LinkedIn: hired + retained
- Pairfect:
- 活动与网红之间的语义契合
- 受众期望一致
- 语调兼容性
- 价格兼容性
- 内容形式对齐
- 世界观对齐（是的，这对创作者很重要）
如果你的团队无法回答**“这里什么算是良好匹配？”**，那么关于嵌入、规则或 transformers 的讨论为时过早。
为什么我们没有直接采用 SOTA 模型
We evaluated the standard architectural options. Most didn’t survive the constraint filter:
| 选项 | 在 MVP 阶段的原因 |
|---|---|
| 仅规则 | 过于僵硬 |
| 纯嵌入 | 在没有确定性锚点的情况下噪声过大 |
| LLM 排序 | 速度太慢 + 在 CPU 上成本高 |
| 学习排序 | 需要标注数据 |
| 双塔 | 需要训练数据 + GPU |
| 协同过滤 | 需要行为数据 |
| 图模型 | 需要成熟的图结构 |
于是只剩下一个可行的类别：
混合匹配
并不是因为它“酷”，而是因为它适合当前阶段。
Source: …
架构概述：实践中的混合匹配
我们的混合流水线如下所示：
Hard Filters → One‑Hot Features → Embeddings → Fusion → Top‑K1. 硬过滤
提前剔除不可能的情况：
- 价格
- 语言
- 内容格式
- 区域
- 活动类型
SELECT *
FROM influencers
WHERE price BETWEEN 500 AND 1500
AND language = 'en'
AND region = 'eu'
AND format @> ARRAY['video']::text[];2. One‑Hot 信号
显式编码领域知识（语调、细分领域、行业、渠道、创意风格）。这可以防止出现“语义胡说”（例如，将金融品牌匹配到恶搞频道）。
SELECT influencer_id,
(CASE WHEN tone = campaign.tone THEN 1 ELSE 0 END) AS tone_match,
(CASE WHEN vertical = campaign.vertical THEN 1 ELSE 0 END) AS vertical_match
FROM influencers;3. 嵌入向量
我们为以下内容生成嵌入向量：
- 个人简介
- 标题文字
- 描述
- 大语言模型摘要
存储在 pgvector 中，使用余弦相似度进行比较。
SELECT influencer_id,
1 - (bio_embedding <=> campaign.bio_embedding) AS semantic_score
FROM influencers
ORDER BY semantic_score DESC
LIMIT 50;4. 排名融合（RRF）
RRF（Reciprocal Rank Fusion）让我们在 无需训练 的情况下将多个排名信号合并为一个稳定的排序。
公式
[ \text{Score} = \sum_i \frac{1}{k + \text{rank}_i} ]
SQL/CTE 实现（简化版）
WITH ranked AS (
SELECT influencer_id,
ROW_NUMBER() OVER (ORDER BY semantic_score DESC) AS r1,
ROW_NUMBER() OVER (ORDER BY tone_match DESC) AS r2,
ROW_NUMBER() OVER (ORDER BY vertical_match DESC) AS r3
FROM candidates
)
SELECT influencer_id,
(1.0 / (60 + r1)) +
(1.0 / (60 + r2)) +
(1.0 / (60 + r3)) AS final_score
FROM ranked
ORDER BY final_score DESC
LIMIT 10;基于 RRF 的融合优势
- 无需维护机器学习流水线
- 行为一致且可确定
- 完全可解释的评分（每个组件均可见）
- 在 CPU 上计算成本低廉
- 对噪声嵌入具有鲁棒性
要点
| ✅ 有效做法 | ❌ 无效做法 |
|---|---|
| 从 约束 开始 → 架构 | 复制大厂技术栈而没有数据 |
| 保持所有内容 SQL 本地 (Postgres + pgvector) | 依赖 GPU 密集、黑盒模型 |
| 使用 硬过滤 进行早期裁剪 | 仅使用嵌入且没有锚点 |
| 用 独热特征 编码领域知识 | 盲目信任 CPU 上的 LLM 排序 |
| 用 RRF 合并信号 → 确定性、可解释 | 无标签的学习排序 |
如果你正处于种子轮阶段并且需要 今天 就能使用的匹配引擎，请从上面的混合流水线开始。它可以从几百个扩展到数万候选人，成本低廉，并且提供投资者喜爱的可解释性。
匹配愉快！
Top‑K 输出
返回一个简短列表，而不是无限滚动。
Top 10 most compatible influencers
+ explanation layer这不是个性化；而是决策支持。
为什么所有东西都运行在 PostgreSQL 上
我们的整个匹配系统运行在：
PostgreSQL + pgvector + CPU
原因
- 基础设施应降低风险，而不是增加风险
- 一个系统 > 五个微服务
- 组件更少 = 故障更少
- 用 SQL 调试快速且确定性强
- 产品迭代 > 基础设施优化
热评: 基础设施不是工具；基础设施是一种负债——尤其在 MVP 阶段。
可解释性是功能，而非锦上添花
我们在匹配层中实现了完整的可解释性：
- 为什么会推荐这个？
- 哪些信号起了作用？
- 融合是如何给它们打分的？
- 什么情况会导致它被排除？
- 如何进行覆盖？
在早期的市场中，信任至关重要。LinkedIn 可以躲在黑箱后面，初创公司则不行。
演进路径（关键 CTO 工作）
创始人常问：
“Hybrid 能永远扩展吗？”
不会。 而且也不需要。
我们计划的演进路径：
Hybrid → Behavioral Signals → LTR → Two‑Tower → Graph → RL → Agents
每一步都会解锁下一步：
| 步骤 | 它解锁的功能 |
|---|---|
| Hybrid | Day 1 可用的匹配 |
| Behavioral Signals | 标签 |
| LTR (Learning‑to‑Rank) | 实现基于标签的排序 |
| Two‑Tower | 可扩展的编码器 |
| Graph | 多目标优化 |
| RL (Reinforcement Learning) | 个性化 |
| Agents | 推理 |
这就是 市场情报实际增长 的方式，在真实世界中。
最终教训
三条经验源自 Pairfect 的构建过程：
- Lesson 1 – 匹配不是模型问题，而是业务约束问题。
- Lesson 2 – 在 MVP 阶段，适度的复杂度才是胜出之道。过度工程会延长上市时间。
- Lesson 3 – 没有大数据就不需要大厂架构。
目标 不是 复制 LinkedIn。
目标是构建一个 对自身阶段保持诚实、能够随时演进 的系统。
如果你正在构建类似的东西
乐于讨论：
- 市场匹配
- 排名架构
- 混合系统
- pgvector 设置
- 演进路径
私信开放。