Sparse Retriewer

<p><a class="oln" data-kno="K#/D0EF" href="/D0EF">RAG</a>において検索を担う箇所
</p>

Retriever

アイデア

<p><a class="URI" href="https://blog.recruit.co.jp/data/articles/two-tower-model/" target="_blank" rel="noopener nofollow ugc">https://blog.recruit.co.jp/data/articles/two-tower-model/</a>
</p>

 https://blog.recruit.co.jp/data/articles/two-tower-model/
  

『Two-Towerモデルと近似最近傍探索による候補生成ロジックの導入』

<p><a class="URI" href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/b9f4e78a8830fe5afcf2f0452862fb3c0d6584ea.pdf" target="_blank" rel="noopener nofollow ugc">https://storage.googleapis.com/pub-tools-public-publication-data/pdf/b9f4e78a8830fe5afcf2f0452862fb3c0d6584ea.pdf</a>
</p>

 https://storage.googleapis.com/pub-tools-public-publication-data/pdf/b9f4e78a8830fe5afcf2f0452862fb3c0d6584ea.pdf
  

『Mixed Negative Sampling for Learning Two-tower NeuralNetworks in Recommendation』

<p>レコメンドシステムにおいて、ユーザーのEmbeddingを計算するモデル（Query Tower）と、推薦対象のEmbeddingを検索するモデル（Candidate TowerあるいはDocument Tower）の2つを使う手法。
</p><p>検索システムにおいてはQuery towerで検索文のEmbeddingを生成する。
</p><p><a class="oln" data-kno="K#/2D8A" href="/2D8A">dual encoder</a>とも呼ばれている。
</p>

 レコメンドシステムにおいて、ユーザーのEmbeddingを計算するモデル（Query Tower）と、推薦対象のEmbeddingを検索するモデル（Candidate TowerあるいはDocument Tower）の2つを使う手法。
検索システムにおいてはQuery towerで検索文のEmbeddingを生成する。
dual encoderとも呼ばれている。
  

Two-Towerモデル

<p><a class="oln" data-kno="K#/43D5" href="/43D5">索引</a>としての<a class="oln" data-kno="K#/7AFD" href="/7AFD">embedding</a>（<a class="oln" data-kno="K#/B358" href="/B358">ベクトル</a>）
</p>

 索引としてのembedding（ベクトル）
  

応類

<p><a class="oln" data-kno="K#/43D5" href="/43D5">索引</a>である<a class="oln" data-kno="K#/5E11" href="/5E11">応量</a>を引くための<a class="oln" data-kno="K#/7AFD" href="/7AFD">embedding</a>（<a class="oln" data-kno="K#/B358" href="/B358">ベクトル</a>）
</p>

 索引である応量を引くためのembedding（ベクトル）
  

向類

<p>おそらく一般的には<a class="oln" data-kno="K#/5E11" href="/5E11">応類</a>と<a class="oln" data-kno="K#/C21C" href="/C21C">向類</a>は同じ<a class="oln" data-kno="K#/01C5" href="/01C5">言語モデル</a>で生成して検索に用いるのだが、<a class="oln" data-kno="K#/5E11" href="/5E11">応類</a>と<a class="oln" data-kno="K#/C21C" href="/C21C">向類</a>で異なる言語モデルを用いることで以下の利点が得られる。
</p><ul><li>利用者の動向から<a class="oln" data-kno="K#/C21C" href="/C21C">向類</a>を学習させ、漸次的に<a class="oln" data-kno="K#/704E" href="/704E">検索精度</a>を向上させる<li>利用者の動向から<a class="oln" data-kno="K#/C21C" href="/C21C">向類</a>を学習させ、漸次的に個々の利用者に対して検索結果を変化させる<li>上記をしつつ、更新費用が高くなる<a class="oln" data-kno="K#/5E11" href="/5E11">応類</a>を不変あるいは低頻度での更新と出来る</ul><p><a class="oln" data-kno="K#/4256" href="/4256">レコメンド</a>においても同様のことができ、同じような利点が得られる。
</p><br/><p><a class="oln" data-kno="K#/41FF" href="/41FF">Two-Towerモデル</a>と同一。
</p>

 おそらく一般的には応類と向類は同じ言語モデルで生成して検索に用いるのだが、応類と向類で異なる言語モデルを用いることで以下の利点が得られる。
利用者の動向から向類を学習させ、漸次的に検索精度を向上させる利用者の動向から向類を学習させ、漸次的に個々の利用者に対して検索結果を変化させる上記をしつつ、更新費用が高くなる応類を不変あるいは低頻度での更新と出来るレコメンドにおいても同様のことができ、同じような利点が得られる。
Two-Towerモデルと同一。
  

応向分離

ベクトル

造語

索引

embedding

<p><a class="oln" data-kno="K#/1690" href="/1690">応向分離</a>は誰かもう考えているだろうと思って検索した所、<a class="oln" data-kno="K#/41FF" href="/41FF">Two-Towerモデル</a>というのがあることがわかった。
</p>

 応向分離は誰かもう考えているだろうと思って検索した所、Two-Towerモデルというのがあることがわかった。
  

<p><a class="URI" href="https://ufcpp.net/blog/2021/12/unicode-benzene/" target="_blank" rel="noopener nofollow ugc">https://ufcpp.net/blog/2021/12/unicode-benzene/</a>
</p>

 https://ufcpp.net/blog/2021/12/unicode-benzene/
  

『ベンゼン環の文字コード: ⌬ (U 232C), ⏣ (U 23E3)』

