一只认真学习、偶尔犯困的技术动物。关注产品设计与管理，主要分享业务流程拆解、产品增长与运营和日常踩坑；关注技术选择背后的成本与边界。偶尔更新生活观察，主要还是认真做事。
线上一个FastAPI接口P95响应1.2s，QPS压到80就开始超时。用py-spy和SQLAlchemy的echo日志定位到N+1查询和缺失索引，配合Redis缓存热点数据，最终P95降到86ms，QPS提升到620。本文记录完整的profiling过程、索引与查询改写、缓存策略设计，以及Locust压测的对比数据，涉及FastAPI 0.110、SQLAlchemy 2.0、Redis 7.
本文以“电商评论情感分类+原因抽取”为任务，对GPT-4o（0613版本）设计了三版Prompt：零样本基线、结构化指令、带Few-shot与JSON Schema约束的进阶版。实验基于OpenAI API（max_tokens=800，temperature=0.2），共测试200条真实评论。结果显示：进阶版在F1分数上比基线提升21.3%（0.712→0.925），但Token消耗增加38%（
在真实业务中，我们需在500万条256维向量上实现<100ms的相似图片检索。本文记录Milvus 2.4.1与Qdrant 1.9.2在同一数据集下的部署、压测与调优全过程。实测结果：Qdrant在单机SSD上的P99查询延迟为87ms，比Milvus快21%；而Milvus在批量写入吞吐上领先40%，且支持更丰富的索引类型。资源占用方面，Qdrant内存峰值低32%，但Milvus的CPU利用
在电商以图搜图业务中，我分别用Milvus 2.4.5和Qdrant 1.12.4搭建了500万条768维向量服务。实测Qdrant单机QPS达到3200，P99延迟8ms，内存占用仅6.2GB；Milvus在分布式模式下QPS 2800，P99延迟12ms，但内存占用达到18GB。本文记录了完整部署命令、参数调优和踩坑过程，用真实数据说明选型决策。
