Master of Science in Computer Science, University of Nottingham.
Nothing here yet.
Feb 3 · 4 min read · 这篇文章记录我在 Taste Aligner 项目中实现 Recommendation Service v1.3 的全过程： 为什么要做“舒适区 / 探索区”双区推荐？ 为什么必须拆成 Recall→Rerank？ 如何让推荐“可解释、可控、可验证、Agent 友好”？ 以及：我遇到的 2 个最难 bug（CZ 跨城污染、tags=[] 导致 EZ 消失）是怎么一步步修掉的。 0. 背景：Recommendation 在 Taste Aligner 里负责什么？ Taste Al...
Join discussionFeb 3 · 2 min read · 这篇文章记录的是 Taste‑Aligner 项目中最后一个核心模块：Planner（规划器）。在整个系统中，它并不负责“算分”，也不直接生成自然语言，而是承担一个非常工程化、却常常被忽略的角色——把模型结果转化为稳定、可控、可解释的决策结构。 一、为什么一定要单独做 Planner 很多推荐或 RAG 系统，在工程早期都会省略 Planner 这一层： 检索 → 排序 → 直接交给 LLM 生成回答 这种做法在 Demo 阶段足够，但一旦系统开始变复杂，问题会迅速显现： 结果不可控： ...
Join discussionJan 31 · 5 min read · 目标：把 Ontology（标签本体）→ Vision（标签提取）→ Embedding（TES 向量生成） 这条“可验证的最小链路”完整记录下来，作为博客发布与后续迭代留档。 范围：本篇只覆盖 V1（可预测、可回放、可验收） 的工程实现；不讨论完整业务（Recommendation / Planner / UI），也不讨论 Vision 的真实大模型接入（留给 V2）。 0. 当前项目结构与约定 0.1 仓库关键目录 gateway/：Java Gateway（统一入口、显式路由、Fea...
Join discussionJan 31 · 2 min read · 本文记录了我在 Taste Aligner 项目中设计与实现 Memory Service v1.3 的全过程。这不是一个“存 JSON + 查向量”的模块，而是一个长期品味建模（Long-term Taste Modeling）系统：它试图回答一个更难的问题——过去的体验，应该以多大的权重影响当下的推荐？ 1. 为什么需要 Memory，而不是只有 Embedding？ 在很多推荐或 RAG 系统中，Embedding 往往被当作终点： 把文本 / 图片变成向量 用 cosine si...
Join discussionJan 28 · 3 min read · Taste-Aligner Gateway工程设计 1.背景与定位 Gateway 是 Taste Aligner 系统的**核心控制平面（Control Plane）**，负责统一管理 Agent 对所有后端工具（Tool/ 微服务）的访问。 在第一设计阶段，Gateway 仅承担**简单转发**职责； 在第二设计阶段，Gateway 升级为具备**服务治理能力**的系统中枢。 设计目标： 解耦 Agent 与微服务实现 提供稳定、可观测、可降级的工具调用层 支持从 dummy → r...
Join discussion