<p><a href="/?kw=〄">〄</a>と<a href="/?kw=〠">〠</a>を全知検索したら宇田川さんが描き出し済みでわろうた。
</p><p><a href="/?kw=⌬">⌬</a>と<a href="/?kw=⏣">⏣</a>は流石になかった（2023年11月19日時点）。
</p>

 〄と〠を全知検索したら宇田川さんが描き出し済みでわろうた。
⌬と⏣は流石になかった（2023年11月19日時点）。
 

『++C++; // 未確認飛行 C ブログ』

ベンゼン環

面白いものを思いついた（見つけた）と思ったら宇田川さんが輪郭作成済みの現象

KJ法

<p>デライトにはKJ法的な何かを感じるが、KJ法というラベルを付けてしまうとそれに引っ張られてしまうようで怖い。
</p>

 デライトにはKJ法的な何かを感じるが、KJ法というラベルを付けてしまうとそれに引っ張られてしまうようで怖い。
  

あれ

考える花火

<p class="no_idt">輪郭の表題が長い場合、後ろが……として短縮表示される
<br/>　
<br/>短い表題をつけるように促す効果がある
<br/>表題を「あれ」で済ませたくなる
</p>

 輪郭の表題が長い場合、後ろが……として短縮表示される
　
短い表題をつけるように促す効果がある
表題を「あれ」で済ませたくなる
 

表題の表示制限

<p class="no_idt">　KJ法を<a class="oln" data-kno="K#/585A" href="/585A">正・反・合</a>の弁証法にあてはめれば、正と合は島になったデータ、合は表札となる。
<br/>　また、KJ法とはデータとの対話であり、<a class="oln" data-kno="K#/D04E" href="/D04E">対話的思考は弁証法</a>である。ゆえにKJ法は弁証法だといえる。
<br/>　KJ法を開発した川喜田二郎氏も、<a class="oln" data-kno="K#/35C1" href="/35C1">「KJ法はある意味で、弁証法の技術化である」</a>と<a class="oln" data-kno="K#/A1B5" href="/A1B5">『続・発想法』</a>で述べている。
</p>

 　KJ法を正・反・合の弁証法にあてはめれば、正と合は島になったデータ、合は表札となる。
　また、KJ法とはデータとの対話であり、対話的思考は弁証法である。ゆえにKJ法は弁証法だといえる。
　KJ法を開発した川喜田二郎氏も、「KJ法はある意味で、弁証法の技術化である」と『続・発想法』で述べている。
 

KJ法は弁証法

身の回りの弁証法・弁証法の応用

<p><a class="URI" href="https://dlt.kitetu.com/" target="_blank" rel="noopener nofollow ugc">https://dlt.kitetu.com/</a>
</p><p><a class="oln" data-kno="K#/5198" href="/5198">メモアプリ</a>に見せかけた、<a class="oln" data-kno="K#/84D3" href="/84D3">KNS</a>(<a class="oln" data-kno="K#/AEB2" href="/AEB2">SNS</a>+<a class="oln" data-kno="K#/ECEE" href="/ECEE">個人知識管理サービス</a>)に見せかけた、<a class="oln" data-kno="K#/B526" href="/B526">知能増幅メモサービス</a>
</p>

 https://dlt.kitetu.com/
メモアプリに見せかけた、KNS(SNS+個人知識管理サービス)に見せかけた、知能増幅メモサービス
 

デライト(なんでもメモ)

データとの対話

考える

2020年7月15日

花火

KJ法は弁証法の技術化

 川喜田二郎「KJ法はある意味で、弁証法の技術化である」

正・反・合

表題

<p>Wikipediaで弁証法のページをザっと読んだら、「なんかめんどくさそう」という印象だけが残った。
</p><p>Googleで弁証法と検索して出てきたページをザっと読んだら、なんかWikipediaで感じた「なんかめんどくさそう」という印象とギャップがありすぎて、理解からは程遠い感覚になる。
</p><p>Googleで「site:scrapbox.io 弁証法」と検索したら<a class="oln" data-kno="K#/D2ED" href="/D2ED">アープラノート</a>が出てきて、中埜肇『弁証法』が出てくる。アープラノートで取り上げられているなら読む価値はありそうだ。あそこの人は私よりも遥かに哲学について詳しい。
</p>

 Wikipediaで弁証法のページをザっと読んだら、「なんかめんどくさそう」という印象だけが残った。
Googleで弁証法と検索して出てきたページをザっと読んだら、なんかWikipediaで感じた「なんかめんどくさそう」という印象とギャップがありすぎて、理解からは程遠い感覚になる。
Googleで「site:scrapbox.io 弁証法」と検索したらアープラノートが出てきて、中埜肇『弁証法』が出てくる。アープラノートで取り上げられているなら読む価値はありそうだ。あそこの人は私よりも遥かに哲学について詳しい。
 

弁証法

