prompt：提示词工程
从用户角度来说，我认为提示词不是很重要，只要自己的表述清晰就可以了
但是从工程角度来说，理解学习挺重要的，需要改写用户提示词更好的喂给模型
- 这，那，他，她等需要从语意上下文改成明确的人
- 用户语言命中关键字又模糊的时候要提示ABC选项，问清意图
- 一个对话八个问题，需要拆解好问题
- few-shot，给一部分样例，2-5个比较好不要太多，用于参考缩小模型理解范围
- cot，推理链条，将问题拆解为步骤，1-2-3步得出结论
RAG
现在很多小公司都会使用，可以用coze等成熟的搭建，也可以自己写。范围非常宽，不是很多人概念中的不需要更改模型，rag的也可以结合微调，就是在微调过程中加入知识库训练，这可以大大提高准确率。不过从成本而言rag还是尽量不动模型。
- 知识库，从各种文档来，最好的格式当然是md，别的格式还要处理归档
- chunk，用段落标点拆分，简单的可以用字符数量，和重叠字数等。但是这个分的过程中一个关键就是会粗暴拆分语意，所以简单的重叠是这么做的。但是我问了公司里面一个项目，他们是用字符比如500个直接拆，没有重叠部分，然后用一个小一点的模型判断，上下文关联是不是要拼接，chunk算是结束但是后续阶段会用graph关系判断关系，比如搜曹操会搜出相关的人和事，尽量给出答案。
- Embedding，比较有名world2vec，向量数据库大概就是拆成各种向量，算相似度余弦夹角，点乘/各自平方和开根。
- 向量怎么提取呢，一种方法提取字和单词，过滤掉没有意义的他/的/是这些，然后用算法发现一部分词太多没有区分度影响判断也过滤；这种情况下字改变位置余弦结果，所以要用2个/3个相邻字也提取向量做判断。
- 还有判断方法也就是关键字，发现有哪些关键字，像推广搜
- 当然还有别的纬度，就是越多纬度的话，可能结果比较准确
- 检索排序重拍打分：向量太多了，这时候就要粗略筛选，从很多向量数据库里吗，从不同维度考虑分别取topK；从这些里面再排序判断打分，生成答案和参考的文档。
function call：
大部门模型的api都支持这个，自己准备很多函数给模型，然后问模型问题的时候，模型自己会判断要不要调用函数，相关接口返回告诉你调用什么，调用外部函数api像今天天气后，再调一次模型api生成答案
MCP: model context protocol
通用的协议，可以代替FC，可以说是一个外部的FC广场智能管理，更公开，增强AI功能和实时性，服务者可以提供服务挣钱，比如说高德地图
未完...
总的来说各种工程的应用是不难的，无非是组合各种方法，在某些阶段插入合适的大大小小的模型介入判断和生产，比如说专门用模型生成prompt啊，专门去拆去提取，难的是提高准确率，是迁移能力，还有根本的判断标准
