RAG准确率从62%到89%：chunk分割、Embedding选型与Rerank重排全记录
生产环境的RAG系统在文档问答中频繁答非所问，检索Top5命中率仅62%。本文记录了完整的优化链路：将固定512字符的chunk改为基于语义边界的动态分割，命中率提升至71%；将bge-large-zh替换为text-embedding-v3，命中率提升至78%；最后引入bge-reranker-base重排，Top5命中率稳定在89%。文中给出完整的代码实现、参数配置与踩坑记录，包括中文标点切分
LangChain 0.3手写Agent循环：工具注册与记忆回收的7个实现细节
当AutoGPT的Plan-and-Execute循环在复杂任务中频繁死循环时，我决定用LangChain 0.3.7手写一个仅200行的Agent内核，支持工具增删、滑动窗口记忆和异常熔断。在WizardLM-13B模型上，工具调用成功率从78%提升至94%，平均单轮响应从3.2秒降至1.8秒。核心实现包括：ToolRegistry动态注册、双缓冲记忆池、重试退避策略，以及基于token预算的循
React 19与Vue 3.5告别Props钻取：Zustand与Pinia迁移实录
本文记录一个中型CRM系统从React Context/Props向Zustand（React 19）及Pinia（Vue 3.5）迁移的完整过程。项目包含42个路由页面、超过200个组件，迁移前因Props钻取导致平均组件重渲染次数达8.3次/操作，Context更新引发全树渲染。迁移后，核心页面渲染时间从210ms降至65ms，内存占用减少37%。文中对比两者设计哲学，提供原子化Store切分
asyncio重构Flask接口：QPS从87到1420的并发改造实录
一个批量查询接口，在4核8G机器上，压测QPS只有87，RT P99高达2.3秒。用asyncio + aiohttp重构后，同样的压测场景，QPS飙到1420，P99降到180ms。这不是魔法，而是把每个请求内部的5次串行HTTP调用改成了并发。本文记录这次改造的完整过程，包括asyncio.Semaphore限流、aiohttp连接池参数调优、以及一个差点让我放弃的TaskGroup坑。代码基
React 19与Vue 3.5下的状态管理迁移：从Props钻取到Zustand/Pinia的工程化实践
接手一个维护两年的中后台项目，200+组件，状态散落在Context和Props中，每次需求迭代都像在迷宫里找线头。产品侧反馈页面切换卡顿，DevTools显示Context导致的重渲染平均每次操作触发87次多余render。本文记录我将该项目从React 19的Context+useReducer迁移到Zustand v5，以及另一个Vue 3.5项目从Props+emit迁移到Pinia v3
asyncio重构Flask接口：请求耗时从850ms降至120ms的实践记录
某个凌晨两点，线上告警群里炸了锅——订单导出接口平均响应时间飙到850ms，数据库连接池被打满。排查后发现，罪魁祸首是串行调用三个下游HTTP服务（用户服务、库存服务、价格服务），每个耗时250ms左右。本文记录了我用Python 3.10原生的asyncio + httpx将该接口从同步阻塞改为异步并发，在不引入Celery等重型中间件的前提下，将P95延迟从1.2s压到180ms，数据库连接数
FastAPI接口耗时2200ms降至90ms：Profile与缓存优化实录
一个内部报表接口在QPS300时P99延迟飙至2.2秒，数据库CPU被打满。通过cProfile定位出N+1查询与JSON序列化两大元凶，再配合Redis缓存热点数据与SQL窗口函数重写，最终将P99降到90ms，单机QPS从420提升至3800。本文记录了完整的优化链路：从py-spy火焰图到SQLAlchemy懒加载陷阱，再到缓存一致性设计，含全部可复现代码与压测数据，适合正在被慢接口折磨的P
asyncio重构Flask接口，QPS从120飙升到850的完整记录
一个内部报表接口因串行调用三次外部HTTP服务，高峰期平均延迟2.8秒，F5健康检查频繁超时。用asyncio搭配aiohttp重写后，在Python 3.8.10、单机4核8G环境下，接口P95延迟从3100ms降至420ms，QPS从120提升至850，CPU峰值反而下降15%。本文记录了从同步到异步的完整改造过程，包括Semaphore限流、超时控制、连接池复用等关键细节，以及两个隐藏极深的
Docker Compose 2.24多服务编排：网络隔离与健康检查实战配置
本文基于 Docker Compose 2.24.0 与 Docker Engine 25.0.3，分享一个生产级多服务项目的完整编排方案。项目包含 Nginx 1.25、Golang 1.22 API 服务、PostgreSQL 15.3 和 Redis 7.2，通过自定义 bridge 网络实现服务隔离，利用卷挂载持久化数据，配置 healthcheck 控制启动依赖。实测服务冷启动时间从原来
7B模型LoRA微调实录：从数据清洗到推理显存节省80%
上周用单张RTX 3090对Llama-2-7B做领域微调，通过LoRA将训练显存从112GB压到21GB，训练速度仅下降18%。本文记录完整过程：从构造1.2万条法律问答数据，到用peft库配置r=8的LoRA模块，再到loss从2.1降至0.47的曲线变化。实测微调后模型在领域问答的ROUGE-L从0.23提升到0.51，而通用能力几乎无损。包含全部代码和踩坑记录，特别是关于梯度检查点与LoR
asyncio重构Flask接口：Web API吞吐量提升3倍实践
在一次真实业务压测中，我发现现有Flask同步接口在20并发下平均响应时间飙升至1.2秒，而通过asyncio+httpx异步化改造后，同样20并发下P95延迟降至380ms，吞吐量从85 req/s提升至260 req/s。这篇文章将完整记录我的改造过程，包括协程设计、事件循环配置、以及Python 3.11中asyncio的TaskGroup新语法。你会看到具体的before/after代码，
Docker Compose多服务编排：网络、健康检查与启动顺序实践
本文分享一个基于Docker Compose v2.24.2的6服务容器化部署方案，包含Nginx网关、Spring Boot后端、PostgreSQL、Redis、RabbitMQ及定时任务组件。通过自定义bridge网络实现服务隔离，利用healthcheck与depends_on条件组合解决启动顺序问题，卷挂载持久化数据。配置上线后服务启动时间从原来的3分12秒缩短至58秒，容器重启成功率提
Git分支模型与CI/CD集成：从混乱到有序的版本控制演进
团队从3人扩张到12人后，feature分支冲突率从每周15次降至2次，发布周期从2天缩短至4小时。这套基于Git Flow改良的Trunk-Based分支策略，配合GitHub Actions自动化流水线，解决了多环境部署和紧急热修复的痛点。文中分享的分支命名规范、Code Review检查清单、以及Jenkins迁移至Gitea Actions的踩坑记录，都是实际生产环境验证过的方案。如果你正
Prompt Engineering调优实录：从8.2%到91.4%准确率的CRF任务迭代
在处理一个中文命名实体识别（NER）任务时，我通过系统性地迭代Prompt模板，将GPT-4-turbo的F1值从初始的8.2%提升至91.4%。全程共消耗约12.6万tokens，对比了零样本、少样本、结构化输出约束、思维链等5种Prompt策略。实测发现：直接提供JSON Schema约束输出格式可使解析错误率降低76%，而加入两个正例和两个反例的少样本策略效果最佳。本文记录了完整的实验数据、
Milvus与Qdrant选型实测：千万级向量检索资源消耗与延迟对比
在电商以图搜图业务中，我们对比了Milvus 2.4.1与Qdrant 1.9.2在相同数据集（1000万条768维向量）下的部署复杂度、查询延迟与内存占用。实测结果显示：Qdrant在单机SSD模式下P99延迟低至23ms，内存占用仅3.2GB；Milvus在分布式集群下吞吐更高，但单机部署时索引构建耗时是Qdrant的2.3倍。本文记录了完整的部署步骤、性能压测数据与踩坑经验，供选型参考。
React 19与Vue 3.5下的状态管理迁移：从Context到Zustand/Pinia的工程实践
当项目超过50个组件、状态更新导致首屏渲染耗时从210ms飙升至780ms时，Context/Props已显疲态。本文记录一次真实的中台系统重构：对比React 19的Context + useReducer与Zustand 5.x、Vue 3.5的provide/inject与Pinia 3.x在性能、代码量、可维护性上的差异。通过具体代码演示迁移步骤，并附上LCP从2.8s降至1.2s、组件重
Prompt Engineering实测：5轮迭代让GPT-4o输出准确率从67%升至92%
本文基于实际业务场景（电商评论情感分类），记录了对GPT-4o（gpt-4o-2024-05-13）进行Prompt工程优化的完整过程。通过对比零样本、少样本、CoT（思维链）、结构化输出及自一致性（Self-Consistency）5种策略，我发现单纯增加示例token消耗增加87%但准确率仅提升4%，而结合角色设定+XML约束+CoT的组合方案，在准确率92%的同时将无效输出比例从15%降至0
Git分支策略与Code Review流水线：支撑200人团队的协作体系
当团队从20人扩张到200人，原先“一条master走天下”的工作流彻底崩坏——合并冲突日均17次，线上事故3起，代码审查形同虚设。本文基于Git 2.39.1与GitLab 15.11，拆解一套经过生产环境验证的分支策略：trunk-based与GitFlow的折中方案，配合基于Merge Request的强制Code Review流水线，以及Jenkins 2.414.2驱动的CI/CD集成。
Docker Compose编排多服务：网络隔离、健康检查与启动顺序实战
本文分享一个真实项目中的docker-compose.yml配置，包含Nginx、Spring Boot、PostgreSQL、Redis四个服务。通过自定义网络实现服务隔离，使用volume持久化数据库和日志，利用healthcheck和depends_on条件控制启动顺序。解决了一个困扰我两天的服务启动竞态问题，最终将服务启动时间从原来的90秒压缩到35秒，并保证了100%的启动成功率。
Git分支策略与CI/CD集成：从混乱到有序的协作重构
接手一个40人团队，Git仓库日均30+次提交，却因混乱的分支命名和缺乏Code Review导致每周至少2次代码冲突回滚。本文记录我引入Git Flow + GitHub Flow混合模型，配合Jenkins Pipeline实现自动化构建、测试和部署的完整过程。通过规范分支策略、强制执行PR Review、集成SonarQube静态检查，将代码冲突率从15%降至2%，部署失败率降低70%，发布