<h2><a class="oln" data-kno="K#/C9AC" href="/C9AC">弁証法</a>とはなにか</h2><p>　ここでの弁証法は、いわゆる<a class="oln" data-kno="K#/585A" href="/585A">正・反・合</a>からなる弁証法、すなわち、<a class="oln" data-kno="K#/ACEC" href="/ACEC">定立</a>（<a class="oln" data-kno="K#/A811" href="/A811">テーゼ</a>）があり、<a class="oln" data-kno="K#/CA1E" href="/CA1E">反定立</a>（<a class="oln" data-kno="K#/5E12" href="/5E12">アンチテーゼ</a>）と対立し、<a class="oln" data-kno="K#/EDF8" href="/EDF8">止揚</a>（<a class="oln" data-kno="K#/BA77" href="/BA77">アウフヘーベン</a>）して対立が解消された<a class="oln" data-kno="K#/ACEC" href="/ACEC">定立</a>であるところの<a class="oln" data-kno="K#/B125" href="/B125">総合</a>（<a class="oln" data-kno="K#/BB86" href="/BB86">ジンテーゼ</a>）が作られる形の弁証法を言うこととする。
</p><h2>メモで弁証法</h2><p>　<a class="oln" data-kno="K#/D8C7" href="/D8C7">中埜肇</a>の「<a class="oln" data-kno="K#/D04E" href="/D04E">弁証法の根源は対話的思考</a>」から考えると、メモを書くという行為は自己との対話が発生するために、「弁証法的」である。メモ対自分（<a class="oln" data-kno="K#/5C21" href="/5C21">否定</a>）の対話、すなわち対立が起こる。そこから<a class="oln" data-kno="K#/EDF8" href="/EDF8">止揚</a>が生じ、<a class="oln" data-kno="K#/B125" href="/B125">総合<ruby></a><rp>（</rp><rt>ジンテーゼ</rt><rp>）</rp></ruby>という<a class="oln" data-kno="K#/10EB" href="/10EB">知識</a>に至る。
</p><p class="no_idt">　<a class="oln" data-kno="K#/2A16" href="/2A16">輪郭法</a>では、書くことで生じる対立がより起こりやすくなっている。
<br/>　引き入れによって、ある題目に関係する複数の輪郭が同時に目に入る。読み手の脳内では、輪郭（肯定）対輪郭（否定）の対話・対立が生じる。
</p><h2><a class="oln" data-kno="K#/7CA3" href="/7CA3">階層的止揚</a></h2><p class="no_idt">　<a class="oln" data-kno="K#/32D1" href="/32D1">中埜肇の考える弁証法では、対立と否定によるジグザグ的な連続としてとらえる</a>。輪郭法では、この対立と否定によるジグザグの連続が容易に表現される。
<br/>　以下のような順によって、連鎖的に対立と止揚とが繰り返される。
</p><ol><li>輪郭Taを描き出す。<li>Taを他の輪郭Txに引き入れる。<li>Txの中には過去に引き入れた輪郭Tbがあり、TaとTbの対立と止揚によって、輪郭Tnが生じる。<li>Tnについても引き入れ・対立・止揚が生じ、連鎖し続ける。</ol><p>　これを<a class="oln" data-kno="K#/7CA3" href="/7CA3">階層的止揚</a>と呼ぶことにする。
</p><p><a class="img" href="https://i.gyazo.com/a164bc7a8ab1999e3347c4d3d9b26b78.png"><img src="https://i.gyazo.com/a164bc7a8ab1999e3347c4d3d9b26b78.png" style="max-width: 100%;"/></a></p>
<h2><a class="oln" data-kno="K#/51D2" href="/51D2">多重階層的止揚</a></h2><p>　<a class="oln" data-kno="K#/7CA3" href="/7CA3">階層的止揚</a>をさらに発展させる。輪郭法では、輪郭は複数の輪郭に引き入れられることができる。すなわち、Txに引き入れられTnの元となったTaは、Tαに引き入れられ、Tpと対立し、Tµを生み出せる。すなわち多重に止揚が生じる。これを<a class="oln" data-kno="K#/51D2" href="/51D2">多重階層的止揚</a>と呼ぶことにする。
</p><p><a class="img" href="https://i.gyazo.com/ba289201d50b7feb5f9da9d0a9e01cf3.png"><img src="https://i.gyazo.com/ba289201d50b7feb5f9da9d0a9e01cf3.png" style="max-width: 100%;"/></a></p><h2><a class="oln" data-kno="K#/51D2" href="/51D2">多重階層的止揚</a>は<a class="oln" data-kno="K#/4860" href="/4860">止揚爆発</a>を引き起こす</h2><p class="no_idt">　さて、多重かつ階層的に止揚が生じるならば、連鎖的に止揚が生じるはずである。<a class="oln" data-kno="K#/B89F" href="/B89F">核分裂の連鎖反応</a>によって<a class="oln" data-kno="K#/A125" href="/A125">核爆発</a>が発生するように、<a class="oln" data-kno="K#/EDF8" href="/EDF8">止揚</a>が止揚を発生させることを、<a class="oln" data-kno="K#/4860" href="/4860">止揚爆発</a>と呼ぶことにしよう。
<br/>　止揚爆発が起こった結果、何がどうなるかはまだ何もわかっていない。少なくとも、定立を書いたメモが爆発的に増加（<a class="oln" data-kno="K#/2F5A" href="/2F5A">メモ爆発</a>）し、書きたいことが止めどなく表れてくることが考えられる。
</p><h2><a class="oln" data-kno="K#/4860" href="/4860">止揚爆発</a>（<a class="oln" data-kno="K#/2F5A" href="/2F5A">メモ爆発</a>）の条件</h2><p>　経験的に、<a class="oln" data-kno="K#EDD2/3DCE" href="/3DCE">メモ爆発はメモが1万個ぐらい溜まったら起こり始める</a>。しかし、<a class="oln" data-kno="K#EDD2/31A7" href="/31A7">直列に並べたメモは、メモ爆発を起こしにくい</a>。メモに書かれた<a class="oln" data-kno="K#EDD2/04BD" href="/04BD">定立どうしの対立</a>を発見するには、すべての<a class="oln" data-kno="K#EDD2/F986" href="/F986">メモの見返し</a>を何度も行う必要がある。そのために、関連したメモが自動で目に入る仕組みが望ましい。その素朴な方法としてフォルダやタグが考えられるが、<a class="oln" data-kno="K#EDD2/6BC6" href="/6BC6">メモのフォルダ分けはメモ爆発を妨げる</a>し、<a class="oln" data-kno="K#EDD2/220C" href="/220C">タグは階層的止揚を妨げる</a>。やはり、輪郭法によってメモを集めることが重要となる。
</p><p>　さて、1万もメモを書けないと思われるかもしれない。しかし、<a class="oln" data-kno="K#EDD2/A2B8" href="/A2B8">9万のメモすらデジタルだとうっかり超えてしまえる数</a>だ。<a class="oln" data-kno="K#EDD2/A32B" href="/A32B">ツイートはメモ</a>だとするならば、10万ツイートする人は少なくない。Twitterと類似したサービスの<a class="oln" data-kno="K#EDD2/BBAE" href="/BBAE">マストドン</a>では、<a class="oln" data-kno="K#EDD2/9C50" href="/9C50">マストドンチュートリアルは10万投稿</a>と言われている。<a class="oln" data-kno="K#EDD2/84AA" href="/84AA">10万投稿</a>が簡単な数ではないことを使った冗談の類だが、それでも不可能な数ではないことを示している。実際、10万を超える投稿数を持つマストドン利用者は何人もいる。
</p><p>　また、1人で10万のメモを書く必要はない。ほかの人のメモによっても止揚爆発にともなうメモ爆発は起こると思われる。そのためには、利用者が メモを分断するモノがないこと が条件となってくる。
</p><p>　メモを分断するモノとは何だろうか。例えば、そもそもメモを公開していなければそれによって他人に止揚が生じることはない。また、公開していたとしても、利用者ごとのフォルダのように、なんらかの要因でそのメモの相互作用が阻まれれば、止揚もその中に留まる。全利用者のメモが一つのフォルダの中にいるかのごとき環境が、メモ爆発の発生条件として望ましい。
</p>

 弁証法とはなにか　ここでの弁証法は、いわゆる正・反・合からなる弁証法、すなわち、定立（テーゼ）があり、反定立（アンチテーゼ）と対立し、止揚（アウフヘーベン）して対立が解消された定立であるところの総合（ジンテーゼ）が作られる形の弁証法を言うこととする。
