Prompt工程调优实录：信息抽取任务下5版模板的Token与精度博弈
在财务公告结构化抽取任务中，我对比了5版Prompt模板，从零样本到Few-shot再到思维链。实验基于GPT-4-turbo（1106-Preview），使用QPS=1的限流配置。结果显示：**结构化指令+3个示例**的模板在F1分数上比朴素模板提升22.7%，但Token消耗增加41%。最终通过**动态截断+关键字段前置**策略，将单条成本压至0.031美元，同时F1稳定在0.89。文中附全部
RAG准确率从68%到91%：chunk重构、Embedding换血与Rerank落地的全记录
三个月前，我负责的智能客服知识库RAG系统在200+真实问询测试集上命中率只有68.2%，Top-3召回率不足80%。排查发现，罪魁祸首是固定的256 token分块把技术文档中的表格和代码切得七零八碎；其次，老旧的`text2vec-large-chinese`在语义匹配上严重拖后腿。本文记录了完整的优化链路：针对文档结构定制Markdown感知分块器、切换至BGE-large-zh（v1.5）
asyncio重构Flask接口，QPS从120飙到800+
某电商订单系统上线大促前，发现订单详情接口在500并发下平均延迟1.2秒，QPS仅120。用asyncio+httpx替换requests同步调用，配合Semaphore限流和连接复用，仅改动40行代码，延迟降至180ms，QPS提升至850。本文记录完整的压测数据、踩坑过程（包括EventLoop阻塞、超时参数陷阱）和可复用的代码模板。
Docker Compose编排实践：多服务依赖、健康检查与启动顺序控制
部署一个由Nginx、Spring Boot应用、PostgreSQL和Redis组成的项目，直接`docker-compose up`就绪后，服务间依赖乱序导致连接失败。本文结合一个真实的中台项目，展示如何设计docker-compose.yml，覆盖自定义网络、持久化卷挂载、健康检查机制及depends_on条件控制，确保容器启动顺序可靠。配置上线后，服务启动成功率从70%提升至100%，平均
7B模型LoRA微调显存爆炸？QLoRA+4bit量化拯救记
上周用两张3090微调Qwen2.5-7B做法律文书摘要，全量微调直接OOM，LoRA(rank=8)勉强跑通但显存峰值26.8GB。换用QLoRA+NF4量化后，峰值显存直降到11.2GB，训练速度只慢18%。最终在2000条法律判决书上微调3个epoch，ROUGE-L从0.42提升到0.57，推理时模型能正确引用法条编号。本文记录完整过程：从数据清洗、bitsandbytes配置、PEFT参
Prompt工程化调优实录：基于GPT-4o的SQL生成任务，从42%到89%准确率
本文记录了一次针对自然语言转SQL任务的Prompt调优全过程。通过5轮迭代实验，对比了零样本、Few-shot、CoT及结构化约束等多种Prompt策略。实验基于OpenAI GPT-4o (gpt-4o-2024-05-13) 与gpt-3.5-turbo-0125，在Spider验证集抽取的200条难例上测试。最终方案通过引入Schema感知与输出格式约束，将执行准确率从基线42.5%提升至
React 19与Vue 3.5状态管理迁移实录：从Context/Props到Zustand与Pinia的架构重塑
随着项目迭代至10万行代码，React Context频繁更新导致组件树re-render耗时从12ms飙升至210ms，Vue3中Props深层透传让维护成本增加40%。本文记录一次为期三周的状态管理层迁移：对比Zustand 5.0与Pinia 3.0在响应式追踪、代码侵入性及包体积（+3.2KB gzip）上的取舍，分享分阶段迁移策略（按模块灰度切换）、性能调优（selector精确订阅使R
asyncio重构Flask接口：Web API并发性能从50到1800 QPS的改造记录
一个基于Flask+Requests的聚合查询接口，在8核8G机器上压测QPS仅50，TP99高达480ms。通过引入asyncio+aiohttp替换同步IO，并利用`loop.run_in_executor`保留少量CPU密集计算，最终QPS提升至1850，TP99降至32ms。本文记录完整改造链路，包含asyncio.Semaphore限流、连接池复用、超时控制三个关键动作，并附上wrk压测
RAG召回率从61%到89%：chunk重切、embedding换型与rerank排序的工程实践
在搭建面向企业私有文档的问答系统时，召回质量一度卡在61%的Hit Rate上，表现为“答非所问”和“漏检关键段落”。本文记录一次为期两周的RAG管线优化过程：首先将固定256字符chunk改为基于Markdown标题的语义切分，并引入50%重叠滑动窗口；随后将Embedding模型从`text2vec-large-chinese`切换为`BAAI/bge-large-zh-v1.5`，维度从10
Prompt工程化调优实录：从42%到91%的意图识别准确率跃迁
同一意图分类任务，朴素Prompt准确率仅42%，经系统化Prompt工程改造后提升至91%。本文记录完整实验过程，对比4种Prompt模板在GPT-4-turbo（gpt-4-0613）下的表现差异，精确统计token消耗：从每次请求平均1876 tokens降至512 tokens，成本降低72.7%。通过few-shot示例筛选、格式约束、思维链引导三步优化，最终在200条测试集上达到F1=
FastAPI接口延迟1800ms降至90ms：Profile与缓存优化实录
某CRM系统客户列表API在QPS 50时P95延迟飙至1800ms，MySQL CPU打满。通过cProfile定位到N+1查询与ORM序列化热点，配合SQLAlchemy 2.0的selectinload、Redis管道缓存及gzip中间件，将P95降至90ms，QPS提升至800。全程记录PyCharm Profiler火焰图分析、EXPLAIN执行计划解读、缓存穿透防护等细节，附完整代码与
RAG召回率从61%到89%：chunk重切、embedding换代与rerank落地实录
两个月前，我们内部知识库问答系统的召回率（Recall@5）一直卡在61%左右，用户问“发票报销流程”，系统却常把“差旅报销制度”排到后面。问题不在模型，而在RAG管线的三个关键环节：chunk切分太粗导致语义混淆、embedding模型对长尾专有名词表征弱、以及缺失粗排后的精排纠错。本文记录一次完整的RAG系统优化过程——从调整chunk策略（固定256字到语义滑动窗口），到切换embeddin
LangChain与AutoGPT融合：手写ReAct循环实现Agent记忆与容错机制
当我的AutoGPT项目在处理连续12轮工具调用后因上下文窗口溢出而崩溃时，我意识到单纯堆砌LangChain组件无法解决Agent的长期记忆问题。本文将展示如何用LangChain 0.1.0构建一个仅需387行代码的ReAct Agent，包含自定义工具装饰器、基于SQLite的向量记忆、三级异常恢复机制，以及循环次数硬限制。实测在金融问答场景下，该Agent将工具调用成功率从68%提升至94
FastAPI压测1830req/s瓶颈定位与三层缓存优化实录
接手一个日活5万的B端查询接口，单次请求平均耗时862ms，P99高达2.3秒。本文记录从零开始使用py-spy、locust、EXPLAIN ANALYZE定位FastAPI + PostgreSQL的性能瓶颈全过程。通过引入Redis二级缓存、Gunicorn多进程及SQLAlchemy查询裁剪，最终将接口吞吐量从312req/s提升至1830req/s，平均响应时间降至47ms。文中包含py
Docker Compose多服务编排：网络分区、健康检查与启动依赖全解析
一个Spring Boot + Redis + MySQL + Nginx的项目，从单机docker run到Compose编排，我花了三天时间踩遍网络、卷、启动顺序的坑。本文基于Docker 24.0.7与Compose v2.24.0，分享一个含4个服务、3个自定义网络、2个持久化卷的生产级compose文件。通过healthcheck与depends_on条件组合，将服务启动时间从90秒压缩
Git Flow与Trunk Based双轨制：团队协作中的分支策略与CI/CD集成实践
当团队从3人扩张到15人，主干分支频繁冲突、发布窗口混乱、Code Review流于形式——这是我们2024年Q2的真实痛点。本文基于Git 2.43.1、GitLab 16.9与Jenkins 2.452，详细拆解我们如何从单一Git Flow演化为“Trunk Based为主、Release分支为辅”的双轨制模型。你将看到具体的分支保护规则、基于`git diff --check`的自动化检查
RAG准确率从61%到87%：chunk/embedding/rerank全链路调优实录
上周处理一个私有知识库问答项目，基线RAG(FAISS+OpenAI Embedding+Top5直接生成)在32道人工标注问题上准确率只有61.3%，回答经常漏掉关键条款。我依次做了三件事：把固定256字chunk改成按Markdown标题语义切分、把OpenAI text-embedding-ada-002换成bge-large-zh-v1.5(本地部署)、引入bge-reranker-bas
LangChain 0.3手写Agent循环：工具注册与记忆回溯机制
上个月在电商客服场景中，我基于AutoGPT思路用LangChain 0.3.7搭建了一个能查订单、算优惠、发券的Agent。系统处理了4120轮对话，工具调用成功率92.3%，但最初版本在连续对话第8轮时token溢出、第5轮时工具参数幻觉频发。本文记录我从零实现Agent主循环的过程：如何用Pydantic定义工具Schema、用SQLite做短期记忆滑窗、用异常捕获实现工具级熔断，以及那个让
Token成本与输出质量双优化：Prompt工程在SQL生成任务中的实验对比
在Text-to-SQL任务中，我基于GPT-4-turbo（1106-Preview）进行了三轮Prompt迭代实验。零样本（Zero-shot）下准确率仅61.3%，且平均每条SQL消耗2,847 tokens；通过引入“数据库Schema结构化描述+3条Few-shot示例+输出JSON限定”，准确率提升至82.7%，单次调用token消耗降至1,934 tokens。更意外的是，通过“错误
React 19与Vue 3.5项目从Context到Zustand/Pinia迁移实录：状态管理选型与性能对比
本文记录了两个真实项目（React 19 + Next.js 15 与 Vue 3.5 + Vite 6）从 Props/Context 与 Provide/Inject 迁移至 Zustand 4.5 与 Pinia 2.3 的完整过程。我们遇到了 Context 导致的 15% 额外重渲染和 Vue 组件间状态同步的时序问题。通过引入外部状态库，React 项目首屏交互时间（TTI）从 2.8
