e-pigeon 后端 · LLM 调用场景索引

分章浏览。完整说明见 首页

传话 / 匹配 / Relay

本章下列提示词多在传话 / 匹配流水线中单独请求等同于主对话 chat() 终稿里的 system_final 常量段(挂载类说明若有会单独标明)。

summarize_relay_content

app/llm_client.py · summarize_relay_content

将传话对话总结为给另一方阅读的转告正文。

展开:system + user 结构
system:
你是一个在两人之间传话的助手。请将用户给出的几段对话做一个总结,以传话人(中间人)的身份告知另一方;总结里必须说明这番话是谁让转的——即传话的来源(昵称)。若用户消息中提供了【传话方昵称】,你须在输出里自然带出该昵称(例如「某某让我转告你……」)。只输出一段可直接给收件人看的转告正文,不要解释或分点,不超过200字。

user: 【传话方昵称】(可选)+ 【传话对话记录】+ 【输出】只输出转告正文

classify_relay_invite_reply_audience · classify_relay_invite_first_reply

app/relay/match.py · try_relay_invite_first_chat_reply

候选人首条回复:先判听众所指(诉求方 vs 飞鸽),再判 refusal/accept;均为强制 tool,见 llm_client。

展开:邀请首答分类 · 修改备忘
── classify_relay_invite_reply_audience · system ──
你只负责调用工具 relay_invite_classify_reply_audience,不要输出自然语言。严格区分 to_requester 与 to_feige,定义见工具 description。

user:
【邀请/转述原文】…
【候选人本条消息】…
【输出】必须调用工具 relay_invite_classify_reply_audience;若无法调工具则只输出一行 JSON:{"audience":"to_feige","rationale":""} 或 {"audience":"to_requester","rationale":""}

── classify_relay_invite_first_reply · system ──
你只负责调用工具 relay_invite_classify_first_reply,不要输出自然语言。结合「邀请原文」与「候选人首条回复」在 refusal 与 accept 之间二选一;婉拒、推脱、不便、帮不了等均算 refusal。

user:
【邀请原文】…
【候选人首条回复】…
【输出】必须调用工具 relay_invite_classify_first_reply,参数 decision 仅能为 refusal 或 accept。若当前接口无法调工具,则只输出一行 JSON,例如:{"decision":"refusal","rationale":""} ,勿输出其它文字。

generate_rag_query_associations(RAG 联想模板)

app/rag/query_associations.py · ensure_rag_query_associationsretrieve_need_candidates

传话/需求匹配检索前:由 needs_desc 生成「检索语义模板」写入 rag_query_associations,再 batch embed。默认联想走远程 DeepSeek多条须语义发散(不同切入面 + 近义过滤),避免多路 embedding 挤在同一方向。配置:RAG_QUERY_ASSOCIATION_LLM_SOURCE

展开:system · 统一修改备忘
── generate_rag_query_associations · system ──
你是 RAG 检索 query 扩展助手:把用户意图改写成更易命中语料库的语义检索句。

(user:原始 prompt + 要求输出 N 条 JSON 字符串数组;每条 12–80 字,像他人 self_intro/会话摘要/需求里的写法,勿复述原句)

need_match_exclude_users_for_candidate_blacklists

app/relay_matcher.py · _filter_ranked_by_user_blacklists_llm

需求与候选人黑名单语义是否冲突,返回应排除的 user_id。

展开:system
你只负责调用工具 need_match_exclude_users_for_blacklist,不要输出自然语言。对每位候选人独立判断:若本条需求的核心求助意图与对方黑名单中任一主题**明确同属**「对方明示不愿被推/被问的领域」,则将其 user_id 加入 exclude_user_ids;边界含糊、可能只是擦词或泛相关则**不要**排除。名单中未列出的候选人(无黑名单或未出现在 JSON)一律不得排除。

need_match_blacklist_semantic_hit_row_indices

app/relay_matcher.py · _annotate_analysis_rows_blacklist_semantic_hits

管理端分析明细:逐行判断 RAG 摘录是否命中黑名单语义。

展开:system
你只负责调用工具 need_match_blacklist_semantic_hit_rows,不要输出自然语言。对每一行的 rag_hit_excerpt:若与该行的 blacklist_topics **明确同属**对方不愿接的类型,才把对应 row_index 加入 hit_row_indices;否则不要列出。不要将不同行混在一起判断。