メモで弁証法　中埜肇の「弁証法の根源は対話的思考」から考えると、メモを書くという行為は自己との対話が発生するために、「弁証法的」である。メモ対自分（否定）の対話、すなわち対立が起こる。そこから止揚が生じ、総合（ジンテーゼ）という知識に至る。
　輪郭法では、書くことで生じる対立がより起こりやすくなっている。
　引き入れによって、ある題目に関係する複数の輪郭が同時に目に入る。読み手の脳内では、輪郭（肯定）対輪郭（否定）の対話・対立が生じる。
階層的止揚　中埜肇の考える弁証法では、対立と否定によるジグザグ的な連続としてとらえる。輪郭法では、この対立と否定によるジグザグの連続が容易に表現される。
　以下のような順によって、連鎖的に対立と止揚とが繰り返される。
輪郭Taを描き出す。Taを他の輪郭Txに引き入れる。Txの中には過去に引き入れた輪郭Tbがあり、TaとTbの対立と止揚によって、輪郭Tnが生じる。Tnについても引き入れ・対立・止揚が生じ、連鎖し続ける。　これを階層的止揚と呼ぶことにする。

多重階層的止揚　階層的止揚をさらに発展させる。輪郭法では、輪郭は複数の輪郭に引き入れられることができる。すなわち、Txに引き入れられTnの元となったTaは、Tαに引き入れられ、Tpと対立し、Tµを生み出せる。すなわち多重に止揚が生じる。これを多重階層的止揚と呼ぶことにする。
多重階層的止揚は止揚爆発を引き起こす　さて、多重かつ階層的に止揚が生じるならば、連鎖的に止揚が生じるはずである。核分裂の連鎖反応によって核爆発が発生するように、止揚が止揚を発生させることを、止揚爆発と呼ぶことにしよう。
　止揚爆発が起こった結果、何がどうなるかはまだ何もわかっていない。少なくとも、定立を書いたメモが爆発的に増加（メモ爆発）し、書きたいことが止めどなく表れてくることが考えられる。
止揚爆発（メモ爆発）の条件　経験的に、メモ爆発はメモが1万個ぐらい溜まったら起こり始める。しかし、直列に並べたメモは、メモ爆発を起こしにくい。メモに書かれた定立どうしの対立を発見するには、すべてのメモの見返しを何度も行う必要がある。そのために、関連したメモが自動で目に入る仕組みが望ましい。その素朴な方法としてフォルダやタグが考えられるが、メモのフォルダ分けはメモ爆発を妨げるし、タグは階層的止揚を妨げる。やはり、輪郭法によってメモを集めることが重要となる。
　さて、1万もメモを書けないと思われるかもしれない。しかし、9万のメモすらデジタルだとうっかり超えてしまえる数だ。ツイートはメモだとするならば、10万ツイートする人は少なくない。Twitterと類似したサービスのマストドンでは、マストドンチュートリアルは10万投稿と言われている。10万投稿が簡単な数ではないことを使った冗談の類だが、それでも不可能な数ではないことを示している。実際、10万を超える投稿数を持つマストドン利用者は何人もいる。
　また、1人で10万のメモを書く必要はない。ほかの人のメモによっても止揚爆発にともなうメモ爆発は起こると思われる。そのためには、利用者が メモを分断するモノがないこと が条件となってくる。
　メモを分断するモノとは何だろうか。例えば、そもそもメモを公開していなければそれによって他人に止揚が生じることはない。また、公開していたとしても、利用者ごとのフォルダのように、なんらかの要因でそのメモの相互作用が阻まれれば、止揚もその中に留まる。全利用者のメモが一つのフォルダの中にいるかのごとき環境が、メモ爆発の発生条件として望ましい。
 

