我用3种Prompt把GPT-4o准确率从61%拉到94%：一次结构化信息抽取的Token与质量对比实验
同一个信息抽取任务，我用三种不同粒度的Prompt在GPT-4o上做了对照实验：朴素指令、Few-shot示例、Schema约束+CoT。结果准确率从61.3%提升到94.0%，但平均Token消耗从218涨到742，单次成本翻了3.4倍。这篇文章完整记录了实验设计、可运行代码、踩过的坑，以及我最终如何在质量和成本之间做出取舍。
Docker Compose编排多服务项目：网络卷挂载健康检查与启动顺序配置
本文以一个包含Nginx、Spring Boot、MySQL 8.0和Redis 7的真实项目为例，分享一套可直接运行的docker-compose.yml配置。通过自定义bridge网络实现服务隔离，利用命名卷持久化MySQL数据，配合healthcheck与depends_on的condition参数精确控制启动顺序，最终将服务启动失败率从30%降至接近0，冷启动时间稳定在45秒以内。
LoRA与QLoRA微调Qwen2.5-7B：从数据构建到推理效果对比
本文记录了在单张RTX 4090（24GB）上使用LoRA和QLoRA微调Qwen2.5-7B-Instruct的完整流程。训练数据为3200条医疗问诊指令，采用peft 0.13.2 + transformers 4.44.2 + bitsandbytes 0.43.3。LoRA配置r=16、alpha=32、dropout=0.05，QLoRA开启4bit NF4量化。最终LoRA显存占用18
从0.42到0.89：一次RAG系统检索增强生成优化的完整记录
线上RAG问答系统上线两周后，用户反馈"答非所问"的比例高达37%，人工评估命中率只有0.42。本文记录了我在一周内对系统做的三轮优化：chunk策略从固定512切分改为语义+重叠切分，embedding从text-embedding-ada-002切到bge-large-zh-v1.5，并引入bge-reranker-large做精排。最终Top-5命中率提升到0.89，端到端响应P95从2.3
Docker Compose编排多服务容器化部署与健康检查启动顺序
本文以一个真实的前后端分离项目为例，分享一套可落地的Docker Compose编排方案。项目包含Nginx、Node.js API、PostgreSQL、Redis四个服务，通过自定义bridge网络实现服务隔离，使用命名卷持久化数据，并借助healthcheck与depends_on的condition字段控制启动顺序。文中给出完整的docker-compose.yml配置，涵盖镜像版本锁定、
Milvus 2.4与Qdrant 1.9选型对比：千万级向量检索性能与资源实测
本文基于一个真实的图文推荐场景，在相同硬件（16C64G，NVMe SSD）上对 Milvus 2.4.1 与 Qdrant 1.9.2 进行了系统性对比。数据集为 1000 万条 768 维向量，测试了 HNSW 与 IVF 索引的写入速度、QPS、P99 延迟、内存与磁盘占用，并给出 Docker Compose 部署步骤和 Python 客户端代码。最终 Qdrant 在内存占用上节省约 3
从62%到89%：一次RAG检索增强生成系统的三阶段优化记录
本文记录了一个基于LangChain 0.1.12 + Milvus 2.3.4的生产级RAG系统优化过程。原始方案采用固定512字符切分与text-embedding-ada-002，在1200条测试集上召回率仅62.3%，答案准确率58.7%。通过chunk策略调整为语义+递归混合切分、embedding切换至bge-large-zh-v1.5、引入bge-reranker-large重排序三
从0.62到0.89：一次RAG检索增强生成系统的三段式优化实录
线上知识库问答的召回率长期卡在0.62，用户抱怨"答案就在文档里却搜不到"。我用两周时间做了三轮改造：chunk策略从固定512切到语义+重叠切分，embedding从text-embedding-ada-002换成bge-large-zh-v1.5，再引入bge-reranker-large做精排。最终Hit@5从0.62提升到0.89，MRR从0.48升到0.77，P99延迟只增加了180ms
我用4版Prompt把JSON抽取准确率从72%拉到96%：一次token与质量对比实验
同一个"从电商评论中抽取结构化JSON"的任务，我写了4版Prompt，在gpt-4o-mini（2024-07-18）上各跑200条真实评论。V1直白提问：准确率72%，平均token 312，JSON解析失败率11%。V4引入字段定义、few-shot示例、输出约束和失败重试后：准确率96%，平均token 587，解析失败率降到0.5%。本文完整记录每版Prompt的写法、token账单、踩
LoRA微调Qwen2.5-7B全记录：数据构造、rank选型与loss曲线复盘
本文记录了我在单卡A100 40G上使用LoRA/QLoRA微调Qwen2.5-7B-Instruct的完整过程。训练数据为1.2万条垂域问答对，采用4-bit NF4量化+LoRA（r=16, alpha=32），约3小时完成2个epoch，最终显存占用从78GB降到14.6GB，eval_loss从1.42降到0.87。文中包含可运行代码、loss曲线解读、踩坑记录，以及微调前后在50条测试集
我用GPT-4o做合同信息抽取：7版Prompt迭代，Token从2100降到680，准确率反升到96%
本文记录了我用GPT-4o从采购合同中抽取结构化字段的Prompt Engineering全过程。从最初的“一句话Prompt”到最终的结构化模板，我迭代了7个版本，输入Token从峰值2137降到684，单次成本下降约68%，字段抽取准确率却从78%提升到96%。文章包含完整可运行代码、每版Prompt的对比数据、temperature与response_format参数的取舍，以及JSON输出
我用GPT-4o做合同要素抽取：6版Prompt迭代对比，Token从2100降到680
本文以“从采购合同中抽取甲乙方、金额、付款节点、违约条款”这一具体任务为例，记录了6版Prompt的完整迭代过程。测试集为50份真实中文合同，使用GPT-4o（2024-08-06版本）和text-embedding-3-small，温度设为0。结果：初版Prompt平均消耗2100 Token、字段准确率72%；最终版降到680 Token、准确率94%，单份成本从0.021美元降至0.0068
从78分到94分：一次电商评论情感分析Prompt工程优化记录
同一个情感分类任务，我用4版Prompt在GPT-4o-mini上做了对比实验。V1零样本准确率78.3%，V4加入角色设定、少样本示例和结构化输出后提升到94.1%，但token消耗从180涨到720。本文记录了完整的实验过程、每次迭代的思考、踩过的坑，以及准确率与成本之间的权衡数据，供正在做Prompt优化的同学参考。
Docker Compose编排多服务容器化部署：网络卷挂载健康检查与启动顺序配置详解
一个包含Web、API、Redis、PostgreSQL、Nginx的5服务项目，用Docker Compose 2.24编排时踩了不少坑：服务启动顺序错乱导致API连不上数据库、卷挂载权限报Permission denied、健康检查形同虚设。本文给出完整可运行的compose.yaml配置，涵盖自定义bridge网络、命名卷挂载、healthcheck探针与depends_on条件启动，并附上
用LoRA与QLoRA微调Qwen2.5-7B：从数据到loss曲线的完整记录
本文记录了在单张RTX 4090（24GB）上微调Qwen2.5-7B-Instruct的全过程。采用QLoRA 4bit量化，r=16、alpha=32、dropout=0.05，在约8500条医疗问答数据上训练3个epoch，耗时约4.5小时。训练loss从初始1.87降至0.62，验证集loss稳定在0.71。推理对比显示，微调后模型在专业术语回答准确率上从基线52%提升到87%，同时保留了
React Context 重渲染拖垮列表后，我把状态迁到了 Zustand 和 Pinia
一个后台管理系统，订单列表页在 React Context 方案下每次筛选要重渲染 1200+ 个组件，交互延迟从 80ms 涨到 640ms。我把全局状态拆成 Zustand（React 18.2）和 Pinia（Vue 3.4）两套实现，迁移后首屏可交互时间从 2.4s 降到 1.1s，筛选响应稳定在 90ms 以内。这篇文章记录了方案对比、迁移步骤、踩过的坑和真实的 Performance
React 18与Vue 3项目中从Context/Props迁移到Zustand与Pinia的完整记录
本文记录了一个中型后台管理系统从React Context + Props drilling迁移到Zustand，以及另一个Vue 3项目从Props/Provide-Inject迁移到Pinia的真实过程。迁移前，React项目在100+组件规模下，一次全局状态更新平均触发47个组件重渲染，交互延迟最高达380ms；迁移后重渲染降至平均6个组件，延迟降到42ms。文章包含方案对比、迁移步骤、可运
FastAPI接口从2.3s优化到89ms：一次Profiling驱动的数据库与缓存调优记录
线上一个FastAPI订单查询接口P99延迟飙到2.3s，QPS只有120就出现大量超时。本文用cProfile+py-spy定位到N+1查询和缺失索引问题，配合SQLAlchemy的selectinload、Redis缓存热点数据、以及uvicorn worker调参，最终P99降到89ms，QPS提升到1400+。文中包含完整压测对比数据和可复现代码。
Docker Compose编排多服务容器化部署与健康检查启动顺序配置
本文以一个真实的前后端分离项目为例，分享一套可运行的docker-compose配置。项目包含Nginx、Spring Boot API、MySQL 8.0、Redis 7.2四个服务，通过自定义bridge网络实现服务隔离，使用命名卷持久化数据，并借助healthcheck与depends_on的condition机制解决启动顺序问题。配置完成后，冷启动从原来的手动5步缩减为1条命令，平均启动耗
Milvus与Qdrant向量数据库选型对比：千万级向量场景下的部署、性能与资源实测
在图文去重业务中，我们需要在1000万条768维向量上做Top-10相似检索，要求P99延迟低于50ms、单机可部署。本文在同一台16核64GB服务器上，对Milvus 2.4.0（Standalone）和Qdrant 1.9.0做了完整对比：包括Docker部署步骤、HNSW参数调优、批量写入与并发查询代码，以及QPS、P99延迟、内存和磁盘占用的实测数据。结论先行：Qdrant在单机中小规模场
