年后這兩個月頻繁組織架構變動，所以博客很久沒更新。現在暫時算是塵埃落定，趁這段時間整理一下。
入職九個月，自己參與的項目有4個，負責前后端開發，測試，devops（全棧/doge），總結一下背景，技術棧以及個人在開發方面的思考。
A和B分別是【Python開發】大模型應用開發項目整理
中數據抓取和GenAI部分。
A 數據抓取
A.1 背景
時間：2024.8-2024.10
原始數據只能從某Java Application上獲取，需獲取原始數據并傳入Web UI中進行下一步的處理。
A.2 技術棧
A.2.1 jnlp應用程序數據抓取
1.窗口定位：psutil，pygetwindow，win32process
2.數據獲取：keyboard(監聽和模擬鍵盤事件)，pypeclip（剪貼板），win32api（鼠標）
3.GUI界面：pysimpleUI
亮點：
1.針對非英語版本的應用無法通過固定title定位的問題，采用psutil通過獲取pid獲取title，進而定位到window。
2. 針對用戶點擊過應用其他部分則無法獲取數據的問題，采用win32api將鼠標移至初始位置，再獲取數據，并添加retry機制提高成功率。
A.2.2 Selenium傳入數據
配置chromedriver.exe路徑，通過selenium拉起chrome，通過執行js腳本將數據填入page中的hidden element，前端進行解析。
亮點：
1.針對重復啟動chrome的問題，設置指定options參數，確保只啟動唯一chrome實例。
2.針對退出時chromedriver自動關掉而占用系統資源的問題，增加了關閉app時調用taskkill命令。
A.3 經驗和思考
個人感想： 這是入職后接手的第一個組件，接手時開發已經到了中后期，有基本功能，但遺留了較多歷史bug需要修復。另外由于嚴格的policy，導致在整個項目上線后，仍然需要user手動更新chromedriver，在一定程度上增加了user的使用成本。
經驗： 盡量減少user使用成本，及時索取feedback。對于無法避免的error，給出完善的refer doc和app提示。
B GenAI 數據分析
B.1 背景
時間：2024.10-2024.12
利用OpenAI的GPT模型，設定prompt來提取article的關鍵信息和摘要，將結果返回后端分析，給出recommendation。
B.2 技術棧
B.2.1 prompt調優
在與大語言模型（如GPT、Claude等）交互時，Prompt調優是提升輸出質量的關鍵技術。以下是一些常見的Prompt調優方法：
1. 明確任務指令
- 使用清晰的動詞（如"總結"、“解釋”、“生成”、“對比”）
- 指定輸出格式（如JSON、Markdown、代碼塊）
- 設置約束條件（如字數限制、技術棧要求）
2. 提供示例（Few-Shot Learning）
在Prompt中插入輸入-輸出示例，引導模型學習模式。
3. 分步引導（Chain of Thought）
將復雜任務拆解為多個步驟，要求模型分步輸出思考過程。
4. 角色扮演
指定模型扮演特定角色（如資深程序員、學術專家、創意寫作導師）。
5. 控制輸出長度
使用明確的字數或標記限制，或指定輸出復雜度。
6. 提供上下文信息
在Prompt中添加相關背景知識或前置條件。
7. 避免歧義
使用精確術語，避免模糊詞匯（如"一些"、“相關”、“適當”）。
8. 迭代優化（A/B測試）
方法：
對同一任務創建多個版本的Prompt，對比模型輸出質量。如何評估模型輸出？使用了Gemini模型進行evaluate，這也是業界常用方法，用其他llm來評估llm的輸出。
9. 使用系統提示（System Prompt）
在多輪對話中，使用System Prompt設置模型的行為基調。
10. 利用外部工具
結合Function Calling讓模型調用外部API獲取實時數據。
總結
Prompt調優的核心原則是明確性、具體性和引導性。對于復雜任務，建議采用迭代優化和分步引導策略，逐步逼近理想結果。
B.2.2 異步處理
由于flask并不原生支持并發，所以使用事件循環和協程實現并發，用redis做backup queue，防止服務器down丟失task。
B.2.3 監控
上線后需要監控服務狀態
- 日志（級別，按日存儲，支持查詢，排序）
- Queue每小時峰值長度
- 響應時間（每小時觸發request，記錄上游響應時間）
B.3 經驗和思考
高并發下一定需要異步，獲取結果可以callback和等待輪詢，python的異步常通過協程和事件循環實現，此外也可以嘗試用多線程。為了防止service down，需要記錄任務狀態備份。為了及時發現問題定位問題，需要在生命周期中做好監控和log。
C pipeline components
C.1 背景
時間：2025.1-2025.3
將GenAI相關功能包裝成API作為AI workflow的node，開放給center提供pipeline服務。
C.2 技術棧
C.2.1 FastAPI
相比于之前的Flask，FastAPI的好處主要體現在以下幾個方面：
- 高性能：FastAPI基于Starlette，基于ASGI協議構建的異步處理引擎，在TechEmpower基準測試中實現每秒12萬次請求處理能力，與Golang的Gin框架（13.5萬次）及Node.js的Fastify（11.8萬次）處于同一性能梯隊，適合高并發場景。
- 異步支持：FastAPI原生支持異步編程，適合現代Web開發需求。
- 自動文檔生成：FastAPI自動生成OpenAPI和JSON Schema文檔，便于API的測試和調試。
所以我們最后在新項目中選用了FastAPI作為微服務框架。
C.2.2 Celery分布式任務處理+監控
之前的redis queue和in-memory queue也可以實現異步任務處理，只是無法快速擴展，無法監控任務狀態，需要自己寫錯誤處理，所以在新項目中嘗試引入Celery。好處：
- 多節點擴展+負載均衡: 擴展的話加worker就行
- 結果存儲：將任務的結果存儲在各種后端（如 Redis、MongoDB、數據庫等），方便后續查詢和處理。還可以通過任務 ID 查詢任務的結果，實現任務狀態監控和結果獲取。
- 任務重試: 支持任務重試機制，當任務失敗時可以自動重試，確保任務最終能夠成功執行。
持久化隊列: 使用持久化的消息隊列（如 RabbitMQ 和 Redis），即使系統重啟，任務也不會丟失。監控和管理: 提供豐富的監控和管理工具，如 Flower（一個實時監控 Celery 集群的 Web 界面），了解任務的執行情況和系統狀態。
C.3 經驗和思考
在使用celery時，發現盡管有以上好處，但也增加了維護成本，需要同時維護微服務和worker腳本，對于小項目來說可能并不是很適合。所以以后在選擇使用技術的時候，也要考慮到使用成本的問題。
D 數據校驗
D.1 背景
時間：2025.3-2025.4
根據user給定的rules，對每列數據進行校驗，輸出校驗結果。
D.2 技術棧
D.2.1 JavaScript engine（低代碼平臺）
D.2.2 NER model
提取address中的city，county，iso code，用于匹配規則
D.3 經驗和思考
這個項目的底層架構是5/6年前的了，所以不支持異步和并發，因為infra性能較差也經常503，504，后來后端有些改進。在技術實現不復雜，復雜的地方在于user給定的校驗規則太多，需要大量的溝通，主要學到的就是郵件留痕，及時同步了。個人認為NER model可以用llm替代（不需要手寫每一條規則），整個項目也可以用Python重構提高并發（user請求量還挺大的），只是因為接手的時候已經到UAT階段，無法修改，但做了demo給leader展示，如果有機會重構的話則可以用。
部署
Jenkins+k8s+ArgoCD
Jenkins用來拉代碼，build docker image，手動將image更新到k8s腳本中，在ArgoCD中sync進行同步。
參考：
python事件循環深度剖析
)
)