要望

トリクルダウン

<p class="no_idt">　<a class="oln" data-kno="K#/D151" href="/D151">実家</a>から<a class="oln" data-kno="K#/1AA9" href="/1AA9">みかん</a>が届いた。5kg。ギリギリ冷蔵庫に入った。5kgともなると流石に食べきれずに腐らせてしまうので、職場で配りたい。明日総務部あたりに頒布していいか打診しよう。
<br/>　<a class="oln" data-kno="K#/A7C8" href="/A7C8">和歌山</a>では農家からみかんが<a class="oln" data-kno="K#/BD17" href="/BD17">トリクルダウン</a>してくる。
</p><br/><p>　今日は<a class="oln" data-kno="K#/2088" href="/2088">休みの日</a>と位置づけた。最近プログラミングのやり過ぎで、疲労感がある。
</p><br/><p class="no_idt">　昼。軽く街をぶらついた。散歩ルートがなかなか定まらずにいる。
<br/>　ぶらついた後、やや暖かかったのも有って、<a class="oln" data-kno="K#/8E96" href="/8E96">スタバのテラス</a>で読書をした。そのためにわざわざ本を持ち出しておいた。テラスでの読書は、今年はコレが最後になるだろう。そろそろ寒さが厳しくなりそうだ。
</p><br/><p>　夕飯。鍋に積まれた白菜の山に蓋を載せながら、俺はいつか<a class="oln" data-kno="K#/D0F5" href="/D0F5">寸胴</a>を買うのだろうなと思った。
</p><br/><p>　月曜が近づき、<a class="oln" data-kno="K#/EAC8" href="/EAC8">2023年11月17日日記</a>で書いた開発中のシステムを吹っ飛ばしたままの件が重くのしかかる。憂鬱だ。Gloomy Monday。なにかの手違いで直っていてほしいが、そんなことは起こらないので、なんとかするしか無い。
</p>

 　実家からみかんが届いた。5kg。ギリギリ冷蔵庫に入った。5kgともなると流石に食べきれずに腐らせてしまうので、職場で配りたい。明日総務部あたりに頒布していいか打診しよう。
　和歌山では農家からみかんがトリクルダウンしてくる。
　今日は休みの日と位置づけた。最近プログラミングのやり過ぎで、疲労感がある。
　昼。軽く街をぶらついた。散歩ルートがなかなか定まらずにいる。
　ぶらついた後、やや暖かかったのも有って、スタバのテラスで読書をした。そのためにわざわざ本を持ち出しておいた。テラスでの読書は、今年はコレが最後になるだろう。そろそろ寒さが厳しくなりそうだ。
　夕飯。鍋に積まれた白菜の山に蓋を載せながら、俺はいつか寸胴を買うのだろうなと思った。
　月曜が近づき、2023年11月17日日記で書いた開発中のシステムを吹っ飛ばしたままの件が重くのしかかる。憂鬱だ。Gloomy Monday。なにかの手違いで直っていてほしいが、そんなことは起こらないので、なんとかするしか無い。
 

2023年11月19日日記

実家

スタバのテラス

<p>　服薬をサボってたら<a class="oln" data-kno="K#/3AB9" href="/3AB9">メンタル</a>を不調が襲ったので、薬をのんだ。
</p><br/><p>　<a class="oln" data-kno="K#/D151" href="/D151">実家</a>から送られてきた5kgの<a class="oln_unk" href="/?kw=K%23EDD2+%26+みかん&rdr">みかん</a>が残り半分以下になっている。「週明けに職場で配ろう」とか思ってたら、このままなくなる勢いだ。
</p><br/><p class="no_idt">　年末も近づき、<a class="oln" data-kno="K#/D151" href="/D151">実家</a>の<a class="oln" data-kno="K#/FAA6" href="/FAA6">親</a>のことが思い出されて<a class="oln" data-kno="K#/4AB4" href="/4AB4">情緒</a>が不安定になる。親の<a class="oln" data-kno="K#/EF2B" href="/EF2B">寂しさ</a>を思ってしまうが、その実私が<a class="oln" data-kno="K#/82D0" href="/82D0">寂しい</a>のかもしれない。<a class="oln" data-kno="K#/BBA3" href="/BBA3">一人暮らし</a>が長い。
<br/>　そろそろ年末の<a class="oln" data-kno="K#/C615" href="/C615">帰省</a>に向けて、実家への飛行機のチケットを取らねば。
</p><br/><p class="no_idt">　<a class="oln" data-kno="K#/3A43" href="/3A43">Next.js</a>の<a class="oln" data-kno="K#/9446" href="/9446">Server Action</a>を性懲りもなく試しているが、どうにもうまく動かない。エラーが出るが、どこがエラーを出しているのか判別がつかない。諦めよう。
<br/>　<a class="oln" data-kno="K#/6194" href="/6194">ServerSideProps</a>に切り替えていく。引数でデータをバケツリレーするのは面倒だが、想定した動作をする可能性が高い。
</p>

 　服薬をサボってたらメンタルを不調が襲ったので、薬をのんだ。
