← 工程作品集 · 项目 03（系统演进）的真实案例
📈 规模化升级：从 230 到 1200+ 古籍
小剑 · 16 岁 · 系统工程与演进
背景 · 为什么升级
案例 01 的系统用了 3 个月。爷爷和朋友们反馈很好，但也指出了新需求：① 需要更多古籍（现在只有 230 块，有时候找不到），② 需要支持多轮对话（"对上一个回答继续追问"），③ 需要更快的检索（现在 200ms 对诊所还是有点慢）。小剑决定升级。
升级步骤
- 数据扩展： 230 → 1200+ 古籍块。增加《针灸甲乙经》《本草纲目》等 15 部新古籍。
- 性能优化： 加 embedding 缓存，避免重复计算。检索时间 200ms → 150ms。
- 多轮对话： 加 conversation memory，每个用户的历史问答保留 5 轮。
- CI/CD 建设： GitHub Actions 每日自动运行回归测试。一旦识别到性能下降 > 10%，自动告警。
关键代码 · 多轮对话 + 缓存
from langchain.memory import ConversationBufferMemory
from functools import lru_cache
import hashlib
# 多轮对话记忆
memory = ConversationBufferMemory(
memory_key="chat_history",
return_messages=True,
max_token_limit=2000 # 保留最多 2000 tokens
)
# Embedding 缓存（避免重复计算）
@lru_cache(maxsize=512)
def cached_embedding(text_hash):
"""缓存查询 embedding，减少重复计算"""
return embeddings.embed_query(text)
# 多轮对话链
conversation_chain = ConversationChain(
llm=llm,
memory=memory,
prompt=ChatPromptTemplate.from_messages([
("system", SYSTEM_PROMPT),
("human", "{input}"),
("assistant", "{chat_history}")
])
)
# 使用示例
user_input_1 = "患者气喘，舌淡，怎么治？"
response_1 = conversation_chain.run(input=user_input_1)
print(response_1)
user_input_2 = "那第二条古籍怎么配合使用？" # 需要上下文
response_2 = conversation_chain.run(input=user_input_2)
# AI 会记住之前推荐的古籍，自动将新问题与之关联
GitHub Actions CI 配置
name: Daily Regression Test
on:
schedule:
- cron: '0 2 * * *' # 每天凌晨 2 点运行
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: '3.10'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run Eval Tests (50 题)
run: python eval.py --dataset eval_50.json
- name: Performance Check
run: |
python perf_test.py --samples 100
# 检查是否检索时间 > 200ms 或推理时间 > 4s
- name: Detect Performance Regression
run: |
python compare_metrics.py \
--baseline metrics_baseline.json \
--current metrics_current.json \
--threshold 0.1
# 如果性能下降 > 10%，自动失败
- name: Notify if failed
if: failure()
uses: actions/github-script@v6
with:
script: |
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: '⚠️ Regression detected! Performance degraded > 10%'
})
性能对比
| 指标 | 升级前 | 升级后 | 改进 |
|---|---|---|---|
| 古籍块数 | 230 | 1200+ | 420% ↑ |
| 向量库大小 | 150 MB | 740 MB | 5x |
| 检索时间 | 200ms | 150ms | 25% ↓ |
| 推理时间 | 3s | 3.2s | -7% (接受) |
| 准确率 | 87% | 84% | -3% (可接受) |
| 真实用户 | 1 | 3 | 新增 2 人 |
升级后的问题和解决
- 问题 1：古籍块从 230 增到 1200，准确率反而下降到 84%。原因是新增的古籍编码质量不如原来的精细。解决：重新标注 200 个新古籍块，准确率恢复到 85%。
- 问题 2：多轮对话中，第 3 轮开始 memory 会混淆。原因是 memory 缓冲溢出。解决：改为智能摘要，只保留关键信息。
- 问题 3：CI 流水线有时候因为 Ollama 崩溃而失败。解决：加健康检查，如果 Ollama 不可用则跳过，记录日志。
学到的经验
小剑说："升级比从 0 开始更难。因为要保证向后兼容，还要确保性能不下降太多。最聪明的决定是提前建立 CI 和 baseline metrics，这样每次改动都能看到影响。"