大语言模型赋能备案审查
业务背景
备案审查是指规范性文件在制定颁布后，按法定期限报同级或上一级人大常委会备案，由接受备案的人大常委会在法定期限内依照法定标准和程序对其进行监督审查的活动。
在这个过程中，最重要的就是确保下位法不会与上位法相抵触。
因规范性文件众多，而具备审查资格的专家又极少，故工作进程较为缓慢，现期望借助AI的能力，提高效率。
核心流程
大约 2 分钟
使用Ragas评估LLM应用
说明
对于已知问题有正确答案的场景，适合使用 ragas 的 faithfulness 指标对 GenAI 应用响应结果进行评估，方便进行回归测试。
注意：本文提到的方法，只适用于对已知问题的评估。对于线上运行时，用户提的随机的、不在测试集范围内的问题，不适合用此方法评估。
安装
pip install ragas
大约 3 分钟
缩减Python应用的镜像体积
背景
当你为 LLM 应用构建镜像时，发现整个过程很慢，一看镜像体积：好家伙，1.76 G！
能不能减少镜像体积，缩短打包时间啊？本文将分享两招实用的技巧，让 Python 应用的镜像体积减少 50%。
大约 2 分钟
Docker 构建镜像、推送、启动实用脚本
misc
存储多份 docker 认证信息：
mkdir "~/.project1"
mkdir "~/.project2"
docker --config ~/.project1 login registry.example.com -u <username> -p <deploy_token>
docker --config ~/.project2 login registry.example.com -u <username> -p <deploy_token>
大约 1 分钟
使用 pytest 为LLM应用添加回归测试
回归测试的必要性
基于 LLM 的 Chat 应用大量依赖了 Prompt Engineering，而用户的输入又千奇百怪，调整了 Prompt 模板，很可能会有意想不到的效果：满足了新需求，却破坏了旧功能。
因此，LLM应用比任何时候都需要回归测试，确保在迭代过程中，不破坏旧功能、不让已修复的bug复现。
而回归测试，当然是自动化执行效率才高。本文交分享如何使用 pytest 对 LLM 应用进行自动化的回归测试。
大约 3 分钟
给LLM应用添加日志
logging替代print
目前公司的LLM应用开发使用的是 Python 技术栈，观察源码，发现没有多少日志，纵使有，也是用的 print。
print 的作用，就相当于 Java 的 System.out.print，相当于 Node.js 的 console.log，一般只适合在本地调试，不适合作为日志输出的。
大约 3 分钟
生产教训：测试环境要与生产环境一致
事件还原
业务流程：
- app-a 上传文件
- app-b 下载文件后使用文件
其他信息：
- 开发、测试环境使用 MinIO
- 生产环境使用 Amazon S3
问题：
- app-a 上传文件成功
- app-b 使用文件报错
逐步分析定位问题：
- app-a 与 app-b 配置是否一致？——确认都是使用 S3
- S3 是否正确配置？有没权限问题？——确认配置正确，没有权限问题
- app-a 是否真的上传成功？——确认文件已在 S3
- app-b 是否下载成功？——根据日志，判断下载失败，得到的信息是：文件不存在。
大约 2 分钟
避免密码明文传输
说明
密码加密是很常见的安全性需求，但由于涉及前后端，前后端分离的情况下，开发人员容易只关心自己熟悉的领域，最终导致“知道要加密，实际还是没明文”的情况发生。
本文分享实际可运行的前后端代码，以减轻大家实现密码密文传输的负担。
流程说明：前端加密，后端解密。
当然，数据库存储的肯定是密文。这里后端解密的意思是：需要使用密码的时候，如获取数据库的连接，由后端解密后使用。
大约 2 分钟
检查名字是否重复
检查名字是否重复是很常用的业务需求，本文推荐一种更省心、更少bug的做法。
大约 1 分钟
复制代码也许不是罪
前言
熟悉我的人都知道，我对代码是有追求的。
正式参加工作后，我就知道，复制粘贴是坏的实践，自己一直极力避免做这样的事。要是遇到了别人复制粘贴，要么喷，要么自己改。
我早期认为：复制代码就是菜。
后来认为：复制代码可能不是菜，而是懒，没有素养，自我要求。
而现在：代码其实也没那么重要；某些情况下复制粘贴是可以接受的。
编码经过七个年头，我思想上为何会有如此改变？难道这就是传说中的七年之痒?
大约 2 分钟
...