　実家から送られてきた5kgのみかんが残り半分以下になっている。「週明けに職場で配ろう」とか思ってたら、このままなくなる勢いだ。
　年末も近づき、実家の親のことが思い出されて情緒が不安定になる。親の寂しさを思ってしまうが、その実私が寂しいのかもしれない。一人暮らしが長い。
　そろそろ年末の帰省に向けて、実家への飛行機のチケットを取らねば。
　Next.jsのServer Actionを性懲りもなく試しているが、どうにもうまく動かない。エラーが出るが、どこがエラーを出しているのか判別がつかない。諦めよう。
　ServerSidePropsに切り替えていく。引数でデータをバケツリレーするのは面倒だが、想定した動作をする可能性が高い。
 

2023年11月24日日記

寸胴

2023年11月19日

みかん

日記

<p>　朝、体が冷え切って目が覚める温度になってきた。そろそろ布団を出さないと体調を悪くしてしまう。
</p><br/><p class="no_idt">　上司と、私の今年の目標達成率について<a class="oln_unk" href="/?kw=K%23EDD2+%26+1 on 1&rdr">1 on 1</a>をした。お互いに、「毎日の定例で30分話してるし、話すこと無くね？」みたいな感じだったが、普通に予定していた時間いっぱいまで話した。評価は上司の更に上がするので、まあどうなることやらである。
<br/>　設定した目標を完全に忘れていたが、自己評価においては目標達成率は思いの外良かった。ちゃんと、自分が走りそうな方向に目標を置いておいたのが良かった。
<br/>　ちなみにこの<a class="oln" data-kno="K#/E0D3" href="/E0D3">目標管理</a>は給与とかボーナスには影響しない。という建付け。多分参考にはする。
</p><br/><p class="no_idt">　仕事で問い合わせを出して、その回答待ちなのを良いことに、すげーダラダラしていた。
<br/>　<a class="oln" data-kno="K#/3A43" href="/3A43">Next.js</a>で<a class="oln" data-kno="K#/21E5" href="/21E5">SMTP</a>を受ける方法とか検討していた。無理そう。コレができるとシステムでできることの幅が広がるのだが。普通にマネージドサービスを使ったほうが良いんだろう。
</p><p class="no_idt">　そうこうしていたところ、仕事でクラウド上に作ってるシステムが、全部吹っ飛んでいることが判明した。DBやらファイルやらユーザーアカウントやらが全部消えた。まだ本番運用前で良かった。
<br/>　上司と話したところ、週明けに原因調査しようということになった。定時直前に発覚して、上司に相談した上で泣きながら帰宅した。
<br/>　何も心当たりのある操作してないんだよなぁ……。クラウドのコンソールにログインするアカウントが不正ログインされた形跡もなかった。クラウドのシステム自体の不具合で消えたんだったら、一発アウトなので別のクラウドに移行しないといけなくなってしまう。
<br/>　CI/CD・DB・ストレージ・認証・認可・API生成の全部入りのマネージドサービス（フレームワーク付き）でこの事象が起きちゃったので、まじで影響範囲がでかい。死ぬ。たのむ、俺のミスであってくれ。
</p><p>　<a class="oln" data-kno="K#/5D31" href="/5D31">Fediverse</a>で「複雑なマネージドサービスって怖いよね〜〜」という話をしていた。はい。実感。
</p><br/><p>　布団を出してカバーを付けた。カバーをうまく付けられなくてモタモタしてしまった。疲れで不器用になっている。<a class="oln" data-kno="K#/4F5F" href="/4F5F">俺はもうだめだ</a>。
</p>

 　朝、体が冷え切って目が覚める温度になってきた。そろそろ布団を出さないと体調を悪くしてしまう。
　上司と、私の今年の目標達成率について1 on 1をした。お互いに、「毎日の定例で30分話してるし、話すこと無くね？」みたいな感じだったが、普通に予定していた時間いっぱいまで話した。評価は上司の更に上がするので、まあどうなることやらである。
　設定した目標を完全に忘れていたが、自己評価においては目標達成率は思いの外良かった。ちゃんと、自分が走りそうな方向に目標を置いておいたのが良かった。
　ちなみにこの目標管理は給与とかボーナスには影響しない。という建付け。多分参考にはする。
　仕事で問い合わせを出して、その回答待ちなのを良いことに、すげーダラダラしていた。
　Next.jsでSMTPを受ける方法とか検討していた。無理そう。コレができるとシステムでできることの幅が広がるのだが。普通にマネージドサービスを使ったほうが良いんだろう。
　そうこうしていたところ、仕事でクラウド上に作ってるシステムが、全部吹っ飛んでいることが判明した。DBやらファイルやらユーザーアカウントやらが全部消えた。まだ本番運用前で良かった。
　上司と話したところ、週明けに原因調査しようということになった。定時直前に発覚して、上司に相談した上で泣きながら帰宅した。
　何も心当たりのある操作してないんだよなぁ……。クラウドのコンソールにログインするアカウントが不正ログインされた形跡もなかった。クラウドのシステム自体の不具合で消えたんだったら、一発アウトなので別のクラウドに移行しないといけなくなってしまう。
　CI/CD・DB・ストレージ・認証・認可・API生成の全部入りのマネージドサービス（フレームワーク付き）でこの事象が起きちゃったので、まじで影響範囲がでかい。死ぬ。たのむ、俺のミスであってくれ。
　Fediverseで「複雑なマネージドサービスって怖いよね〜〜」という話をしていた。はい。実感。
　布団を出してカバーを付けた。カバーをうまく付けられなくてモタモタしてしまった。疲れで不器用になっている。俺はもうだめだ。
  