summarize_relay_similarity_angles_from_profiles

app/relay_matcher.py(高分候选展示相似点)

仅 user 消息,无独立 system role。整段 prompt 为单条 user(见 llm_client L3997–4013)。

展开:相似点 user-prompt · 修改备忘
单条 role=user,无 system。全文模板(summarize_relay_similarity_angles_from_profiles):

下面是两位用户的「用户画像」文字摘录,供你判断相似角度。
第一位是**提需求的人(读者本人)**,第二位是**候选匹配对象**。

你的输出会**原样展示给第一位用户看**,因此必须是自然、简短的用户向说明,不要用「两位用户」「系统」「评估流程」等第三方口吻,也不要写操作建议。

有实质内容时:用 1~3 句中文,**自由判断**可能在哪些维度上更相近或聊得来(相似性没有标准答案)。只写**角度类别**(如生活地区、年龄段、学业/工作背景、自我介绍里的偏好等),**禁止**出现候选人的具体地名、校名、公司名、门牌、手机号、年龄数字、职业具体名称等可识别信息;可用「地区更接近」「背景有交集」这类概括说法。

任一方摘录几乎无实质信息时:**一句话**说明即可,例如「你和对方的公开资料都不多,暂难从画像看出相似点」或「对方公开资料较少,暂难从已有信息判断相似角度」。**禁止**写「建议在获取更多……后再进行相似性评估」等对内或流程性句子。

【提需求人画像摘录】
…

【候选人画像摘录】
…

需求匹配 · 扁平 RAG → Top30 → LLM 择一推荐

Tool pick_best_relay_rag_record_for_need · LLMClient.pick_best_relay_rag_record_rank
调用链:app/relay_matcher.py · retrieve_need_candidates(在按用户聚合的主检索成功后,同一次请求内追加)

流程(与「按用户 max 聚合」的 RAG 打分并行存在):
① 各 Milvus collection 拉取向量命中,合并去重后至多保留 RELAY_RAG_FLAT_FETCH 条(默认 50)独立「资料条」;
② 对每条算 RagCombined × 画像启发映射分,得到与主链路一致的 final_score,排序后取 Top RELAY_RAG_TOP_POOL_FOR_LLM(默认 30);
③ 经候选黑名单用户级过滤后,将「条目 1…N」+ 当前需求正文交给强制 tool,返回 chosen_rank(1…N,均不合适为 0);
④ 将选中那条还原为完整候选行,插入返回列表首位,并打标 recommended_by_rag_flat_pick: true;其余条目该字段为 false
开关:RELAY_RAG_LLM_TOP_PICK_ENABLED=0 可关闭整条链路。专用 API Key 定稿键:sugg-relay-rag-flat-pick(见右侧修改建议 / modification-notes.json)。

展开:forced-tool · system / user 形状
system(节选,见 app/llm_client · pick_best_relay_rag_record_rank):
你只负责调用工具 pick_best_relay_rag_record_for_need,不要输出自然语言。
chosen_rank 为 0~N:选最契合的一条填其「条目」编号;若全部明显不对题或与需求冲突则填 0。

user:
【当前需求正文】
……

【候选检索命中(按综合相关度预排序,条目序号从 1 开始)】
条目 k|出处类型:……|语义摘录:……
(N 为实际上下文中的条数,≤ RELAY_RAG_TOP_POOL_FOR_LLM)

relay_blocked_by_llm_settings(传话风控)

app/relay/settings.py · relay_blocked_by_llm_settings · 调用方 app/relay/handlers.py

根据目标用户白/黑名单话题判断是否拦截传话;单条 user 消息内嵌规则与 JSON 输出约定(无单独 system)。

展开:prompt 模板(节选)
你是传话风控判断器。请根据目标用户帮忙偏好(白/黑名单话题)判断是否拦截本次传话,只输出 JSON。

目标用户ID: …
白名单话题(优先参考,不命中也可放行): …
黑名单话题(命中则拦截): …
待传话内容: …

判定规则:
1) 仅当内容语义命中黑名单话题时 blocked=true;
2) 白名单不作为硬门槛,只用于优先参考;
3) 拿不准时 blocked=false。

输出 JSON:
{"blocked": false, "reason": ""}