项目实训十三中医智能诊疗系统 热门搜索与文言文翻译功能实现从用户行为洞察到古籍知识普惠一、背景与需求在中医知识库查询模块的开发过程中两个看似独立的用户需求逐渐浮现1. 热门搜索用户需要“被引导”知识库中存储了大量的食材、穴位、方剂信息但新用户往往不知道从何查起。传统的做法是在搜索框下方固定几个热门词如“气虚体质”、“菊花”但这些词是硬编码的无法反映真实的用户搜索趋势也无法根据季节或热点动态变化。2. 文言文翻译用户需要“被理解”知识库中大量内容来自中医古籍如《本草纲目》《伤寒论》这些文献以文言文写成对普通用户存在阅读障碍。用户看到一段古籍原文后如果无法理解其含义知识库的“知识传递”价值就大打折扣。针对这两个痛点我分别设计了动态热门搜索和文言文翻译两个功能。二、热门搜索从静态数据到动态洞察2.1 设计思路热门搜索的核心是记录用户的真实搜索行为并从中提取高频词。技术上需要解决三个问题记录什么用户每次通过主搜索框发起的查询怎么存储统计每个搜索词的出现次数怎么展示按频率降序返回 Top N 个词2.2 技术实现在backend/api/knowledge.py中我使用内存中的Counter来统计搜索词并设置每 24 小时自动清空的机制确保热门词反映近期趋势而非历史累积。fromcollectionsimportCounterimporttime# 全局计数器_search_counterCounter()_last_cleanuptime.time()defrecord_search(q:str):记录用户搜索词ifqandlen(q.strip())2:# 过滤过短的搜索词_search_counter.update([q.strip()])router.get(/hot_searches)asyncdefget_hot_searches(limit:int6):global_last_cleanup# 每 24 小时自动清空避免数据膨胀iftime.time()-_last_cleanup86400:_search_counter.clear()_last_cleanuptime.time()hot[wordforword,_in_search_counter.most_common(limit)]return{code:200,data:hot}在/search接口中每次全库搜索时调用record_search(q)router.get(/search)asyncdefsearch(q:strQuery(...,min_length1),...):# 记录搜索词仅全库搜索分类搜索不记录record_search(q)# ... 原有搜索逻辑前端在页面加载时调用/knowledge/hot_searches接口将返回的动态数据替换原有的静态列表constloadHotSearchesasync(){constresawaitrequest.get(/knowledge/hot_searches)if(res.code200res.data.length){hotSearches.valueres.data}}2.3 技术思考为什么用内存而不是 Redis项目当前处于开发演示阶段使用内存Counter足以满足需求且无需额外依赖。但在生产环境中内存存储存在两个局限一是后端重启会丢失数据二是多实例部署时无法共享计数。因此我在代码中预留了迁移至 Redis 的接口设计后续只需替换存储层即可。为什么 24 小时清空热门搜索的本质是反映当下的用户兴趣。如果不定期清空早期的高频词会长期占据榜单无法反映近期热点如季节变化带来的搜索词变化。24 小时的窗口既保证了数据的时效性又不会因频繁重置导致榜单波动过大。与静态数据的对比对比项静态热门搜索动态热门搜索数据来源硬编码用户真实搜索行为时效性固定不变每 24 小时更新维护成本需手动修改代码自动统计零维护用户引导效果一般更好反映真实热点三、文言文翻译从原文到现代汉语3.1 设计思路古籍翻译功能的目标是当用户查看卡片详情时如果原文是文言文可以点击按钮一键翻译为现代汉语。技术上需要解决三个核心问题翻译质量中医古籍术语专业需要大模型具备中医领域知识响应速度用户点击后等待时间不宜过长成本控制避免相同内容重复调用大模型3.2 技术实现后端翻译接口在backend/api/knowledge.py中新增翻译接口调用项目已有的 LLM 服务classTranslateRequest(BaseModel):text:str# 翻译缓存_translation_cache{}router.post(/translate)asyncdeftranslate_text(req:TranslateRequest):textreq.text.strip()ifnottextorlen(text)5:return{code:200,translated:}# 生成缓存键使用内容的 MD5 哈希cache_keyhashlib.md5(text.encode(utf-8)).hexdigest()# 检查缓存ifcache_keyin_translation_cache:return{code:200,translated:_translation_cache[cache_key]}llmget_llm()promptf你是一位中医古籍翻译专家。请将以下文言文或中医专业内容翻译成通俗易懂的现代汉语要求 - 保留原意不添加额外信息 - 语言流畅适合普通人阅读 - 直接输出翻译结果不要有任何解释或标记 原文{text[:1500]}翻译try:resultawaitllm.generate(prompt,temperature0.3)translatedresult.strip()# 存入缓存_translation_cache[cache_key]translated# 控制缓存大小iflen(_translation_cache)1000:for_inrange(100):_translation_cache.popitem(lastFalse)return{code:200,translated:translated}exceptExceptionase:print(f翻译失败:{e})return{code:500,message:翻译服务暂时不可用}前端交互设计在知识卡片详情弹窗中原文和译文采用左右并列布局┌─────────────────────────────────────────────────────────┐ │ 原文 │ 现代汉语译文 │ │ 【定位】在胸部横平第1肋间隙... │ 【定位】在胸部与 │ │ 【解剖】当胸大肌、胸小肌处... │ 第1肋间隙水平相同...│ │ 【主治】①咳嗽、气喘... │ 【主治】①咳嗽、... │ │ │ │ │ │ [点击翻译] 按钮 │ └─────────────────────────────────────────────────────────┘未翻译时右侧显示“点击翻译”按钮点击后调用后端接口译文显示在右侧区域方便用户对照阅读。divclassdetail-compare!-- 原文栏始终显示 --divclassdetail-originaldivclassdetail-label 原文/divdivclassdetail-text{{ currentDetail?.content }}/div/div!-- 译文栏点击后展开 --divv-ifshowTranslationclassdetail-translateddivclassdetail-label 现代汉语译文/divdivv-iftranslating翻译中.../divdivv-else-iftranslatedTextclassdetail-text{{ translatedText }}/div/divdivv-elsebuttonclicktranslateDetail点击翻译/button/div/div3.3 技术思考为什么用大模型而不是规则翻译中医古籍的翻译涉及大量专业术语如“归经”、“性味”、“君臣佐使”这些词汇在不同的语境下可能有不同的含义。基于规则的翻译如词典替换无法处理这些复杂的语义变化而大模型具备上下文理解能力能够根据语境选择恰当的现代汉语表达。Prompt 设计的关键翻译功能的 prompt 设计经历了多次迭代。最初我让模型“翻译成现代汉语”但结果时好时坏——有时译文过于口语化丢失了专业信息有时又过于书面化不够通俗。最终我在 prompt 中增加了三条明确要求保留原意不添加额外信息——防止模型“发挥”语言流畅适合普通人阅读——明确目标受众直接输出翻译结果——避免模型输出“好的翻译如下”等冗余内容缓存策略的考量同一段古籍原文可能被多个用户查看如果不加缓存每次点击都会调用大模型既增加成本又降低响应速度。我用内容的 MD5 哈希作为缓存键并设置了 1000 条的上限防止内存溢出。当缓存超过上限时删除最早的 100 条利用 Python 3.7 字典保持插入顺序的特性。前后端分离的交互设计翻译采用“点击触发”而非“自动翻译”的设计既节省了大模型调用成本也让用户在自己需要时才触发翻译避免不必要的等待。四、总结与思考4.1 两个功能的共同点热门搜索和文言文翻译看似无关但都体现了同一个设计理念让技术服务于用户的真实需求。热门搜索降低用户的启动成本——不知道搜什么时看别人搜什么文言文翻译降低用户的理解成本——看不懂古籍时一键翻译4.2 技术选型的权衡功能技术选型权衡考虑热门搜索内存 Counter开发简单满足演示需求生产环境可迁移至 Redis文言文翻译大模型 缓存质量高但成本可控缓存避免重复调用4.3 未来优化方向热门搜索接入 Redis 实现多实例共享增加时间权重近期搜索权重更高按分类维度统计“食材类热门”、“穴位类热门”文言文翻译支持流式输出SSE逐字显示译文增加术语解释点击术语弹出释义支持多语言英文、日文翻译这两个功能的实现让我更加深刻地体会到好的产品不是堆砌功能而是在用户需要的时候提供恰到好处的帮助。