2023年11月17日日記

<h2>再現手順</h2><p><a class="oln" data-kno="K#/9977" href="/9977">Amplify</a>を触ったことがある人を対象としているため、画像を貼ったりせず、事細かには説明しない。適宜補完してほしい。
</p><h3>本番と見なすAmplifyのアプリを作成する</h3><h4>ダミーのウェブアプリを作る</h4><ol><li>Githubに空のレポジトリを作成する<li>GithubからレポジトリをCloneする<li>ローカルの端末で<code>npx create-react-app amplify_the_destroyer</code>などと実行して、テスト用に適当なウェブアプリを作成する。ここでnext.jsで作るとややこしいことになるのでやってはいけない。</ol><h4>Amplifyのウェブコンソールでの作業</h4><ol><li>Amplifyのウェブコンソールから「アプリケーションを構築」を押して、アプリ（名前はto_be_destroyedとする）を作成する。</ol><h4>ローカルの端末での作業</h4><ol><li>Backend environmentsにstagingがあるので、これを<code>amplify pull --appId {appId} --envName staging</code>で取得する。<li><code>git add .</code>、<code>git commit -m &quot;init&quot;</code>、<code>git push</code>を実行して、レポジトリにコードを反映させる。</ol><h4>Amplifyのウェブコンソールでの作業</h4><ol><li>Hosting environmentsからGithubを選択して、上記レポジトリのmainブランチと連携させる。<li>「ビルドの設定」画面で、Environmentを「新しい環境を作成」にし、Environment名は空欄のままにする。<li>デプロイを開始し、デプロイされるのを待つ。</ol>
<h4>作業結果</h4><p>下の画像のようになれば成功だ。Amplifyを使っている人には見慣れた光景かと思う。
</p><p><a class="img" href="https://i.gyazo.com/b1af5f4cf0a579a15f244f51268333ee.png"><img src="https://i.gyazo.com/b1af5f4cf0a579a15f244f51268333ee.png" style="max-width: 100%;"/></a></p><p><a class="img" href="https://i.gyazo.com/bfe135b044bf63eed1be678a301e14a2.png"><img src="https://i.gyazo.com/bfe135b044bf63eed1be678a301e14a2.png" style="max-width: 100%;"/></a></p><p>この後、ローカルの端末で<code>amplify pull --appId {appId} --envName main</code>を実行してmainと同期し、その結果をGithubのレポジトリにpushしておく。
</p><br/><h3>本番環境とは切り離された検証環境のつもりでAmplifyで別アプリを作成する。</h3><ol><li>Amplifyのウェブコンソールから「アプリケーションを構築」を押して、アプリ（名前はdestroyerとする）を作成する。<li>Hosting environmentsからGithubを選択して、上記レポジトリのmainブランチと連携させる。<li>「ビルドの設定」画面で、Environmentを「新しい環境を作成」にし、Environment名は空欄のままにする。<li>デプロイを開始し、デプロイされるのを待つ</ol><h3>Amplifyのウェブコンソール上でdestroyerを削除して、to_be_destroyedのBackend Environmentsが削除されるのを確認する</h3><ol><li>Amplifyのウェブコンソールでdestroyerを開き、「アプリの削除」を押して削除する。<li>destoryerが削除されたら、to_be_destroyedのBackend Environmentsが削除されているのを確認する。</ol><p><a class="img" href="https://i.gyazo.com/bc8ba2adc37ffab192e1b09dcf87db03.png"><img src="https://i.gyazo.com/bc8ba2adc37ffab192e1b09dcf87db03.png" style="max-width: 100%;"/></a></p><p>mainが「Deletion completed」となっているのが確認できる。
</p><br/><h2>原因</h2><p class="no_idt">Amplifyにレポジトリ連携でデプロイする時、team-provider-info.jsonがレポジトリに入っていると、別Appであっても同一のCloudFormationスタックが用いられる。
<br/>そのため、Appを削除するとCloudFormationによって他Appと共用となってしまっているバックエンド環境が削除される。
</p><br/><h2>対策（未検証）</h2><ul><li>Amplifyと連携しているレポジトリからteam-provider-info.jsonを消す<li>.gitignoreにteam-provider-info.jsonを追加する<li>CloudFormationのスタック削除保護を有効化する<li>バックアップを設定する</ul><br/><h2>後記</h2><p class="no_idt">代理店を通じてAWSにBackend Environmentsの復旧を依頼したが、Backend Environmentsに掛かるDynamoDB・S3は復旧できないとのこと。
<br/>amplify pullを実行すると、.gitignoreに色々追記されるが、team-provider-info.jsonは除外設定にならない。
<br/>本事象は私のプロジェクトの本格運用前に発生した。本格運用が始まった状態でこの問題が発生した場合にはより深刻な影響を及ぼしただろう。
<br/>DynamoDBのデータは、<a class="oln" data-kno="K#/28A2" href="/28A2">DataStore</a>がDynamoDBと同期していたブラウザのIndexedDBより救出された。
<br/>今年の2月に開始された弊プロジェクトでは、この他にも2度ほどAmplifyのバグを踏んでいる。
</p>

 再現手順Amplifyを触ったことがある人を対象としているため、画像を貼ったりせず、事細かには説明しない。適宜補完してほしい。
