混合检索 + 重排序
RAG 系统的检索契约
你的检索在演示里没问题，一遇到真实用户查询就失灵。精确率下滑、无关结果冒头，在杂乱的非结构化输入下答案质量不断退化。
混合检索（pgvector + BM25）加重排序，端到端全程可观测。专为“能检索的演示”与“扛得住接下来一万次查询的系统”之间的鸿沟而建。
- LangGraph
- pgvector
- FastAPI
//first contact · session 0x----
01
INGESTsource
02
EMBEDvector
03
RETRIEVEpgvector
04
RERANKcohere
05
GENERATEclaude
06
EVALdeterministic
07
SHIPprod
git · main · live
$git log --oneline --since=2d
9f2a3c1 feat(rag): hybrid retrieval + cohere rerank · 4h ago
8e1b2af refactor(eval): split harness into stages · 6h ago
4d2cdf9 feat(agent): add approval gate retry · 1d ago
已部署0覆盖 6 个系统
已接入监控 · 实时0/ 10↑ NexusRAG 活跃
p95 检索延迟0ms−18% / 周
// trace 01 即本次页面加载 · 下方每个系统都沿用同一条主线
下滑 · 核心能力
//核心能力
四条生产管线。
全部交付，公开仓库可查。
每一行是一项工程能力，右侧图示就是该系统在生产中的运行方式。每一行都链接到源码仓库，适用时还有线上部署。第一次通话之前，就能读到源码。
状态图 + 审批闸门
LLM 智能体基础设施
你的智能体在演示路径上正常，用户一偏离就崩。步骤之间状态丢失、工具调用悄悄失败，事后完全无从审计。
基于 LangGraph 的多步智能体工作流：持久化状态、工具编排、审批闸门、重试逻辑与确定性评测。为真实交互模式下的可靠性而设计。
- LangGraph
- Claude API
- Celery
请求延迟瀑布图
面向 AI 产品的 FastAPI 后端
你的 AI 功能需要真正的后端，而不是包了个接口的 notebook。异步 API、结构化数据访问、迁移纪律和部署自动化，从第一天就得就位。
为 LLM 应用量身构建的异步 FastAPI 后端。pgvector、Alembic 迁移、健康检查，第一天就具备运维就绪度。
- FastAPI
- PostgreSQL
- Docker
回归检测 · 12 次运行
AI 可靠性工程
评测纪律还没建立，提示词就已经在扩张。质量靠肉眼看输出，成本与延迟没人度量。生产一旦出问题，根本说不清是什么变了。
确定性评测框架、结构化输出校验、成本与延迟可观测性、回归检测。这是大多数团队在原型与生产之间跳过的那一层。
- Python
- pytest
- Prometheus
//作品集 · 1 个旗舰 + 5 个系统
六个系统。
一个挑大梁。
下方每一帧都是真实系统，截取自各自的线上部署。一个在生产环境运行，三个跑着公开基准评测，两个是坦诚的演示。六个全部开源、此刻都在运行。点开任何一帧，用真实的系统。
旗舰 · 生产
NexusRAG
多租户 RAG 平台
多租户、多云的 RAG 平台：SSO、SCIM、RBAC/ABAC、信封加密、多地域故障切换与 SOC 2 自动化。其余每个仓库都指向的那个已交付参考实现。
connecting to live endpoint…/api/stats
// 支援舰队 · 每一帧都是正在运行的系统
Data Watchtower基准评测阅读成果
EvalOps基准评测阅读成果
Revenue Signal基准评测阅读成果
Agent Runbook演示源码
Repo RAG Debugger演示源码
// 截取自线上部署 · June 2026 · 按阶段查看全部系统
//客户
我们为谁而建，
交付形态是什么样。
三种合作画像。每一种都从一个可度量的问题开始，以部署在你仓库里的代码收尾，并连同评测框架、可观测性与交付文档一并移交。
FOR ·01
正在走出原型阶段的初创公司
AI 功能已经演示过了。团队现在需要的是不会崩的检索、能捕捉回归的评测框架，以及 iOS 工程师真正能调用的 API。
// 合作方式4 周交付 · 线上 API · 完整移交
FOR ·02
交付 AI 产品的代理公司
你们负责前端与品牌，我们在底层交付 AI 后端：RAG、智能体、评测。上线前我们退场，源码留在你客户的仓库里。
// 合作方式嵌入团队 · 交付上线 · 移交所有权
FOR ·03
评估 AI 能力的团队
你在考虑一笔 AI 投入，需要一套可运行的参考架构、一次基于真实数据的评测，以及生产级可靠性到底要花多少钱的确切数字。
// 合作方式2 周试点 · 基准评测 · 去留决策
//方法
五个阶段，
一次交付提交。
每次合作都走同一套流程。调研阶段确定规格与评测达标线，随后四个阶段照此构建与交付。周期可按周调整，顺序不变。
W1 · 第 1 天W2 · 第 6 天W3 · 第 11 天W4 · 第 16 天持续 · 第 21 天起
阶段 01 / 05 · 规格说明
调研
第 1–5 天 · 5 个工作日我们从需求简报出发，撰写系统规格说明、确定评测达标线，并在任何代码交付之前把所有风险摆上台面。这份规格说明就是后续每个阶段的验收合同。
// 交付物4 份文件 · 仅规格
- spec/v1.md
- 系统规格 + 架构草图
- eval/bars.yaml
- 评测标准 + 达标线
- risk/register.md
- 风险清单 + 待决问题
- ops/deploy.tf
- 仓库与部署目标确认
//遥测
这些系统
此刻究竟在做什么。
每个系统都对外提供公开的 stats 端点。下方控制台每 30 秒从你的浏览器探测全部六个系统，并原样打印返回结果，包括每次请求实测的往返延迟。系统安静时，它会如实说明。这里没有任何模拟数据。
NexusRAG
Multi-cloud RAG · production workload
Queries · total…
Queries · 24h…
Uptime · 30d…
Indexed chunks…
GET /api/stats → …
// request log · fetched live from this browsernewest last
--:--:--Zawaiting first responses…
//工程守则
模型不等于系统。
系统才是真正的工程。
差别从来不在模型，而在模型周围的系统。下面是我们交付时绝不妥协的四条守则，每一条都配上让它真正可执行的反面模式。
守则 0101 / 04
确定性评测
用可度量的评分与回归检查取代“看起来不错”的主观测试。每一次提示词改动都附带相对冻结基线的增量对比。
// 不予接受“我试的时候是好的”
守则 0202 / 04
成本控制
靠架构防止 token 消耗失控，而不是事后补救式优化。成本上限、缓存与路由都内建在请求层。
// 不予接受“等贵起来再优化”
守则 0303 / 04
延迟工程
设计实时响应的系统，而不是慢上好几秒的系统。p95 本身就是产品功能；预热路径与流式输出是架构决策，不是优化项。
// 不予接受“模型要 8 秒，以后再说”
守则 0404 / 04
运行可靠性
构建在高负载、故障与扩容下仍持续工作的系统。健康检查、重试、幂等与熔断从第一天就交付。
// 不予接受“开发环境能跑，先上了再说”
//定位
AI 工程就是契约工程。
- 01构建控制平面。
- 02守住工作流。
- 03运行分层评测。
AI 基础设施，而非 AI 表演。
// 摘自工程守则
//联系
告诉我们你的系统。
我们告诉你达标线。
告诉我们你要交付的系统。我们会在 24 小时内回复：一份具体的技术方案、一条可度量的达标线，以及对周期与成本的诚实估算。