本番と見なすAmplifyのアプリを作成するダミーのウェブアプリを作るGithubに空のレポジトリを作成するGithubからレポジトリをCloneするローカルの端末でnpx create-react-app amplify_the_destroyerなどと実行して、テスト用に適当なウェブアプリを作成する。ここでnext.jsで作るとややこしいことになるのでやってはいけない。Amplifyのウェブコンソールでの作業Amplifyのウェブコンソールから「アプリケーションを構築」を押して、アプリ（名前はto_be_destroyedとする）を作成する。ローカルの端末での作業Backend environmentsにstagingがあるので、これをamplify pull --appId {appId} --envName stagingで取得する。git add .、git commit -m "init"、git pushを実行して、レポジトリにコードを反映させる。Amplifyのウェブコンソールでの作業Hosting environmentsからGithubを選択して、上記レポジトリのmainブランチと連携させる。「ビルドの設定」画面で、Environmentを「新しい環境を作成」にし、Environment名は空欄のままにする。デプロイを開始し、デプロイされるのを待つ。
作業結果下の画像のようになれば成功だ。Amplifyを使っている人には見慣れた光景かと思う。
この後、ローカルの端末でamplify pull --appId {appId} --envName mainを実行してmainと同期し、その結果をGithubのレポジトリにpushしておく。
本番環境とは切り離された検証環境のつもりでAmplifyで別アプリを作成する。Amplifyのウェブコンソールから「アプリケーションを構築」を押して、アプリ（名前はdestroyerとする）を作成する。Hosting environmentsからGithubを選択して、上記レポジトリのmainブランチと連携させる。「ビルドの設定」画面で、Environmentを「新しい環境を作成」にし、Environment名は空欄のままにする。デプロイを開始し、デプロイされるのを待つAmplifyのウェブコンソール上でdestroyerを削除して、to_be_destroyedのBackend Environmentsが削除されるのを確認するAmplifyのウェブコンソールでdestroyerを開き、「アプリの削除」を押して削除する。destoryerが削除されたら、to_be_destroyedのBackend Environmentsが削除されているのを確認する。mainが「Deletion completed」となっているのが確認できる。
原因Amplifyにレポジトリ連携でデプロイする時、team-provider-info.jsonがレポジトリに入っていると、別Appであっても同一のCloudFormationスタックが用いられる。
そのため、Appを削除するとCloudFormationによって他Appと共用となってしまっているバックエンド環境が削除される。
対策（未検証）Amplifyと連携しているレポジトリからteam-provider-info.jsonを消す.gitignoreにteam-provider-info.jsonを追加するCloudFormationのスタック削除保護を有効化するバックアップを設定する後記代理店を通じてAWSにBackend Environmentsの復旧を依頼したが、Backend Environmentsに掛かるDynamoDB・S3は復旧できないとのこと。
amplify pullを実行すると、.gitignoreに色々追記されるが、team-provider-info.jsonは除外設定にならない。
本事象は私のプロジェクトの本格運用前に発生した。本格運用が始まった状態でこの問題が発生した場合にはより深刻な影響を及ぼしただろう。
DynamoDBのデータは、DataStoreがDynamoDBと同期していたブラウザのIndexedDBより救出された。
今年の2月に開始された弊プロジェクトでは、この他にも2度ほどAmplifyのバグを踏んでいる。
 

AWS Amplifyで検証用アプリを作ったあとに削除したら、大本のアプリのBackend environmentsが意図せず消された

和歌山

カフェで読書

<blockquote><p>結論としてはHyDEはそれほど有効ではないことです。少し改善すれば性能は良くなりますが、検索スピードは非常に遅いですし、コストも大幅増加するので、ほぼ実用ではない手法といえます。
</p><footer><span class="dmdsh">──</span>  <a class="URI" href="http://www.jiang.jp/posts/20230510_hyde_detailed/" target="_blank" rel="noopener nofollow ugc">http://www.jiang.jp/posts/20230510_hyde_detailed/</a></footer></blockquote><p class="no_idt">HyDEはLLMで質問文を生成するので、遅いし費用も掛かる。
<br/>モデルの学習のコストを掛けられるのであれば、<a class="oln" data-kno="K#/41FF" href="/41FF">Two-Towerモデル</a>のほうが早く検索できて良さそうに思える。
</p>

 結論としてはHyDEはそれほど有効ではないことです。少し改善すれば性能は良くなりますが、検索スピードは非常に遅いですし、コストも大幅増加するので、ほぼ実用ではない手法といえます。
──  http://www.jiang.jp/posts/20230510_hyde_detailed/HyDEはLLMで質問文を生成するので、遅いし費用も掛かる。
モデルの学習のコストを掛けられるのであれば、Two-Towerモデルのほうが早く検索できて良さそうに思える。
  

HyDEは有効ではない

Hypothetical Document Embedding

<p><a class="URI" href="http://www.jiang.jp/posts/20230601_embedding_benchmark/" target="_blank" rel="noopener nofollow ugc">http://www.jiang.jp/posts/20230601_embedding_benchmark/</a>
</p>

 http://www.jiang.jp/posts/20230601_embedding_benchmark/
  

t_wの輪郭

最近傍探索

ScaNN